Why does LabVIEW generate -0?

[SiliconAddict]

I have attached a bit of code that occaisonally generates a value of -0.

[JÞB · Accepted solution]

LabVIEW like most other programming languages implements the IEEE 754 standard that states how to correcty display and operate on floating point numbers in a computer. 

+0 and -0 have the same value for the mantissa and exponent but the sign bit is set on the -0.  there are three other special values that are defined in the same standard -inf, +inf and NaN (Not a Number)

If you really hate that -0 you can add 0 to your result (Really "-0" + "+0" = "+0")

[SiliconAddict]

Thank you, it surprised me because I have never seen a use for a negative 0.

[mikeporter]

Hmm... Interestingly, -0 is also apparently larger than 0. Try the Min & Max function on your -0 output.

Mike...

[JÞB]

---

@mikeporter wrote:

Hmm... Interestingly, -0 is also apparently larger than 0. Try the Min & Max function on your -0 output.

Mike...

---

Run that one through again Mike!  BOTH outputs are -0  (REALLY thats the correct behavior!)

Wait untill you run across an instance where NaN fails self equality!  by spec! NaN is not equal to any IEEE 754 code including NaN!  those silly engineers!

[Darin.K]

---

@JÞB wrote:

Run that one through again Mike!  BOTH outputs are -0  (REALLY thats the correct behavior!)

---

There is something missing, both outputs should not be -0, and if they are that is really not the correct behavior.  Max & Min is simply a comparison and a swap (ie. a conditional swap).  In this case, comparing 0 and -0 should result in no swapping since they are "equal" by definition.  The Max and Min should simply passthrough the values, one output will be 0 and the other -0 with the order depending on the order of the input.

[JÞB]

---

@Darin.K wrote:

---

@JÞB wrote:

Run that one through again Mike!  BOTH outputs are -0  (REALLY thats the correct behavior!)

---

There is something missing, both outputs should not be -0, and if they are that is really not the correct behavior.  Max & Min is simply a comparison and a swap (ie. a conditional swap).  In this case, comparing 0 and -0 should result in no swapping since they are "equal" by definition.  The Max and Min should simply passthrough the values, one output will be 0 and the other -0 with the order depending on the order of the input.

---

At the risk of hijacking the thread  - My oppologies to the OP

Go- ahead and debate it in the next IEEE conferance.  I have at least as much disrespct for authority as Dr Kinion.!   But, unlike (or maybe just like) Schroedinger and Heidelberg, I bow to thie wisdom of generating reproducalbe results- even if the results are technically incorrect.  Math is funny- with computers its even "funnier" because it needs to ......

Too bad humans were not gifted with a random number of fingers. 

[Darin.K]

I have no quibble with the IEEE spec, I am only claiming that if the behavior is as you described max(0,-0) = min(0,-0) = -0 then I would argue about how LV is implementing the spec. I haven't tried myself, I expect the operation to be a noop and return the two values in the order entered. Mike seems to say -0 is returned as the max and you say they are both -0. I'll simply test when I get a chance.

[JÞB]

there are a few special cases defined.  By definition -0 and 0 are equal.  TRUE!  

inequality is otherwise defined.  enough to make your head spin.  Well, enough to make MY head spin!  funny stuff!

[Darin.K]

OK I got a chance to play with this, and it is even more fun than I could have imagined!

First of all Max&Min does the conditional swap as I expected and it is all good.  You get the outputs back in the same order.

Now I start playing with other special cases of the spec: (LV10)

1. Drop a sqrt function, create an indicator and create a constant on the input, enter -0.0

2. Ctrl-drag the -0 contant and wire the copy to both terminals of an add function, create an indicator

3. Run the VI and look at the two values.

4. Change the value in the constant wired to the add function to 0

5. Run the VI, both values change!

Probably some weird constant-folding thing going on.