Re: Strange behavior of comparison with double.PositiveInfinity - C# Discussion Boards

Re: Strange behavior of comparison with double.PositiveInfinity

31-Jul-07 1:13

Today, I stumbled on the strangest behavior I've seen so far and unfortunatley I'm not able to find an explaination. Here is the problem:
I'm currently testing a library with random generators. The generators have a function NextDouble that generates a floating point random number within a specified range. The range is computed by subtracting the specified minValue from the specified maxValue. Afterwards the computed range is passed to double.IsPositiveInfinity, so the method can throw an exception if an overflow occured.
Strangely the comparison only works in Debug mode (below code outputs "NextDouble: Infinity"). If I run the same code in Release mode the comparison does not work (below code outputs "NextDouble: Not infinity"). I first thought this might be an issue of code optimization, but even if I turn off the optimization in release mode it doesn't work. To make the whole thing even more strange, the comparison works if the final Console.Out is uncommented.

Does the small console application show the same behavior on your computers? Does someone have an explaination for this strange behavior? By the way, I'm running this with .NET framework 2.0.50727.

static class Program
{
    [STAThread]
    static void Main()
    {
		NextDouble(Double.MinValue, Double.MaxValue);

		Console.ReadLine();
	}

	public static void NextDouble(double minValue, double maxValue)
	{
		double range = maxValue - minValue;

		if (double.IsPositiveInfinity(range))
			Console.Out.WriteLine("NextDouble: Infinity");
		else
			Console.Out.WriteLine("NextDouble: Not infinity");

		//Console.Out.WriteLine("NextDouble: " + range);
	}
}

-- modified at 9:11 Tuesday 31st July, 2007

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rick Cook

www.troschuetz.de

Luc Pattyn31-Jul-07 1:30

Re: Strange behavior of comparison with double.PositiveInfinity

31-Jul-07 1:30

Did you read the documentation ?

on Double.PositiveInfinity MSDN gives the remark:
Use IsPositiveInfinity to determine whether a value evaluates to positive infinity. It is not possible to determine whether a value evaluates to positive infinity by comparing it to another value equal to PositiveInfinity

I don't know about different handling of extreme double values under debug/release
conditions; as long as you go against the manual, you can't trust the behavior
anyway.

Smile | :)

Luc Pattyn

try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] }
catch { [Google] }

Stefan Troschuetz31-Jul-07 2:31

Re: Strange behavior of comparison with double.PositiveInfinity

31-Jul-07 2:31

I forgot to mentioned that I suspected something like this too and also tested with Double.IsPositiveInfinity. The behavior is the same, so I didn't took a look at the documentation of Double.PositiveInfinity.

Luc Pattyn31-Jul-07 2:50

Re: Strange behavior of comparison with double.PositiveInfinity

31-Jul-07 2:50

Stefan Troschuetz wrote:
so I didn't took a look at the documentation

There is no excuse; you should read the documentation before using something.
And you should consult it again as soon as you don't agree with the observed
behavior of it. Mad | :mad:

In the end, that is only after after careful reading and analysis, you can
start publishing messages with "strange behavior" in their subject...

Luc Pattyn

try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] }
catch { [Google] }

Stefan Troschuetz31-Jul-07 3:11

Re: Strange behavior of comparison with double.PositiveInfinity

31-Jul-07 3:11

Ok, normally I read the docs very carefully. In this case I must admit that I only read the documentation of Double.IsPositiveInfinity, since after I changed range == double.PositiveInfinity to double.IsPositiveInfinity(range) and the behavior staid the same I jumped to the conclusion that it is not a matter of doing a comparison against Double.PositiveInfinity. You're right that it is no good excuse (especially not for using Double.PositiveInfinity in the first place), but the there is still the strange behavior of Double.IsPositiveInfinity.

Luc Pattyn31-Jul-07 3:36

Re: Strange behavior of comparison with double.PositiveInfinity

31-Jul-07 3:36

Stefan Troschuetz wrote:
I read the docs very carefully

Your modified code runs fine for me; it gives "Infinity"
when running in debug under Visual 2005
when running in release under Visual 2005
and when running outside Visual 2005

Confused | :confused:

Luc Pattyn

try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] }
catch { [Google] }

Stefan Troschuetz31-Jul-07 4:23

Re: Strange behavior of comparison with double.PositiveInfinity

31-Jul-07 4:23

I was afraid of something like this. It still does not work on my computer neither under VS2005 nor outside. The same result on my laptop. Maybe this is an issue of the german version only Confused | :confused:

Tested the code under framework 1.0 and 1.1 and there it runs just fine. Also I took a look at the IL code and could not find an obvious error though I must admit that I have not much experience with IL.
I'm somewhat out of ideas what to do with this Sigh | :sigh:

Luc Pattyn31-Jul-07 4:36

Re: Strange behavior of comparison with double.PositiveInfinity

31-Jul-07 4:36

If I were living in a country where infinity can not be trusted,
I would emigrate the same day...

Luc Pattyn

try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] }
catch { [Google] }

Stefan Troschuetz31-Jul-07 4:41

Re: Strange behavior of comparison with double.PositiveInfinity

31-Jul-07 4:41

THX for the tip Smile | :)

PhilDanger31-Jul-07 4:54

PhilDanger

31-Jul-07 4:54

The code runs fine for me (printing "Infinity") in the following situations:

Commented, Uncommented Last Line in Debug
Uncommented Last Line in Release

It does NOT work (printing "Not Infinity"), when:

Commented Last Line in Release.

Strange indeed!

Re: Strange behavior of comparison with double.PositiveInfinity

Stefan Troschuetz31-Jul-07 9:06

Writing a Type to Binary File

31-Jul-07 9:06

What version of the framework is installed on your computer? Any language packs?

JamesBarnes31-Jul-07 0:56

JamesBarnes

31-Jul-07 0:56

I want to write a type to a binary file, but the write method only seems to support strings... is there a way i can do this?

Cheers Smile | :)

FileStream fs = new FileStream("weapon.dat",FileMode.OpenOrCreate,FileAccess.ReadWrite);<br />
            BinaryWriter bw = new BinaryWriter(fs);<br />
            BinaryReader br = new BinaryReader(fs);<br />
<br />
            bw.Seek(0, SeekOrigin.End);<br />
            bw.Write(Weapon);<br />

Re: Writing a Type to Binary File

Luc Pattyn31-Jul-07 1:08

Re: Writing a Type to Binary File

31-Jul-07 1:08

Hi,

BinaryWriter.Write() has overloads for all kinds of native data types, including
int and string. Of course it does not know your class.

If you have a Weapon class, you could add a Write(BinaryWriter) method it,
that would perform a number of basic BinaryWriter.Write() calls so everything
that needs to be written gets written. And of course you would have to
also add a Read method; you might make that one static and have it return a
new instance of Weapon.

The next problem may consist of understanding you binary file; if it consists
of a number of records, each containing the data for one out of many possible
types, you must somehow decide which classe's Read must be invoked next.

One way of solving this is by adding a static bool Recognize(BinaryReader) method,
that does not modify the stream's position, but determines if the data corresponds
with that class.

And it typically is helpful to start each record with something unique,
often called an eyecatcher. It could be a single character ('W' for weapon),
an enum value, whatever. In doing so, you could have a general ReadFile() method
that peeks at the next eyecatcher, then calls the right Read() method, and
loops over this until the file is done.

Smile | :)

Luc Pattyn

try { [Search CP Articles] [Search CP Forums] [Forum Guidelines] [My Articles] }
catch { [Google] }

JamesBarnes31-Jul-07 1:11

JamesBarnes

31-Jul-07 1:11

Thanks for the quick reply (again Big Grin | :-D

), it was very helpful ^^

how to make sure Socket has connected?

Gavin Roberts31-Jul-07 0:56

Gavin Roberts

31-Jul-07 0:56

Hi all,

I would like to be able to correctly determine whether I have connected to my Host before trying to login.

Everything I can think of trying has failed.

If I try connecting to 192.168.0.1 110 it says its connected, but has 0 bytes Available. Which is great, and works for valid and invalid addresses whilst debugging, but as soon as I remove all breakpoints it comes back with errors on the valid addresses.

I done a quick search, and found using a mixture of Poll and Available which unfortunately doesn't work either.

Basically I don't want any code to continue until I have a Connected and Communicating Socket.

Any idea's?

Regards

Gav

led mike31-Jul-07 4:21

led mike

31-Jul-07 4:21

Gavin Roberts wrote:
it comes back with errors

What errors?
What "comes back with errors"?

Gavin Roberts wrote:
Basically I don't want any code to continue until I have a Connected and Communicating Socket.

Then check for the error and if present don't continue

Gavin Roberts31-Jul-07 5:08

Gavin Roberts

31-Jul-07 5:08

Sorry. Basically I use Socket.Available to check if any data is available before continuing which whilst stepping through with a debugger, works fine as soon as I run the code with no breakpoints Socket.Available returns 0.

I am currently using Socket.Read to check but that is quite slow.

Cheers for the reply.

Gav

led mike31-Jul-07 5:41

led mike

31-Jul-07 5:41

Gavin Roberts wrote:
I am currently using Socket.Read to check but that is quite slow.

Slow?? Read will read quit fast when the TCP/IP stack has received the data from the remote socket. If it is "slow" then the network connection or remote server must be slow.

Under normal network and server conditions for a POP3 Server, you can do a blocking "Connect" and when that returns you can "Read" the "OK" message sent by the Server immediately. There should be no significant delay. If there is, then you have a network issue or the POP3 Server is slow.

Gavin Roberts31-Jul-07 6:08

Gavin Roberts

31-Jul-07 6:08

I am using Socket.Connect to connect.

At the moment, I am having to use Socket.Receive to determine whether the connection is valid or not.

I was using Socket.Available, but this only seemed to work when I was stepping through each line using Visual Studio. As soon as I removed all breakpoints and allowed it to continue as normal, Socket.Available returned incorrect data, as if it hadn't enough time to populate.

Socket.Receive is slow for a invalid Connection, and i'd prefere to speed this up.

Thanks

Gav

pbraun31-Jul-07 8:45

pbraun

31-Jul-07 8:45

Gavin Roberts wrote:
Socket.Receive is slow for a invalid Connection, and i'd prefere to speed this up.

Socket.Receive is blocking which means that it will only return after it has received data or the connection has been closed.

To check if the connection is valid you will have to look at the socket options available to see if any of those help. Also you should be checking the return status of Socket.Connect to see if it connected properly and if you are not catching any exceptions around the Socket.Connect, then you will be missing information that may lead to the answer you are seeking.

An inference from the above is that the socket should be valid by the time the receive method is called.

Phil