01-30-2006 03:40 AM
01-30-2006 03:56 AM
01-30-2006 04:58 AM
01-30-2006 04:59 AM
01-30-2006 07:00 AM
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...
01-30-2006 07:10 AM - edited 01-30-2006 07:10 AM
Message Edited by GerdW on 01-30-2006 02:12 PM
01-30-2006 07:16 AM
01-30-2006 07:42 AM
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.
*****
😄
01-30-2006 09:27 AM
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?
01-30-2006 09:44 AM