Calculating 250 Digits of Euler's number with PowerBASIC

[Gunther]

Last week I bought an external floppy drive. On one floppy disk I found some old mainframe programs. I wrote most of them as a student with PL/1.
This was at the time when memory was a rare resource. I adjusted the following program from there for PowerBASIC 3.5. It's a plain DOS program
and in my opinion it belongs in this subforum. If Hutch decides otherwise, I'm okay with that, too.

The application calculates 250 decimal digits of the Euler's number e = 2.718281828... For this purpose it uses an array with 52 elements (208 Byte)
of the data type REAL4. The BASIC program provides the framework. There the variables as well as the array are created and the result is printed.
But the real dirty work is done by the procedures in assembly language.

All floating point operations are realized with the old FPU. The only prerequisite is the 386/387 tandem. That is why the program will run properly under
different configurations. I have tested it under: plain FreeDOS, FreeDOS with VirtualBox and VMware Player, DOS emulation of OS/2 Warp 4 and DOSBox.
The program should also run under the DOS emulation of Windows 95, if someone still has that installed. The output of the program looks like this:

Code Select Expand


2 71828 18284 59045 23536 2874 71352 66249 77572 47093 69995 95749 66967 62772 40766 30353 54759 45713 82178 52516
64274 27466 39193 20030 59921 81741 35966 29043 57290 3342 95260 59563 7381 32328 62794 34907 63233 82988 7531 95251
1901 15738 34187 93070 21540 89149 93488 41675 9244 76146 6681

Please, press any key to end the application ...


The background of the algorithm has to do with the Taylor series and the rest element. With this method, D. Gillies and D. Wheeler calculated 100 000
decimal digits of e in 1964. In 1971, J. Dutka used it to calculate 1 000 000 digits of the square root of 2. The method can, of course, be accelerated.
However, I deliberately didn't use SSE instructions, since that doesn't work on older processors.

A feedback and test reports from other members would be nice. Many thanks in advance.

[FORTRANS]

Hi Gunther,

   Well, it runs okay here.  But leading zeroes are suppressed in
your output.

Regards,

Steve N.

[HSE]

Hi Gunther!

Code Select Expand

FOR i = 0 TO 50
  LEN1 = 6 - LEN(STR$(X(i)))
  IF LEN1 > 0  THEN
    IF i = 0 THEN
      STDOUT STRING$(LEN1," ");
    ELSE
      STDOUT STRING$(LEN1,"0");
    END IF
    STDOUT MID$(STR$(X(i),5),2,6);
  ELSE
    STDOUT MID$(STR$(X(i),5),2,6);
  END IF
NEXT i


Code Select Expand

    27182818284590452353602874713526624977572470936999595749669676277240766303535475945713821785251664274274663919320030599218174135966290435729003342952605956307381323286279434907632338298807531952510190115738341879307021540891499348841675092447614606681

Please, press any key to end the application ...


Nice to play a little 

Regards, HSE

[Gunther]

Steve,

   Well, it runs okay here.  But leading zeroes are suppressed in
your output.

Yes, I see. But HSE did fix it.

By the way, what's your DOS configuration?

[Gunther]

HSE,

Nice to play a little 

Thank you. Good catch!  As soon as I've time, I'll post the update.

What's your DOS configuration?

[HSE]

Gunther,

What's your DOS configuration?

That was in DosBox 0.74-3. I have machine=svga_s3, but I think everything is default. PB was 3.50 and Assembler used was JWAsmR (I builded from v2.15).

Perhaps look better with point:

Code Select Expand

FOR i = 0 TO 50
  LEN1 = 6 - LEN(STR$(X(i)))
  IF LEN1 > 0  THEN
    IF i = 0 THEN
      STDOUT STRING$(LEN1-1," ");
    ELSE
      STDOUT STRING$(LEN1,"0");
    END IF
    STDOUT MID$(STR$(X(i),5),2,6);
    IF i = 0 THEN STDOUT ".";
  ELSE
    STDOUT MID$(STR$(X(i),5),2,6);
  END IF
NEXT i 

[FORTRANS]

Hi,

By the way, what's your DOS configuration?

   On this system, Windows 2000 and OS/2 Warp 4.

Regards,

Steve

[Gunther]

HSE,

That was in DosBox 0.74-3. I have machine=svga_s3, but I think everything is default. PB was 3.50 and Assembler used was JWAsmR (I builded from v2.15).

Good to know. DOSBox is quite solid and well suited for testing purposes.

Perhaps look better with point:

Probably. I'll check that.

[Gunther]

Steve,

   On this system, Windows 2000 and OS/2 Warp 4.

thank you for the information. 

Would it make sense to use SIMD instructions?

[Gunther]

The update is in the archive e250r1.zip under the first post in this thread. Now also leading zeros are printed correctly. Also, a dot is printed after the 2.
The output should look like that:

Code Select Expand


2.7182818284590452353602874713526624977572470936999595749669676277240766303535475945713821785251664274274663919320030599218174135966290435729003342952605956307381323286279434907632338298807531952510190115738341879307021540891499348841675092447614606681

Please, press any key to end the application ...


The improved output loop in lines 124 - 142 in the source code of E250.BAS is a suggestion from HSE. Many thanks to him.  I've also noted this in the source code.

[FORTRANS]

Steve,

   On this system, Windows 2000 and OS/2 Warp 4.

thank you for the information. 

Would it make sense to use SIMD instructions?

Hi,

   Well, not on this computer, they are not supported
(P-III MMX).  And I assume you mean at least some
version of SSE.  And JJ's MASMBASIC requires SSE2
and does not run here.

   I suspect, that since you are asking the question,
that it would be of interest to you.  But then a DOS
program is probably not the way to go.  I have a bit of
difficulty in using DOS timing programs on this system.
And Windows and OS/2 react differently in that regard.
And if you write a program using SIMD code, you
should probably test it against your original program
to see what differences are notable.

   Have fun?  Keep us posted on any neat programming.

Cheers,

Steve N.

[Gunther]

Thank you Steve.

   Have fun?  Keep us posted on any neat programming.

I'll do my best. 

[daydreamer]

Steve,

   On this system, Windows 2000 and OS/2 Warp 4.

thank you for the information. 

Would it make sense to use SIMD instructions?

If you move to 32bit SSE is well suited for packed fp instructions together with Taylor series perform 4 parts of calculations SIMD
( I don't know what each x^y/constant part in Taylor series is called in english)

[avcaballero]

That's quite nice    Just wonder why use DOS instead Windows

[Gunther]

Daydreamer,

If you move to 32bit SSE is well suited for packed fp instructions together with Taylor series perform 4 parts of calculations SIMD
( I don't know what each x^y/constant part in Taylor series is called in english)

I'm aware of that. The point is that with this algorithm, on each pass of the loop, both the element and its successor and predecessor are iteratively computed.
That makes things difficult. But I'll think about this.

My idea was to use SIMD instrutions to make floating point calculations more convenient. With this algorithm, REAL4 values are already sufficient for the calculation.
High accuracy is not required. Therefore, SIMD arithmetic should be good enough.