Is there a bug on Quotient & Remainder function?

[Mourgue Stéphane]

Hello everybody.

I work with Labview 7.
I have a trouble with the Quotient and Remainder function but also with DBL
multiplication and addition.

The Quotient & Remainder function of 200/0.1 given by labview is 1999.9 as
quotient and 0.1 as remainder !!!

Can you tell me if I done something wrong or if it's a bug ?

Thanks in advance.

[John_Howard]

I suspect this is simply due to the lack of precision using the double. (you end up getting round off error - caused by the limited number of bits available to represent the numbers.) It is probably the double representation of 0.1 that looses most of the precision, especially when factored by 200. The error just gets multiplied.

If you use extended precision representation, you should get more accurate results - at least with a reasonable number of significant digits. Also, if you scale everything by 10 or 100, you will get more accurate results as well. (ie. 2000/1 or 20000/10 instead of 200/0.1)

Maybe someone else can give you the more technical explaination, but hopefullly this helps a little.

[Al_S]

There are a couple of strange things here.
1. If you take those same double precision numbers and feed them into the Divide function, the answer is correct.
2. If you create the controls, set the representation of the numbers to extended precision, then add the Quotient & Remainder function and wire it up, the answer is correct. But if you create the numbers as double-precision, wire them to Quotient & Remainder, run the VI, and then set the representation to Extended Precision, the answer is wrong.
3. LabView should have no problem representing 0.1 as a double precision number. It's not a number like 1/3.
LabView 6.1 behaves the same way.

[Dr._Imad]

If I understood the issue correctly, I could not duplicate it with version 6.02 and 6.1

200 = 1999*0.1 + 0.1

see attched image

All variables are of type double

Sorry, I do not have version 7 yet

[John_Howard]

I just tried it with LabVIEW 7.0 and got the same result as you. (200 = 1999*0.1 + 0.1)

Although I think most people would expect to get,

200 = 2000*0.1 + 0.0

I'd guess the reason we don't is because in double respresentation, 0.1 is actually 0.099999999999 or something like that.

[altenbach]

Al S wrote: "3. LabView should have no problem representing 0.1 as a double precision number. It's not a number like 1/3."

Actually, computers care little about decimal representation. A perfectly round number such as 0.1 in decimal can well contain an infinite number of digits in binary representation that must be truncated. DBL 0.1 is internally 0.0999999999999889033.

[Greg_McKaskle2]

> 3. LabView should have no problem representing 0.1 as a double
> precision number. It's not a number like 1/3.
> LabView 6.1 behaves the same way.

Actually, I'm glad you brought up 1/3. Most of us are comfortable with
the fact that 1/3 is precise, and that no decimal representation of it
is. But, remember that LV didn't make up its own numeric type, we just
use the IEEE numerics that Intel or Motorola or Sun built into the HW.
And IEEE many years ago decided that the low-level format of floating
point numbers is stored in binary. Guess what, 1/10 in base two is an
infinitely repeating decimal. It is no different than 1/3 in base ten.
And just for completeness, 1/3 isn't that special, in base nine, it is
precisely represented as
0.3.

So what you have stumbled across is simply mathematical magic where
discrete math tries to pretend it has infinite precision, but doesn't
really. It can carry off the illusion most of the time, but introduce
our friend 0.1 and most of the magic stops working.

My recommendation would be to use remainder and quotient with integers,
or be sure to round your numbers appropriately afterwards.

Greg McKaskle

[arussell]

"altenbach" wrote in message
news:5065000000050000001E1A0100-1042324653000@exchange.ni.com...
> Al S wrote: "3. LabView should have no problem representing 0.1
> as a double precision number. It's not a number like 1/3."
>
> Actually, computers care little about decimal representation. A
> perfectly round number such as 0.1 in decimal can well contain an
> infinite number of digits in binary representation that must be
> truncated. DBL 0.1 is internally 0.0999999999999889033.

Just for funs, I figured the binary representation of 0.1d to be
0.000110011...
I didnt take it further but suspect that the four digits 0011 repeat
endlessly after that.