LabVIEW
quotient & remainder bug
I assume xband got the answer 25 in stead of 26.
(That was the same problem I had in the past... 1 divided by 0.2 would give the answer 4)
However, in LV2012 I also get 26.... It seems the QR behaviour has changed!
And I never got any kudo's !!! 
Hi,
confirm: result of QR is 25 (instead of expected 26).
Things to do:
- increase number of shown digits in all indicators to 20: you will notice the remainder is no longer 1e-8
- why don't you do your QR operation on the prescaled value of 260 and just scale the result of that operation?
Dealing with inaccuracy involves thinking about correct order of operations! When using floats you have to deal with rounding errors, often due to values of different magnitude...
@Anthony_de_Vries wrote:
I assume xband got the answer 25 in stead of 26.
I figured that much from the file name, but it seemed vague. 😉
Of course that raises the question on how it could have possibly changed over the versions because the old result was most likely "mathematically correct" too due to the fuzzy nature of floating point operations. I guess that this is not an intentional change but a side effect of some operation reordering inside the node that, by a lucky coincidence (!), now gives the expected result. 😄
Is there a CAR or release note mentioning any of this change? What is the first LabVIEW version that gives 26?
@Anthony_de_Vries wrote:
When I try it now in Matlab 2012, it also has changed it's behaviour, and gives 'human results'.
Interesting. Maybe the change was made in some common library (e.g. Intel MKL). I am curious what the change was and if it has any negative implications under other scenarios. 😉
