Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

bef

Member

01-10-2012 08:41 AM

Options

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

Rod42

Active Participant

01-10-2012 09:25 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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.

rolfk

Proven Zealot

01-10-2012 09:29 AM - edited 01-10-2012 09:32 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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.

Norbert_B

Proven Zealot

01-10-2012 09:35 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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.

----------------------------------------------------------------------------------------------------

CEO: What exactly is stopping us from doing this?

Expert: Geometry

Marketing Manager: Just ignore it.

01-10-2012 09:46 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

JÞB

Knight of NI

01-10-2012 10:10 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

@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

rolfk

Proven Zealot

01-10-2012 10:34 AM - edited 01-10-2012 10:36 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

@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 754Participation 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.

Broken_Arrow

Active Participant

01-10-2012 10:42 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

@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 , 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

Rod42

Active Participant

01-10-2012 11:01 AM - edited 01-10-2012 11:04 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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.