quotient & remainder bug

[Anthony_de_Vries]

I just noticed that Labview can't calculate properly!     

According to the 'quotient & remainder' vi:    1 divided by 0.2 = 4  !! 

I searched the forum, and saw that people allready reported it for Labview 6.   It was attributed to the rounding of reals after the calculation.  Ofcourse, that's all nice and true... but it still should give the correct answer.  The normal Labview divide vi does give the correct answer.  

Also, when you create your own 'quotient & remainder' vi, using the standard Labview  'divide' and 'floor' vi's, you do get the correct answer.   (See attachment)

Am I missing something here?    Or is this just a bug that has slipped past....

Funniest thing...   When I jokingly asked my collegaes the answer to "1 divided by 0.2"  I got all wrong anwsers as well!   But at least they all had the number 5 in them somewhere! 

[GerdW]

Hello Anthony,

are you sure you are dividing 1 by 0.2 ???
Hint: search the forum for "floting point numbers", precision, IEEE standards and so on. You will find many threads on this topic.

Explanation:
Floating point numbers cannot represent fractions with multiples of 10. And 0.2 is a multiple of 1/10... So you probably divided 1 by 0.2000000...009 (or something similar), giving you 4 and a remainder of 0.19999.9991! This is also the reason for NEVER comparing floating point numbers for equality!

[K C]

Hi,

In LV7 a 0.2 will show as a 0.2 even if you extend the number of significant digits.

In LV8 you can see what GerdW explained if the number of significant digits is increased. See picture.

[becktho]

Hi

Gerd that's exactly what I thought first after reading the 1st post, but this should nod be considered as a problem, because it is possible to wire floatingpoint values to the Q&R-vi. So I also would assume the function to work correctly.

Thomas

[Anthony_de_Vries]

Ofcourse I accept that reals have a limited accuracy.   You are right Gerd, even when one types 0.2  into a number control, you can check with LV 8 that it's actually translated to 2.000000000000001 E-1

However, the limited accuracy of the number representation generally should not influence the actual answers we expect.  In normal math, 1 divided by 0.2 = 5.   Labview should give the same results.    The 'quotient & remainder' vi accepts reals, so it should therefore give the number 5 that we expect.   The vi is completely useless when it gives the answer 4, with a remainder of 0.2. 

The internal representation of a real number should not be of influence on the result of the mathematical operation! 

It's not like this is an unsolvable problem.   As I've allready demonstrated in my vi, dividing yourself, and then rounding down, somehow behaves a lot better.  Then, it does give the answer 5.   It didn't always work though... It seems that the actual problem comes from the rounding.   I've now created a vi that always seems to give the excepted result.  (see new attachement) 

Here's the trick:    I start with DBL for x and y and divide the numbers.  The result is then converted to SGL.  This SGL representation of x/y is then rounded down.  Doing things this way, gives the expected results.  I haven't found a situation where it fails yet.

I don't know exactly what the DBL to SGL conversion does, but it seems that the round function should do something similar to get meaningfull results.   

I do know that I like the results of my 'quotient&remainder' version a lot more than Labview's one... 

[GerdW]

Hello Anthony,

you cannot have (ideal) math with floating point  numbers... You (as programmer) have to keep in mind the problems arising from limited accuracy! You cannot have LabView to check this for you. This applies to all programming languages, not only LabView. Btw.: "Q&R" doesn't give 4 and 0.2 as answers, it gives 4 and 0.19...99 (And that's correct for the input you gave 🙂

If you depend on "accurate math" you have to take precautions like in your VI.

Message Edited by GerdW on 01-30-2006 02:12 PM

[becktho]

Reasoned this way, you are right GerdW - 5 stars from me...

[Ray.R]

That's why validating a vi is a must...  😉

Gerd is correct.  If we depend on precision, then our vi's may require some fine tuning to endure that it is met.

*****

😄

[Anthony_de_Vries]

Ah....  

So I am expected to make sure that my own vi's give meaningfull results, by I can't expect/request that the original Labview vi's give meaningfull results? 

I'd better start checking all those other standard vi's too! 

Seriously,

I'm rather surprised that you accept this abnormal behaviour as acceptable.   Ofcourse I know that reals can't be represented to inifinite accuracy in a computer.   However, because of that limited accuracy, we calculate in high precision, and then round off to a lower precision to get a meaningfull result.  (A results that is often equal to the one we would get if if we did have infinite accuracy.)  

When I take a calculator, I expect that 1.2 / 0.2 gives the anwer 6.   I do not want to see the 5,9999999999999991 raw number that comes out of the calculation.  It's perfectly normal to require the answer to be 6.   You can also see this behaviour in the conversion from DBL to SGL.   Labview will convert the above number to 6.00000 in SGL.   It does not convert the number to 5.99999999       

What I think is going wrong is that the 'floor' in the quotient & remainder is not first rounding the division result to a more meaningfull real number of lower precision...   And the result is chaos... 

The way I see it, the current behaviour of the vi is unwanted and unneccesary.   Whether it is logical from a computer technical viewpoint is irrelevant. The result should be logical to a human.

But let me ask it differently...    Is there anything against the alternative method I proposed, which does give the same results as normal everyday math?

[GerdW]

Hello Anthony,

yes, I accept this behaviour as normal. Once upon a time I implemented my own FloatingPoint-Engine on an 8bit-processor, this way I learned the facts behind IEEE854.

A computer can only calc by rules and for FloatingPoint the rules are given in IEEE854! (and LabView is IEEE854-compliant...) There is no "unwanted" or "unneccesary" result, it's just (pure IEEE854-)math. The only point is: the rules defined by IEEE854 are different to yours...

You want a "result logical to humans"? Then you have to program it that way, as you already did. There isn't "anything" against your subVI.
If you want rounded results you have to use "Round to xx" after (or in-between) calculation. And conversion from DBL to SGL is perfect in this case (5.99...991 will of course get rounded to 6.0, this is in line with mathematics).

And when you take a cheap calculator you will have wrong or inaccurate results as soon as you do a "SQRT" or "division by 3" 🙂