Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site decwrl.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!unc!mcnc!decvax!decwrl!dec-rhea!dec-pbsvax!cooper
From: cooper@pbsvax.DEC (Topher Cooper HLO2-3/M08 DTN225-5819)
Newsgroups: net.math
Subject: Re: multiple-precision arithmetic
Message-ID: <215@decwrl.UUCP>
Date: Tue, 11-Dec-84 18:36:08 EST
Article-I.D.: decwrl.215
Posted: Tue Dec 11 18:36:08 1984
Date-Received: Thu, 13-Dec-84 05:30:41 EST
Sender: daemon@decwrl.UUCP
Organization: DEC Engineering Network
Lines: 45

lines: 45

> ... it seemed possible to write a routine that could run forever computing
> digits for PI.  No need for umpteen digit precision arithmetic.

Sounds neat, but I'm afraid its not possible; at least not unless PI is
rational.  I seem to remember that the non-rationality of PI has never
been proven, but the smart money is on that side.

Let's start by assuming an iterative (non-recursive) algorithm which
cranks along with a fixed amount of space, emitting digits of PI every
once in a while.

The state at the end of the code being iterated over, and what is emitted
during its execution, is completely determined by the state at the
start of the code's execution.  Since there is a fixed amount of storage
(say N bits) there is a fixed number of states which it could be in.
After at most 2^N iterations a state would be repeated and the a repeating
pattern would start to be emitted.

Of course, very good approximations can be done in principal with very
little storage.  Conceivably, a single 16 bit state variable could result
in 64Kbits (roughly 20,000 digits).

The same argument applies to recursive algorithms, but in this case the
extra state may be hidden in the stack.

An exact algorithm which didn't start with infinite storage would have to
grow (perhaps slowly).  This is usually done with dynamic alocation of
multiple precision integers, floating-points, or rationals; but could
be done in other ways.

> I once saw a MACRO-11 routine (quite small) for computing the digits
> of "e" indefinitely, using only a small amount of storage.

The same argument applies.  Either the routine was an approximation to
some large number of digits, or it used a trick like a slowly increasing
recursive depth to approximate infinite storage.

I think any elegant algorithms along these lines would be of interest.

	Topher

USENET: ...decvax!decwrl!dec-rhea!dec-pbsvax!cooper
ARPA: cooper%pbsvax.DEC@decwrl.ARPA