LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"minus zero" in numeric indicator

Hi,

just a general question:

 

Since LabVIEW 2010 (I think) a numeric indicator displays "-0" if you devide zero by a negative number.

(Display format is "automatic formatting") 

 

e.g.: 

0/-1=-0 (minus zero)

0/2 = 0

 

There's nothing wrong with that , but my customers usually don't like that.

Is there an option to change that so that zero is zero (and not minus zero) ?

 

Thanks! 

-DB
0 Kudos
Message 1 of 9
(4,216 Views)

It's a bit of a kludge, but you could add zero!

 

On my LV2009, I cast the result of the division onto a 64bit int, so I could see that 0/-1 (in double) really is -0 (double) [sign bit 1, all other bits zero]

 

By adding double precision zero to the result, I get a clean zero, ie all bits zero.

 

0 / -1 = -0

( 0 / -1 ) + 0 = 0

 

 

 

Rod.

 

Message 2 of 9
(4,203 Views)

Try to display at least 15 digits of the number. Most likely it is not exactly 0 but more something like -0.0000000000000123. This could be the effect of the different code generator used to compile the diagram into machine code. The generated floating code by the underlaying LLVM compiler that is used since 2009 or so, might generate significantly different machine code sequences that could explain such differences. Or it is really some other change in your own code that you haven't even noticed yet.

 

 

EDIT: I just see that this seems a more common problem and the set sign bit for a true 0, while logically not really wrong, is indeed a not so nice thing. Now the big question: Was that already known and will be fixed in 2011 SP1 or is that new, and then will most likely not even be changed in 2012.

Rolf Kalbermatter
My Blog
0 Kudos
Message 3 of 9
(4,198 Views)

It is not necessarily something != 0. Due to the double precision, there is a dedicated code for '-0'.

 

While Rod's suggestion works (adding a positive zero), this "hack" has to be documented in your code!

The clean solution would be a comparison (remark: do not compare floating point against "==") and then compute the absolut value.

 

hope this helps,

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 4 of 9
(4,186 Views)

If we start talking mathematics, we all agree that "-0" is the same number as "0".

The signum bit is not cleared when deviding 0 by a negative number. ok.

 

BUT: to be consistent: if you ADD zero to minus zero the solution should be minus zero: -0 + 0 = -0, just like -5 + 0 = -5.

So for me it feels like an inconsistency:

I a devision the signum bit is not cleared when the solution is truely zero. In additions the bit gets cleared.

 

But this is going way too far. In the end it's just a display problem. And to be honest: I can't compare -0 against 0 every time I display a numeric. I'd rather go with adding zero and pray for the next SP to fix this.

 

Thanks, Rod! 

-DB
0 Kudos
Message 5 of 9
(4,176 Views)

@bef wrote:

If we start talking mathematics, we all agree that "-0" is the same number as "0".

. I'd rather go with adding zero and pray for the next SP to fix this.

 

Thanks, Rod! 



Actually -0 and +0 (while refering to the same quantity) have different encodings in memory and to the Computer are not the same.  What you see as an "Inconsistancy" or a bug is actually the behavior required by IEEE-754 for floating point math operations.  You may chose to disagree with the "correctness" of IEEE 754 but they (IEEE) are the definition of correct.  If you wish to contact them and submit an abstract expressing the need to amend IEEE 754

Participation in IEEE standard development is easy- according to this website


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 9
(4,162 Views)

@Jeff Bohrer wrote:

@bef wrote:

If we start talking mathematics, we all agree that "-0" is the same number as "0".

. I'd rather go with adding zero and pray for the next SP to fix this.

 

Thanks, Rod! 



Actually -0 and +0 (while refering to the same quantity) have different encodings in memory and to the Computer are not the same.  What you see as an "Inconsistancy" or a bug is actually the behavior required by IEEE-754 for floating point math operations.  You may chose to disagree with the "correctness" of IEEE 754 but they (IEEE) are the definition of correct.  If you wish to contact them and submit an abstract expressing the need to amend IEEE 754

Participation in IEEE standard development is easy- according to this website


I agree that the IEEE standard allows not only but provides two distinctive binary values to represent -0 and +0. This can be useful when calculating with certain formulas, but is in most everyday scenarios of little value. The fact that this seems to only show up in LabVIEW 2010 and newer also is an indication, that LabVIEW did it in the past differently. Most likely it has to do with the new LLVM machine code generator that was introduced in LabVIEW 2010. This code generator most likely does the "right thing" in terms of IEEE 754, but it isn't really intuitve to Joe average, and more importantly seems to be different than what it did before, when using the self cooked machine code generator.

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 9
(4,153 Views)

@rolfk wrote:

                      [...]  Most likely it is not exactly 0 but more something like -0.0000000000000123. This could be the effect of the different code generator used to compile the diagram [...]


 

This is where the "Approximately Equal to Zero" VI comes in handy. You have to write it yourself Smiley Wink, or I think Bloomy Controls has one. I like to have an input called "resolution limit". Example, wire a 5 to it, if there's 5 zeros to the right of the decimal, it outputs 0 and/or a Boolean True.

 

Richard






0 Kudos
Message 8 of 9
(4,144 Views)

I've looked back to earlier revisions of LabVIEW.

 

As far back as at least 6.1, dividing 0 by -1 yields the bit pattern of 0x8000...., so the calculation returns "minus zero".

 

In my 8.2, (EDIT: and 6.1, I don't have access to 7.x) the result is displayed as 0 with the default double precision indicator format, but as -0 in LV2009.

 

 

Rod.

 

Message 9 of 9
(4,133 Views)