LabVIEW
quotient & remainder bug
Oh my... What did I start? 
I'll try to address everything that came up...
tbob hit the nail on the head. Why does a simple calculator give the expected results?
The reason why a normal calculator gives the correct anwser, is that it uses reals the way they are supposed to be used. The calculator will shows maybe 10 digit on the display, for input and output. However, it calculates internally with a higher accuracy, for example 13 digits. After it calculation is done, it rounds the result back to 10 digits. This rounding is essential to getting meaningfull results.
This is probably the whole issue... Obviously, the real representation is inaccurate. It cannot even represent the number 0.2 correctly. It makes 2.000000000000001 E-1 from it... The reason why we still can work with it comfortably, is that we use the reals in such a way that this inherent finite accuracy doesn't bother us. The way to do that, is to make sure that the internal calculation occurs at a higher accuracy then the input and output, and then round the end result. We don't care that the computer transform the numer 0.2 into 2.000000000000001 E-1, because it's rounded back to 0.2
When properly used, you do not notice the finite accuracy of the real number representation in the end results! If you do get deviations, then you should have used a higher internal accuracy.
That's where people make mistakes...
Jean-Pierre said that my routine doesn't work when you really want to divide 1 by 2.000000000000001 E-1. However, you've allready made a fundamental mistake if you try to do that using DBL's. You cannot calculate that kind of number in a DBL. From the number representation of the number 0.2, it's allready clear that the last digit is totaly unusable. Performing operations on it, (that themselves also have a finite accuracy) will increase the number of inaccurate digits. You aren't bothered by it, as long as these quantization errors don't influence the end result! Obviously, the only way to do that, it to make sure that the internal represenation of the number has (much) more digits than the required end-result. Clearly, to calculate 1 by 2.000000000000001 E-1 you would need EXT as the internal representation. (And you would need a corresponding (polymorphic) QR vi that uses EXT as input, and reduces (x/y) to DBL)
Normally, you don't round of the result, until the last moment. (Typically, an indicator on your front panel, or the output in a file) However, the QR routine is a very special case. Here, you must loose the digits with the quantization errors in (x/y), before performing the 'floor' operation. Otherwise, the result is meaningless, as we have seen. That's not a general problem of reals in Labview. It's just a specific feature of the QR routine! (And maybe of the 'floor' routine...)
GerdW
I very much doubt that a QR routine is specified in IEEE854. If it is, I'm sure it does not work like the current Labview implementation.
JoeLabView
Have you tried the second QR vi that I posted? As far as I can see, it's works without any problem with numbers up to 7 digits. Which is logical, as it converts DBL's back to SGL in it's calculation. Could make the vi polymorphic, to do the same with EXT to DBL.
You could ofcourse also create a QR vi that has an input asking at which digit to round (x/y). There's no rule where the quantization errors start to occur... If you've done very complex operations, than you might easily loose 6 digits...
Becktho
1. The computer makes the quantization error. Not the user. The input and output should always be reduced such, that you loose this quantization error. The programmer ofcourse has to make sure that this happens at the correct spots. That includes the programmers who wrote the built-in Labview vi's, such as the QR vi!
4. Indeed, you should be carefull comparing reals. If you really want to compare the result of a division with an equality operator, then you certainly must remove the quantization errors yourself first. One way would be to convert the DBL from the division to SGL before the comparison. Then it will work fine. (I hope that's also the answer you give to such questions.)
There are other techniques, all with their advantages and disadvantage. Clear is however, the real equality is not an easy subject. But it's solvable, using the standard vi's.
However, such an option does not exit for the QR vi ! You cannot change it's behaviour yourself, other than to write a new vi... Converting to SGL before the QR vi does not help! The QR is simply useless for reals.
You could write a "logical" equality for reals, to suit your requirements. In my view, the QR actually, is such a kind of "logical" real devision vi. The vi is about getting an integer quotient, from a real division.... that doesn't look like a normal real operation to me. It cannot simply ignore quantization errors, because it's results become meaningless. And unlike the real equality, there's nothing we can do about it.
5. I would like to meet the programmer that relies on a (arbitrary) quantization error for the funtionality of his program! 
Tell me:
Do you see any use for a QR vi that gives: 1 / 0,2 = 4 as a result? (Except for accountants. )
)Message Edited by Anthony de Vries on 01-31-2006 04:21 PM
