News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Calculating 250 Digits of Euler's number with PowerBASIC

Started by Gunther, May 02, 2022, 11:42:54 AM

Previous topic - Next topic

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:

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.
You have to know the facts before you can distort them.

FORTRANS

Hi Gunther,

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

Regards,

Steve N.

HSE

Hi Gunther!

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

    27182818284590452353602874713526624977572470936999595749669676277240766303535475945713821785251664274274663919320030599218174135966290435729003342952605956307381323286279434907632338298807531952510190115738341879307021540891499348841675092447614606681

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


Nice to play a little  :thumbsup:

Regards, HSE
Equations in Assembly: SmplMath

Gunther

Steve,

Quote from: FORTRANS on May 02, 2022, 09:47:00 PM
   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?
You have to know the facts before you can distort them.

Gunther

HSE,

Quote from: HSE on May 02, 2022, 10:49:18 PM
Nice to play a little  :thumbsup:

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

What's your DOS configuration?
You have to know the facts before you can distort them.

HSE

Gunther,

Quote from: Gunther on May 03, 2022, 03:03:39 AM
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: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
 
Equations in Assembly: SmplMath

FORTRANS

Hi,

Quote from: Gunther on May 03, 2022, 03:00:27 AM
By the way, what's your DOS configuration?

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

Regards,

Steve

Gunther

HSE,

Quote from: HSE on May 03, 2022, 03:42:40 AM
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.

Quote from: HSE on May 03, 2022, 03:42:40 AM
Perhaps look better with point:

Probably. I'll check that.
You have to know the facts before you can distort them.

Gunther

Steve,

Quote from: FORTRANS on May 03, 2022, 05:38:21 AM
   On this system, Windows 2000 and OS/2 Warp 4.

thank you for the information.  :thumbsup:

Would it make sense to use SIMD instructions?
You have to know the facts before you can distort them.

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:

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.  :thumbsup: I've also noted this in the source code.
You have to know the facts before you can distort them.

FORTRANS

Quote from: Gunther on May 03, 2022, 05:44:15 AM
Steve,

Quote from: FORTRANS on May 03, 2022, 05:38:21 AM
   On this system, Windows 2000 and OS/2 Warp 4.

thank you for the information.  :thumbsup:

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.

Quote from: FORTRANS on May 03, 2022, 06:43:52 AM
   Have fun?  Keep us posted on any neat programming.

I'll do my best.  :thup:
You have to know the facts before you can distort them.

daydreamer

Quote from: Gunther on May 03, 2022, 05:44:15 AM
Steve,

Quote from: FORTRANS on May 03, 2022, 05:38:21 AM
   On this system, Windows 2000 and OS/2 Warp 4.

thank you for the information.  :thumbsup:

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)

my none asm creations
https://masm32.com/board/index.php?topic=6937.msg74303#msg74303
I am an Invoker
"An Invoker is a mage who specializes in the manipulation of raw and elemental energies."
Like SIMD coding

avcaballero

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

Gunther

Daydreamer,

Quote from: daydreamer on May 03, 2022, 07:50:07 PM
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.
You have to know the facts before you can distort them.