quotient & remainder bug
in [LabView]
|
Prev: How can I perform a serial communication using RS-232 with LV examples?!
Next: Convert a rpm waveform to digital/analog tach signal. Sound & Vibration
From: Anthony de Vries on 30 Jan 2006 05:10 I just noticed that Labview can't calculate properly! According to the 'quotient & remainder' vi: 1 divided by 0.2 = 4 !! :smileyvery-happy: 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! :smileywink: MyQuotientRemainder.vi: http://forums.ni.com/attachments/ni/170/163975/1/MyQuotientRemainder.vi
From: GerdW on 30 Jan 2006 05:10 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!
From: K C on 30 Jan 2006 06:10 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. divide.jpg: http://forums.ni.com/attachments/ni/170/163983/1/divide.jpg
From: Anthony de Vries on 30 Jan 2006 08:10 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... MyQuotientRemainder.vi: http://forums.ni.com/attachments/ni/170/163999/1/MyQuotientRemainder.vi
From: GerdW on 30 Jan 2006 08:40
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 |