Re: FAQ 4.2 Why is int() broken?
- From: "Peter J. Holzer" <hjp-usenet2@xxxxxx>
- Date: Mon, 4 Aug 2008 14:22:20 +0200
On 2008-08-01 21:00, szr <szrRE@xxxxxxxxxxxxxxx> wrote:
Peter J. Holzer wrote:[...]
On 2008-07-31 17:04, szr <szrRE@xxxxxxxxxxxxxxx> wrote:
Peter J. Holzer wrote:
On 2008-07-29 15:57, szr <szrRE@xxxxxxxxxxxxxxx> wrote:
Peter J. Holzer wrote:
On 2008-07-28 17:56, szr <szrRE@xxxxxxxxxxxxxxx> wrote:
Granted, it's a calculator, but I have often wondered why it
seems to be able to handle such calculations better than a CPU
that's over 400 times faster.
Calculators are also rarely used for computations where accuracy
is much of an issue - 8 or 12 digits are enough. But they are
used by people who expect
0.1 * 10 to be 1.0 but aren't overly surprised if 1/3*3 is
0.9999999.
Testing on a TI-89 (which does have a hefty amount of precision)
entering "1/3*3.0" yields "1." and so does "0.1*10", and Perl seems
to give the same results. On what hardware, language, or such, do
you end up getting 0.99999.. from 1/3*3.0 ?
For example on my HP-48 calculator. It uses 12 decimal places, so
1/3 is
0.333333333333. 0.333333333333 * 3 is clearly 0.999999999999.
A TI-86 also uses 12 decimal places. But it depens how you enter
things:
1/3
.333333333333
.333333333333 * 3
.999999999999
But:
123456789012345678901
1/3
.333333333333
Ans*3
1
The 2nd example uses the build in "Ans" variable which always
contains the result of the last computation, which can be more
accurate than simply re-typing what was displayed.
what happens if you enter "(1/3) * 3" instead of "0.333333333333 *
3" on your HP-48 ?
I didn't enter 0.333333333333 * 3. I entered "1 ENTER 3 / 3 *". The
HP-48 uses Reverse Polish Notation. It also displays all digits
(unless told to display a rounded result), so that wouldn't make a
difference anyway.
I hated those type of calculators. I think the difference is calculators
like the TI 86/89 seems to have a threshold for determining if a number
repeats ad infinitum. On the 86, if I type 0.333... with 12 decimal
digits (12 "3"'s after the ".") and multiply by 3, it's ".999999999999",
but if I add a 13th "3" and multiple by 3 it comes out as "1".
From what you wrote earlier I concluded that the TI-86 uses 14 decimaldigits internally, and displays only 12 (which is similar to the TI
calculators of 25 years ago, which used 11 digits internally and
displayed 8). So for the calculator 0.333333333333 and 0.3333333333333
are different numbers for the calculator, even if both are displayed as
0.333333333333. Multiply both by 3 and you get 0.999999999999 and
0.9999999999999 respectively. If the calculator displays 12 digits, it
can display 0.999999999999 exactly, but it needs to round
0.9999999999999: Since the first digit to be omitted is "9" it needs to
be rounded up, so the rounded value is 1.0. But the value which is
stored is still the correct value 0.9999999999999.
It seems calculators like yours do not do this.
Right. The HP-48 displays the full result by default. It doesn't round
unless told.
The TI-89 seems to be far better with this, though.
As I said, the TI-89 does symbolic algebra. But you could try:
1/3
Ans*3
Ans-1
(force to numeric representation after each step if the calculator
doesn't do it automatically)
And check the result.
Mathetically, the TI-89 seems to get it more right, as (1/3)*3 = 1 is
mathematically correct, as the 3 in the demoninator in of the first
number and 3 in the numinator of the 2nd number (3/1) cancel each
other out,
Since the TI-89 can do symbolic algebra it may actually notice this
never compute 1/3.
Either that or it uses a threshold algorithm like I described (either
way the 89 seems to handle this far better than the 86.)
I don't think there's a threshold algorithm. Your example didn't show
one and it wouldn't work anyway.
leaving 1/1 which is better writen as just plain ol' 1. Then 1-1
is, of course, 0.
I'm not sure why the TI-86 has such a strange result when "-1" is
thrown in,
I have been trying to explain it to you in just about every posting in
this thread. I give up.
This was from only one reply up, so how could it have been from every
posting?
Because the whole thread is about the fact that any floating point
representation has a fixed number of digits in a given base and can
therefore represent only a finite number of different values. It doesn't
matter whether you use base 2 or base 10 or base 42, whether you use 10
or 12 or 53 digits: Almost every result of a division must be rounded,
and therefore a/b*b is generally *not* a.
A decimal representation only has the psychological advantage of being
closer to what people expect.
It just didn't occur to me that the 86 was internally had a
value like 0.99999... which is smaller than zero.
It couldn't be anything else.
hp
.
- Follow-Ups:
- Re: FAQ 4.2 Why is int() broken?
- From: szr
- Re: FAQ 4.2 Why is int() broken?
- References:
- Re: FAQ 4.2 Why is int() broken?
- From: Peter J. Holzer
- Re: FAQ 4.2 Why is int() broken?
- From: szr
- Re: FAQ 4.2 Why is int() broken?
- Prev by Date: Re: FAQ 4.2 Why is int() broken?
- Next by Date: Re: Is there a way to spawn a program from perl that is independent?
- Previous by thread: Re: FAQ 4.2 Why is int() broken?
- Next by thread: Re: FAQ 4.2 Why is int() broken?
- Index(es):
Relevant Pages
|
