Threaded Mode | Linear Mode

Rick314 · (This post was last modified: 06-15-2017 01:18 PM by Gene.)

See the attached scans of handwritten pages I wrote in 1982 to approximate e (2.71828...) to 400+ decimal places on an HP-16C. It takes about 3.5 hours to run, plus the time to enter the 2 program halves and see the results 8 digits at a time. The results are that the fractional portion of e truncated to 404 digits is:

Code:

71828182 84590452

35360287 47135266

24977572 47093699

95957496 69676277

24076630 35354759

45713821 78525166

42742746 63919320

03059921 81741359

66290435 72900334

29526059 56307381

32328627 94349076

32338298 80753195

25101901 15738341

87930702 15408914

99348841 67509244

76146066 80822648

00168477 41185374

23454424 37107539

07774499 20695517

02761838 60626133

13845830 00752044

93382656 02976067

37113200 70932870

91274437 47047230

69697720 93101416

9283

Dieter · 02-07-2015, 07:20 AM

(02-06-2015 02:12 AM)Rick314 Wrote: See the attached scans of handwritten pages I wrote in 1982 to approximate e (2.71828...) to 400+ decimal places on an HP-16C.

Wow, what a coincidence: at the same time I wrote the same e program using the same method on my 41C. Or maybe... it's not quite that coincidental, because those were the days when things like these were done on programmable calculators. My math teacher had a similar program for his TI59 and 700 or 800 digits, while I could finally come up with more than 2200. ;-)

Dieter

Rick314 · 02-11-2015, 01:11 AM

(02-07-2015 07:20 AM)Dieter Wrote: My math teacher had a similar program for his TI59 and 700 or 800 digits, while I could finally come up with more than 2200.

Hello Dieter. Your comment prompted me to resurrect my 1992 Turbo Pascal 6.0 program that approximates e to 1,000,010 decimal places (E1MEG_P.TXT, attached). Key routines were coded in 80386 assembly language, and there are 4 algorithm enhancements explained in the header that I claim as my own. I've looked into it and think it is the fastest algorithm published. In 1992 it took 6.85 hours running on a 25 MHz 80386 PC. I just re-ran it on my 2004 Windows XP 1.3 GHz Pentium 4 PC, the latest I have that still runs 80386 assembly code, and it took 2 minutes 45 seconds. That's interesting: 150x faster due just to 12 years of hardware improvements. Now we are 11 more years into the future... The first and last page of output are also attached (E1MEG_R.TXT).

Thomas Klemm · 02-11-2015, 09:11 AM

Is the spigot algorithm used?

Cheers
Thomas

Cf. The calculation of e to many significant digits by A. H. J. Sale

Frido Bohn · 02-11-2015, 02:33 PM

Quote:... resurrect my 1992 Turbo Pascal 6.0 program that approximates e to 1,000,010 decimal places (E1MEG_P.TXT, attached).

Wow! This is a very fine example how programs should be written. Very structured and full of explanatory comments. This yields a lot of motivation to dive deeper into this matter. Thanks for sharing!

Any idea how to translate that 386-assembler code into something digestible for the Core-iN generation?

Cheers
Frido

Dieter · (This post was last modified: 02-12-2015 12:54 PM by Dieter.)

(02-11-2015 01:11 AM)Rick314 Wrote: Hello Dieter. Your comment prompted me to resurrect my 1992 Turbo Pascal 6.0 program that approximates e to 1,000,010 decimal places (E1MEG_P.TXT, attached). Key routines were coded in 80386 assembly language,

Unbelievable – that's exactly what I did in 1995! I also used Turbo Pascal 6.0 and the main calculation loop was coded in 386 assembly. Since the Pascal compiler did not support 386 instructions I used Borland's TASM for this task. However, the algorithm was the same as the one used on the '41C. ;-)

Dieter

Dieter · 02-12-2015, 12:56 PM

(02-11-2015 02:33 PM)Frido Bohn Wrote: Any idea how to translate that 386-assembler code into something digestible for the Core-iN generation?

I'm not sure if I get you right, but of course even the latest Intel processors still support the commands of their earliest ancestors like the 8088, 80286 and 80386.

Dieter

**rprosperi** · 02-12-2015, 06:22 PM

(02-12-2015 12:56 PM)Dieter Wrote:
(02-11-2015 02:33 PM)Frido Bohn Wrote: Any idea how to translate that 386-assembler code into something digestible for the Core-iN generation?

I'm not sure if I get you right, but of course even the latest Intel processors still support the commands of their earliest ancestors like the 8088, 80286 and 80386.

Dieter

The 386 in-line stuff back then probably ran in real mode, which won't work under Windows, etc. today.

Frido Bohn · 02-12-2015, 06:22 PM

Hi Dieter,

I tripped over Rick's statement,

(02-11-2015 01:11 AM)Rick314 Wrote: I just re-ran it on my 2004 Windows XP 1.3 GHz Pentium 4 PC, the latest I have that still runs 80386 assembly code,...

and interpreted that Pentiums would be able to manage assembler code while later processors would not. However, I may be wrong and Rick didn't have any newer Intel processor at hands.

Cheers
Frido

Thomas Klemm · 02-12-2015, 06:53 PM

(02-11-2015 02:33 PM)Frido Bohn Wrote: Wow! This is a very fine example how programs should be written.

Here's a very fine example how programs should not be written:

Code:

a[87700],b,c=87700,d,e=1e4,f=1e5,h;

main(){for(;b=c--,b>84700;h=printf("%05d",e+d/f),e=d%=f)

for(;--b;d+=f*(h?a[b]:e),a[b]=d%b,d/=b);}

It calculates e to 15000 places in ~ 4.7 seconds on a Dell Precision T5400.

Cf. Arndt • Haenel, \(\pi\) - Unleashed
6.4 Spigot algorithm for e
p.85

A similar program (roemer) was a winning entry at the 6th International Obfuscated C Code Contest (1989):

Code:

                                                                        char

                                                            _3141592654[3141

          ],__3141[3141];_314159[31415],_3141[31415];main(){register char*

      _3_141,*_3_1415, *_3__1415; register int _314,_31415,__31415,*_31,

    _3_14159,__3_1415;*_3141592654=__31415=2,_3141592654[0][_3141592654

   -1]=1[__3141]=5;__3_1415=1;do{_3_14159=_314=0,__31415++;for( _31415

  =0;_31415<(3,14-4)*__31415;_31415++)_31415[_3141]=_314159[_31415]= -

1;_3141[*_314159=_3_14159]=_314;_3_141=_3141592654+__3_1415;_3_1415=

__3_1415    +__3141;for                 (_31415 = 3141-

           __3_1415  ;                  _31415;_31415--

           ,_3_141 ++,                  _3_1415++){_314

           +=_314<<2 ;                  _314<<=1;_314+=

          *_3_1415;_31                   =_314159+_314;

          if(!(*_31+1)                   )* _31 =_314 /

          __31415,_314                   [_3141]=_314 %

          __31415 ;* (                   _3__1415=_3_141

         )+= *_3_1415                     = *_31;while(*

         _3__1415 >=                      31415/3141 ) *

         _3__1415+= -                     10,(*--_3__1415

        )++;_314=_314                     [_3141]; if ( !

        _3_14159 && *                     _3_1415)_3_14159

        =1,__3_1415 =                     3141-_31415;}if(

        _314+(__31415                      >>1)>=__31415 )

        while ( ++ *                       _3_141==3141/314

       )*_3_141--=0                        ;}while(_3_14159

       ) ; { char *                        __3_14= "3.1415";

       write((3,1),                        (--*__3_14,__3_14

       ),(_3_14159                          ++,++_3_14159))+

      3.1415926; }                          for ( _31415 = 1;

     _31415<3141-                           1;_31415++)write(

    31415% 314-(                            3,14),_3141592654[

  _31415    ] +                            "0123456789","314"

  [ 3]+1)-_314;                            puts((*_3141592654=0

,_3141592654))                              ;_314= *"3.141592";}

Cheers
Thomas