Thread Subject:

arithmetics in matlab

Hi,

when Matlab performs 1/(4.1-4), the result in double precision is 10.000000000000036
I am not quite sure why there is a 36 at the very end? Thank you

"pluton schmidt" wrote in message <jed8mg$m4q$1@newscl01ah.mathworks.com>...
> Hi,
>
> when Matlab performs 1/(4.1-4), the result in double precision is 10.000000000000036
> I am not quite sure why there is a 36 at the very end? Thank you

Welcome to the wonderfully wacky world of floating point
arithmetic.

Computers use BINARY arithmetic, not decimal arithmetic.
This means that you cannot represent numbers like 4.1
exactly in double precision. In fact, in matlab, 4.1 is
represented by a binary number that is equivalent to:

4.0999999999999996447286321199499070644378662109375

John

> Computers use BINARY arithmetic, not decimal arithmetic.
> This means that you cannot represent numbers like 4.1
> exactly in double precision. In fact, in matlab, 4.1 is
> represented by a binary number that is equivalent to:
>
> 4.0999999999999996447286321199499070644378662109375

Thanks a lot! It helps. Since, I also tried 1/0.1 (equivalent to 1/(4.1-4)) providing a correct final result of 10 and I then understand that 0.1 can be exactly coded in double precision and binary arithmetic. Anyway, for the original question, would new computer architectures (64bit vs. 32bit) help? Also, I'm interested in how you found
4.0999999999999996447286321199499070644378662109375? Did you perform the decimal to binary arithmetic translation? Thank you again.

On 9 Jan, 02:28, "pluton schmidt" <plutones...@gmail.com> wrote:
> > Computers use BINARY arithmetic, not decimal arithmetic.
> > This means that you cannot represent numbers like 4.1
> > exactly in double precision. In fact, in matlab, 4.1 is
> > represented by a binary number that is equivalent to:
>
> > 4.0999999999999996447286321199499070644378662109375
>
> Thanks a lot! It helps. Since, I also tried 1/0.1 (equivalent to 1/(4.1-4)) providing a correct final result of 10 and I then understand that 0.1 can be exactly coded in double precision and binary arithmetic. Anyway, for the original question, would new computer architectures (64bit vs. 32bit) help?

No. Finite-length binary representations are finite-length
binary representations. The number of correct significant
digits might change, but the effect will not go away.

> Also, I'm interested in how you found
> 4.0999999999999996447286321199499070644378662109375? Did you perform the decimal to binary arithmetic translation? Thank you again.

I would guess he used something like

sprintf('%1.33f',4.1)

Rune

"pluton schmidt" wrote in message <jedfr8$c5e$1@newscl01ah.mathworks.com>...
> > Computers use BINARY arithmetic, not decimal arithmetic.
> > This means that you cannot represent numbers like 4.1
> > exactly in double precision. In fact, in matlab, 4.1 is
> > represented by a binary number that is equivalent to:
> >
> > 4.0999999999999996447286321199499070644378662109375
>
> Thanks a lot! It helps. Since, I also tried 1/0.1 (equivalent to 1/(4.1-4)) providing a correct final result of 10 and I then understand that 0.1 can be exactly coded in double precision and binary arithmetic. Anyway, for the original question, would new computer architectures (64bit vs. 32bit) help? Also, I'm interested in how you found

No. 0.1 cannot be exactly represented in binary. It is
represented as a binary number, which is convertible
to:

0.1000000000000000055511151231257827021181583404541015625

And, no. 64 bit has absolutely no affect on this.

You need to learn to use tolerances whenever you
work with numbers. Never assume that exact
decimal values like this are stored exactly in that
form, although integers can be exactly represented,
up to a limit.

John

ok, thank you both. I just figured out that it was well documented on wikipedia and I do not know much on binary numbers.

Rune Allnor <allnor@tele.ntnu.no> wrote in message <61ff6e72-5654-4d81-afb2-f3e39bdfd516@p16g2000yqd.googlegroups.com>...
> On 9 Jan, 02:28, "pluton schmidt" <plutones...@gmail.com> wrote:
> > > Computers use BINARY arithmetic, not decimal arithmetic.
> > > This means that you cannot represent numbers like 4.1
> > > exactly in double precision. In fact, in matlab, 4.1 is
> > > represented by a binary number that is equivalent to:
> >
> > > 4.0999999999999996447286321199499070644378662109375
> >
> > Thanks a lot! It helps. Since, I also tried 1/0.1 (equivalent to 1/(4.1-4)) providing a correct final result of 10 and I then understand that 0.1 can be exactly coded in double precision and binary arithmetic. Anyway, for the original question, would new computer architectures (64bit vs. 32bit) help?
>
> No. Finite-length binary representations are finite-length
> binary representations. The number of correct significant
> digits might change, but the effect will not go away.
>
> > Also, I'm interested in how you found
> > 4.0999999999999996447286321199499070644378662109375? Did you perform the decimal to binary arithmetic translation? Thank you again.
>
> I would guess he used something like
>
> sprintf('%1.33f',4.1)
>
> Rune

Actually, I used my HPF tool, which takes the IEEE binary
form as stored by MATLAB, then converts it to a decimal
form with a specified number of decimal digits. There is
also a tool called num2strexact on the file exchange, but
my tool is the one I like, as it can also do arbitrary precision
arithmetic, for those who enjoy computing pi to 1000000
digits of precision or more. Does anyone really care what
is the value of sin(1e400)?

It is of no intrinsic value that I know of, but a great deal
of fun to write, so I've never posted it. One feature of
HPF is, since it is a true decimal format, that is can in
fact get the exactly correct result for your computation.
Thus, for example, in 100 decimal digits of precision, do
the same computation two different ways:

% This sets the default precision in HPF to 100 digits:
DefaultNumberOfDigits 100

% Now, convert 4.1 to an HPF form. See that HPF
% still fails, to give the correct result, because it starts
% with 4.1 as a double precision number. Thus you
% cannot do high precision computations with inexact
% numbers.
1/(hpf(4.1) - 4)
ans =
10.00000000000003552713678800513551130104874124353138515438830158425231214032743399511154907853692148

% But, if I tell HPF that 4.1 is the actual number in
% decimal form, it generates the exact value with no
% error.
1/(hpf('4.1') - 4)
ans =
10

John

On 1/9/12 5:09 AM, John D'Errico wrote:
> Does anyone really care what is the value of sin(1e400)?

I do.

> It is of no intrinsic value that I know of, but a great deal
> of fun to write, so I've never posted it. One feature of
> HPF is, since it is a true decimal format, that is can in
> fact get the exactly correct result for your computation.

I would be very interested to test your HPF toolbox.
Could you please make it available on the FEX?
Many thanks.