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