24 digits of PI
joe...@mail.liberty.com
The first 24 digits of PI in just a few steps:
RAD 0 ACOS 2 * DUP TAN MANT
--> 3.14159265358
9.79323846264
Cool, huh?
-Joe-
--
Joseph K. Horn [-jkh-]
<joe...@usa.net>
<http://www.liberty.com/home/joehorn>
"There is always there, but here keeps changing." -- Richard Nelson
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Keith J. Farmer
joe...@mail.liberty.com wrote:
>
> The first 24 digits of PI in just a few steps:
>
> RAD 0 ACOS 2 * DUP TAN MANT
>
> --> 3.14159265358
> 9.79323846264
>
> Cool, huh?
Well, yes. But off-hand I can't figure out .. How?
Keith J. Farmer
John H Meyers
Brilliant mathematician joe...@mail.liberty.com wrote:
> The first 24 digits of PI in just a few steps:
> RAD 0 ACOS 2 * DUP TAN MANT
> [ or use SIN instead of TAN -- see below ]
> --> 3.14159265358
> 9.79323846264
> Cool, huh?
In article <33DFE7...@geocities.com>,
Keith J. Farmer <deo...@geocities.com> followed up:
> Well, yes. But off-hand I can't figure out .. How?
Suppose the decimal expansion of pi is y.yyyyyyyyyyyxxxxxxxxxxxx...
(the first twelve significant digits, then all the rest).
Let's call this 'Y+X', where Y is y.yyyyyyyyyyy
and X is .00000000000xxxxxxxxxxxx...
Clearly, 0 < X < 1E-11, yes?
Joe's RAD 0 ACOS 2 * produces y.yyyyyyyyyyy = 3.14159265358
(Everyone knows that ACOS(0) is pi/2, right?)
Then since pi=Y+X, we have
TAN(Y) = TAN(pi-X) = -TAN(X)
This last equation also implies that
TAN(X) = -TAN(Y) [ = ABS(TAN(Y)) if Y is just a bit less than pi ]
Since the Taylor series expansion of TAN(X) is 'X+2/3!*X^3+16/5!*X^5+...'
(as your HP48 TAYLR function will be glad to confirm for you),
it can be seen that for X less than 1E-11 (which it clearly is),
the difference between X and TAN(X) is less than 1E-33, which
means that pi = Y+X ~= Y+TAN(X) = Y + ABS(TAN(Y)),
within 1E-33, which is much smaller than 1E-24,
easily giving the desired 24 digits of accuracy,
after appending the twelve most significant digits of X
to the twelve significant digits of Y.
Note that Joe's DUP TAN MANT reveals all twelve digits
(absolute value) of TAN(Y)*1E23 = TAN(3.14159265358)*1E23,
which gives the next twelve digits of pi ~= Y + ABS(TAN(Y)).
Note that Joe cleverly started with a value near pi, but slightly
*less* than pi; otherwise if we had taken TAN(3.14159265359), using the
*rounded-up* value normally supplied by the HP48, the resulting ABS(TAN)
value would have needed to be *subtracted* from the original rounded-up
value, and its twelve significant digits (with a leading zero prefixed)
would be the tens-complement of the correct next twelve digits of pi.
But heck, Joe, SIN is actually even more accurate than TAN
(check out the Taylor series expansion), and we wouldn't even
have needed to worry about the ABS(...) !!!
-----------------------------------------------------------
With best wishes from: John H Meyers <jhme...@mum.edu>
John H Meyers
I forgot to add:
How does a calculator get an accurate result for TAN (or SIN, etc.)
of a value very close to pi?
On a Casio fx-6300g, for example, SIN(3.141592653) gives exactly 6E-10
(TAN gives the exact negative of this); using Joe Horn's method,
this spectacular Casio result would offer us only *one* more
decimal digit of pi (rounded), not *double* the number of digits!
Not many calculators manage to get the correct result out to
the very last digit of a double-precision (fixed) result,
as does the HP48! Check it out, folks! How does HP do that?
(and why doesn't anyone else generally do it?)
For very small arguments, most every calculator nowadays
"switches over" to using a power series (Taylor series)
at some particular small argument size; this is done on HP's
for trig, hyperbolic, and log/exp (LNP1, EXPM) functions;
the number of terms used is generally small
(sometimes one term may suffice).
On all HP calcs, this occurs "seamlessly," so that there is no
sudden "jump" in results at the "cross-over" point; not every
calculator even cares about discontinuities, however, as you
may see on many Casio's for hyperbolics with arguments
on either side of .01/ln(10); all hyperbolics for arguments
near .005 are often visibly wrong on various Casio's
(but who cares about a few wrong trailing digits, anyway?)
Even HP did not always have room in ROM for such niceties; the
HP35 delivered trig functions accurate to plus or minus a couple
of counts * 1E-10 (fixed error limit, not relative);
smaller arguments did not retain as many significant digits,
and eventually lost all significance. However, at the time
that HP came out with the HP35, it was the only pocketable
calculator in the world which did trig and logs at all,
and its (3-part) ROM was only a few thousand *bits*
However, on all recent HP's,
try a 25-digit wide floating add/subtract, e.g.:
1E24 - 500000000000 = 1E24
1E24 - 500000000001 = 9.99999999999E23
Note that the difference between these cases is 1 (out of 1E24) !!
(subtract different-magnitude values on any other brand, and compare).
"Quality is Job 1"
joe...@mail.liberty.com
In article <5rohdn$6sf$1...@news.iastate.edu>,
jhme...@miu.edu wrote:
> But heck, Joe, SIN is actually even more accurate than TAN
> check out the Taylor series expansion), and we wouldn't even
> have needed to worry about the ABS(...) !!!
Ah, but you see, whereas I was taught to avoid SIN,
I can't help but admire well-defined ABS or a good TAN...
-Joe-
joe...@usa.net
"A good pun is its own reword."
Klaus Wolferts
jhme...@miu.edu (John H Meyers) writes:
>
> However, on all recent HP's,
> try a 25-digit wide floating add/subtract, e.g.:
>
> 1E24 - 500000000000 = 1E24
> 1E24 - 500000000001 = 9.99999999999E23
> Note that the difference between these cases is 1 (out of 1E24) !!
> (subtract different-magnitude values on any other brand, and compare).
>
> "Quality is Job 1"
Not with my HP-45: 1E24 - 500000000000 = 1E24 :-(
..and I'm sure the HP-45 _is_ a more recent model than the HP-35, because
back in 1973 I had to sell my HP35 in order to afford the HP 45 :-)
But I remember an article in HP-Journal about 20 years ago, where the
different methods to achieve best possible accuracy for trig and other
fuctions were reported. AFAIR the computations used 12 digits and the
results only were rounded and displayed with 10 digits.
Klaus, whose vintage HP-45 glows right in front of me ;-)
--
d...@wolferts.sub.de | Dr.-Ing. Klaus Wolferts
Tel: +49 721 706016 | Ingenieurbuero fuer EDV + Elektronik
Fax: +49 721 706017_|_Mitteltorstr. 45, D-76149 Karlsruhe (Nrt) __________
*** For email answers remove the '-NOSPAM' part of the From: address! ***
John H Meyers
I wrote:
> On all *recent* HP's, try this (25-digit wide!) floating subtraction:
> 1E24 - 500000000000 = 1E24
> 1E24 - 500000000001 = 9.99999999999E23
> Note that HP calcs discriminate a difference of 1, out of 1E24 !!
> (The answers are then necessarily rounded to 12 significant digits).
> Subtract different-magnitude values on any other brand, and compare.
In article <dkw0211497...@wolferts.sub.de>,
d...@wolferts.sub.de-NOSPAM (Klaus Wolferts) writes:
> Not with my HP-45: 1E24 - 500000000000 = 1E24 :-(
> and I'm sure the HP-45 _is_ a more recent model than the HP-35, because
> back in 1973 I had to sell my HP35 in order to afford the HP 45 :-)
Both HP35 and HP45 are very "early" HP calcs, having 10-digit results;
the HP35 was in fact the very first small scientific HP calculator,
soon followed by the HP80 (financial), using the same package.
The HP35 had, as I recall, a 13-digit-wide register for
floating add/subtract (try 1E13-500 vs. 1E12-501,
or 1E12-50 vs. 1E12-51).
On later-vintage HP calcs having 10-digit capacity,
try 1E20 - 5000000000 vs. 1E20 - 5000000001
(I recall that those generally had a 21-digit-wide register).
On 12-digit HP calcs, try the example I originally posted (above);
you will see that a difference of 1 in a problem involving one
argument equal to 1E24 does make a difference, demonstrating
that the effective length of the register used for addition/subtraction
is in fact 25 digits.
> But I remember an article in HP-Journal about 20 years ago, where the
> different methods to achieve best possible accuracy for trig and other
> functions were reported. AFAIR the computations used 12 digits and the
> results only were rounded and displayed with 10 digits.
The HP Journal issue which featured the "powerful pocketful" HP35
is now apparently revived at <http://www.hp.com>; it mentions that
HP considered everything under the sun (Chebychev polynomials, anyone?),
but settled upon the simple "CORDIC" method, which is probably still
in use, in order to give trig results within about _half_a_second_
( cf. 1/100 sec on HP48). Intermediate internal values retained
13 digits, but every value returned to the stack or stored in memory
retained only 10 digits (the HP48 uses 15/12, rather than 13/10).
Trig values were asymmetric; tan(x) and tan(-x) did not always have
the same absolute value, because (-x) was adjusted to (360-x) before
calculating further (did they run out of internal flags?), which
lost some significance for small negative angles.
Weren't some of the algorithms attributed to HP's
"Corporate Cash Manager"?
"Those were the Good Old Days"
werner_h...@moc.mbi.eb
In <5ruis3$80v$1...@news.iastate.edu>, jhme...@miu.edu (John H Meyers) writes:
>I wrote:
>
>> On all *recent* HP's, try this (25-digit wide!) floating subtraction:
>> 1E24 - 500000000000 = 1E24
>> 1E24 - 500000000001 = 9.99999999999E23
>> Note that HP calcs discriminate a difference of 1, out of 1E24 !!
>> (The answers are then necessarily rounded to 12 significant digits).
>> Subtract different-magnitude values on any other brand, and compare.
>
> On 12-digit HP calcs, try the example I originally posted (above);
> you will see that a difference of 1 in a problem involving one
> argument equal to 1E24 does make a difference, demonstrating
> that the effective length of the register used for addition/subtraction
> is in fact 25 digits.
>With best wishes from: John H Meyers <jhme...@mum.edu>
I'm sorry to say that is not true. The HP uses only 15 digits internally.
How then, is it able to discriminate between your two examples?
Well, they are the consequence of the HP's 'unbiased rounding' rules,
which you know very well (I'm sure).
What exactly does 'unbiased rounding' mean?
Why is there a difference between:
1 + 5E-12 yields 1
1.00000000001 + 5E-12 yields 1.00000000002
yet
0.5 0 RND yields 1
1.5 0 RND yields 2
Apparently there are two different rounding rules...
RND rounding (adding 0.5 to the least significant digit and truncating,
also called 'rounding up') still produces an average error not equal to zero.
An example: (x is a single digit)
error
1 + 1E-12 = 1 1E-12
2E-12 = 1 2E-12
3E-12 = 1 3E-12
4E-12 = 1 4E-12
5E-12 = 1.00000000001 -5E-12
6E-12 = 1.00000000001 -4E-12
7E-12 = 1.00000000001 -3E-12
8E-12 = 1.00000000001 -2E-12
9E-12 = 1.00000000001 -1E-12
If we sum the errors, they cancel out save for the 5E-12 case (the
'halfway case').
In order to obtain an average error of zero, we should round that case up
half of the time, and down the other half. This is what is being done in
the HP machines, as illustrated in the following example:
1.11111 11111 0 + 5 E-12 = 1.11111 11111 0 rounded down
1.11111 11111 1 + 5 E-12 = 1.11111 11111 2 rounded up
If the 12th digit is even, the result is rounded down, otherwise it
is rounded up. This is also called 'round to even' and ensures an
average error of 0.
The HP incorporates these rules without the need for a 25 digit intermediate
result. After all, all you need to know is whether digits 13 till 25 of the result
are 5000... 000 or 5xxxxx...xxxxx with xxxx..xxxx not all zeroes. The HP does
this using the Sticky Bit.
Addition and subtraction is performed by 'aligning' the two mantissa's just as
you would do by hand. This means that the smaller number (in abs value)
is shifted right as many times as the difference between the exponents. The
Sticky Bit was initialized to 0 before the shifts, and will indicate if anything
non-zero has been shifted out of the register, thus enabling to know whether
you have the halfway case at hand or not.
This explains the ML objects PACK and PACKSB. The latter
uses the information in the Sticky Bit to do unbiased rounding, while the
former simply rounds up.
A few more examples for multiplication:
(1E8+1) * 33305000 = 3.33050003330 E15 (exact: 3330500033305000) round down
(1E8+1) * 33305001 = 3.33050013331 E15 (exact: 3330500133305001) round up
(1E8+1) * 33315000 = 3.33150003332 E15 (exact: 3331500033315000) round up
(1E8+1) * 33315001 = 3.33150013332 E15 (exact: 3331500133315001) round up
Werner Huysegoms
I don't speak for IBM when I post here
Email: werner_h...@moc.mbi.eb
mirror the entire @ field before replying