1.00 >= 1.00 equals FALSE ?

[gstanczak]

I wrote a small program in an attempt to help a fellow labviewer.  I was elated to recieve my first kudo, but now fear that it may be ill deserved.  After I posted my VI, I realized it did not work the way I expected it to all the time, and am confused why.  The program increments by a certain amount from some number to a larger number, and when it reaches the larger counts back to the start and ends.  For most values it works, but not for all.  For example, when 0 is entered as the start value, 1 for the larger value, and 0.1 for the increment, the program goes up to 1.1, and then down to 2.17e-17.  This to me was fishy enough, but reopening the VI appeared to fix the problem.  After a few different runs though of the program, the problem returns.  I played with the numeric representations and the problem seems to come and go.

I also posted an image of the diagram running with the highlight debugging function enabled.  The program returns false when testing if 1.00 is greater than or equal to 1.00, which total screws the program.  The program increment by 0.1 so I don't understand how a fractional number got introduced.

I am sure there is an explanation for this, I just don't have it.  More importantly, I am not sure when to look out for this, or if there is a situation to avoid.

Thanks!

Greg       7.1.1

[muks]

It works right for me

[Yamaeda]

I can verify it in 8.2. Starting at 0 and looping to 1,0 it does in fact give 1.00 >= 1.00 -> False. It's a rounding error or sorts, as changing the controls to Singles solves it. Changing Current Value property to show 15 significant digits shows why this is happening, 0.1 cant be correctly presented, thus adding some numbers in the 8th to 12-th decimal. If you only want 3 number significance you can multiply with 1000 and convert to integer inside the loop. 😉

/Y

[GerdW]

Hi Greg,

you discovered the mysteries of floating point representation on modern computers

This has been discussed here in the forum a number of times...

"increment by 0.1 so I don't understand how a fractional number got introduced"

FloatingPointNumbers only have limited resolution/accuracy. As you can't represent 0.1 exactly in binary you will end up with rounding errors when repeatedly adding 0.1 in a loop. This will happen regardless of the used representation (SGL, DBL or even EXT). Search the forum for "rounding errors" or Wikipedia for "IEEE 754-2008"!

Message Edited by GerdW on 03-26-2010 11:35 AM

[yenknip]

---

gstanczak wrote:

I wrote a small program in an attempt to help a fellow labviewer.  I was elated to recieve my first kudo, but now fear that it may be ill deserved. 

...

I also posted an image of the diagram running with the highlight debugging function enabled.  The program returns false when testing if 1.00 is greater than or equal to 1.00,

---

On the contrary, if you had used an equal to operation, that would have been bad!

As GerdW said, it is to do with how floating points are handled in binary, there is plenty of info elsewhere, but I will just add a little food for thought:

[Ben]

Yes the issue is how floats are represented in binary which gives me an opertunity to once again shine a light on one of (or should that be THE ONLY*) typos by Christian where he wrote;

---

 (A SGL number is rather inaccurate, and e.g. "1" cannot be represented exactly in binary with the number of bits used for the mantissa.)

---

For more on this subject see this thread where "Epsilon" in mentioned.

Ben

* Someone has to remind the world that he is actually human.

[smercurio_fc]

You know, if I had a nickel for every time someone thinks that LabVIEW can't do math or comparisons because of things like this, due not understanding about how numbers are actually stored in computers, then I would no longer need to worry about saving up for my retirement.

[gstanczak]

It looks like your "Min (and start value)" is 1.00.  Try 0.

g

[gstanczak]

I hear you, but I myself wouldn't be a contributor to your retirement.  I suspected there was a logical reason for it, not a problem with LV.

g

[gstanczak]

Sorry I didn't find previous threads related to this.  I did try, just didn't search the right stuff.

Thanks for the replies/leads.

Greg

Message Edited by gstanczak on 03-26-2010 10:57 AM