Rune Allnor <allnor@tele.ntnu.no> wrote in message <61ff6e7256544d81afb2f3e39bdfd516@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.14)) 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. Finitelength binary representations are finitelength
> 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
