How many "Fast Math" routines for XL/XE are there?

[+Larry]

The Ahl Benchmark post got me thinking about this. These are ones that I know about (they may share some common code):

 

Newell (the original AFAIK)

CSS UltraSpeed Plus OS

Turbo Basic XL

Basic XE

MyIDE OS

Charles Marslett (MyDos author)

OS++

 

Add to the list::

Edit1: Atari Microsoft Basic

Edit2: Fastmath.rom

 

I suspect there are a few others... It might be interesting to run the Ahl Benchmark with a common Basic to see the difference in the the various math packs.

 

-Larry

[thorfdbg]

The Ahl Benchmark post got me thinking about this. These are ones that I know about (they may share some common code):

...

 

While I'm only aware of the TurboBasic math, one should probably include some additional information either. TurboBASIC for example has a much larger footprint, both in program code, and in memory requirements. What it did is that it mostly unrolled the loops, plus added a smarter multiply that required, however, the storage of pre-computed multiplier tables. This luxery does not exist if you need to stay compatible with existing programs for both keeping the original entry points, plus not to use memory addresses the original ROMs did not use. (The non-tabulated entry points in the math-pack are again a clear indicator of the lousy quality here. The math pack is actually part of Basic, and not part of the Os.)

 

 

However, while Frank did a pretty good job of optimizing the code, the BCD math is still the same pretty bad BCD math it was from the beginning, with all the errors the original designers did. From a math standpoint, the design we see here is not very sane. Not only is it very slow, the huge exponent base (which is 100, not 2 as in modern IEEE math. Yes, really 100, not 10) often causes loss of precision due to cancelation and elimination of digits. Even with the moderate improvements in Os++, one can get (as you just see) a ten-fold improvement of the precision (i.e. one extra relevant digit for nothing but a little bit more brain in how to do the rounding).

 

I believe MS basic had some binary math, I wonder how well this worked.

Edited June 3, 2013 by thorfdbg

[+Larry]

Yes, that's right, it did have it's own math routines. It should be included also. (I'm no expert in MS Basic -- always found it a bit awkward after being immersed in Atari 8K Basic.)

 

But it was tested with Ahl, and is a bunch faster than regular 8K Atari Basic:

 

Atari Microsoft Basic Time=101.4 Accuracy .150879 Random=2.06506, 2.06506 (5.60 when RANDOMIZEd)

 

Notes from original tests: "Atari Microsoft Basic would not run properly as the benchmark is written. RND(1) gives a random number between 1 and 1. RND(0) appears to work, but gives the same results each time. A RANDOMIZE statement must be added to "seed" the random number generator. The RANDOMIZE value can be taken from POKEY to provide a "random" seed from 0-255 IIRC. Also, the times for AMSB are single precision floating point (not integers)." Also, somewhat lower accuracy.

 

-Larry

[Mathy]

Hello Larry

 

IIRC, Charles Marslett wrote the Fast Math routines Newell used.

 

BTW check out "Atari Calculator" (CX8102) by Carol Shaw. I was informed that it has no math errors.

 

Sincerely

 

Mathy

[Rybags]

I wouldn't really classify routines built into Basic or other languages in the same class. The likes of Newell replace the OS FP routines which means they're globally available regardless of what's running.

 

I forget the name, think it's a Euro production, there's another FP replacement - I've only got it as Fastmath.rom - it replaces the OS FP and has some extra code that lives just below $CC00 in the XL OS, it's quicker again than the Newell one.

 

I believe the Newell FP is also present in OmniMon Roms.

[+Larry]

Thanks, Mathy! I had never heard of the Atari Calculator. Nice write-up at the link.

 

Hi Rybags-

 

I don't remember that Omnimon has fast math. Wes sold the RamRod XL OS board and it typically came with OSNXL (with his fast math), and Omnimon or Omniview. I have a bunch of old ads from Wes and David Young, so I can look at them and test the OS's. How about running Ahl on the Fastmath package when you get a chance. I will get all these benchmarked.

 

-Larry

[Mathy]

Hello Larry

 

Even Atari probably forgot that they had it. Atleast in Europe, it was never sold and I guess it wasn't sold in most parts of the world, if at all. Roland (the guy who made the page from the link above) searched for it for years and only found it recently.

 

And if I understood Roland correctly, Atari Calculator wasn't the only piece of software Atari had lying on the shelf, ready to sell, but that was never sold.

 

Sincerely

 

Mathy

[thorfdbg]

BTW check out "Atari Calculator" (CX8102) by Carol Shaw. I was informed that it has no math errors.

 

Well, it's all numerics, so you do have errors, unavoidable. That 2^2 is not 4 is unavoidable due to the stupid way how Basic computes the power function. Atari Basic rev. B and C "kind of" fixed that by always rounding up to the next integer if base and exponent are both integer. Just too bad that this makes 4^4 = 257 then with Os++ (even though the result is 256.000002 or so).

 

Thus, I wonder whether the calculator actually did better math, or just did the same type of rounding trick. The test on the web page is not quite suitable to detect that. It would be, for example, better to see sqrt(2)-2^0.5 (should be zero, but typically is not).

 

At least one thing I got right: LOG(1)=0 in Os++. (-:

[TXG/MNX]

The Ahl Benchmark post got me thinking about this. These are ones that I know about (they may share some common code):

 

Newell (the original AFAIK)

CSS UltraSpeed Plus OS

Turbo Basic XL

Basic XE

MyIDE OS

Charles Marslett (MyDos author)

OS++

 

Edit1: Atari Microsoft Basic

Edit2: Fastmath.rom

 

I suspect there are a few others... It might be interesting to run the Ahl Benchmark with a common Basic to see the difference in the the various math packs.

 

-Larry

 

What is OS++ i never heard of it where can I get it ?

[thorfdbg]

What is OS++ i never heard of it where can I get it ?

 

Os++ is the operating system originally developped for the Atari++ emulator, but it is complete and stand-alone (i.e. you can use it without the emulator). You can get an older version here: http://www.xl-project.com/.I am currently working on a next release (of both Atari++ and Os++) which includes bug fixes, new features and a new "system disk", featuring a menu-based DUP for its FMS and many additional tools. If you want to help me beta-testing, let me know, I can send you the ROM image and the disk image.

Edited June 6, 2013 by thorfdbg

[ClausB]

Sorry, Larry, I've had my fingers in this one too. I wrote a triple-speed multiplier:

http://atariage.com/...m/#entry1508306

[Faicuai]

Hello Larry

 

IIRC, Charles Marslett wrote the Fast Math routines Newell used.

 

BTW check out "Atari Calculator" (CX8102) by Carol Shaw. I was informed that it has no math errors.

 

Sincerely

 

Mathy

 

WOW (!)

 

Now, this one is what I would call for the true "Connoisseur" (!)

 

Had I missed your post, I would have not know about the existence of this baby.

 

I ran some preliminary tests on it (transcendental functions) and I have already seen clear signs that it runs FP operations differently than, say, Basic... and all this by 1979 (!!!).

 

I will be later checking this one vis-a-vis my 48GX (with arbitrary-precision FP library set to Atari's precision), and come back here with anything interesting I find.

 

THANKS!

[+Stephen]

WOW (!)

 

Now, this one is what I would call for the true "Connoisseur" (!)

 

Had I missed your post, I would have not know about the existence of this baby.

 

I ran some preliminary tests on it (transcendental functions) and I have already seen clear signs that it runs FP operations differently than, say, Basic... and all this by 1979 (!!!).

 

I will be later checking this one vis-a-vis my 48GX (with arbitrary-precision FP library set to Atari's precision), and come back here with anything interesting I find.

 

THANKS!

I never knew about this either - one more great piece of software by Carol Shaw. Is it safe to assume then, that this is not using the FP in ROM? I suppose I should just download it and set some breakpoints in the emu.

[norbert_kehrer]

Hi,

 

I recently ported the Atari Calculator to the C64 (download will be available soon), so I know some of the internals of the program.

 

The program intensively uses calls to the FP routines in ROM and seems to completely build onto them. I checked some algorithms (e.g. the one for the square root), and saw that Calculator uses more or less the same method as the Atari Basic interpreter in the 800 XL.

 

Nonetheless, a very nice program which was fun to analyze and port. I will keep you posted about the download link for the preliminary C64 version if someone is interested.

 

Greetings

 

Norbert

[thorfdbg]

<p>

The program intensively uses calls to the FP routines in ROM and seems to completely build onto them. I checked some algorithms (e.g. the one for the square root), and saw that Calculator uses more or less the same method as the Atari Basic interpreter in the 800 XL.

 

Kind of what I suspected - they only "polish" the output to fit to the expectations of the user, but do not use any better math routines to provide better precision.

[Mathy]

Hello guys

 

If she did or didn't depends on your definition of "polish'.

 

There's two kinds or mathematics. The one they usually teach and the second one. Called numerical mathematics. IIRC it's usually only taught at universities.

 

With "normal" mathematics, you can get all kinds off errors, because for instance working with 100 decimals is nearly impossible.

 

What numerical mathematics does, is (among other things) find/use methods to prevent these errors from happening. But to do so, it still needs normal mathematics. And that's probably what Norbert has seem happening in Atari Calculator. Carol used numerical mathematics to reduce the (size/amount of) errors and heavily relies on the standard mathematical routines inside the Atari to do so.

 

So in a sense she did polish the results. But she did so by using scientifically proven methods that are known as "numerical mathematics".

 

Sincerely

 

Mathy

[thorfdbg]

If she did or didn't depends on your definition of "polish'.

 

I'll give a definition in a minute, and I'll explain why I'm skeptical about the results. But first, let me remark that I'm a mathematician, so I hopefully know what this is about - or at least I believe so. Thus a bit of numerics is part of my education at least, though I'm certainly not the ultimate expert on the field.

 

So here is what I consider improper polishing: Do you know how Atari BASIC Rev.B and C arrive at the correct result of 4^4? They first use the (mathematical identity) a^b = exp(log(a)*b), feed this into the mathpack as it is, and get as result 255.9.. something. Now they notice, "oops, we had two integers, so the result should be integer". And they round up to the next larger (!) integer, which is 256. Always the *next larger* integer.

 

Why is this an improper polishing? Very simple: a) the algorithm fails should the underlying numerics of the math pack come up with a result that is actually *more precise* but happens to be just a bit larger than 256. Atari BASIC is then returning 257. Ooops! b) the algorithm has undesirable properties, as for example not ensuring that f(x) = a^x is actually monotonic. If you apply 4^X with X *just a little* larger than four, but non-integer, the stupid BASIC will return a number a bit smaller than 256, and will *not* round up, because the argument is not an integer. Which can have very undesirable side effects if this is part of a longer simulation or a scientific computation. So 4^x does not grow always if x grows. Oops! c) because there are actually algorithms that are known to be numerically stable (unlike what they did) that do return better answers - in the sense that integer powers of integers return integers, but without being the result of "polishing". A "polish" is thus an improper mathematical method applied to an end result to make it look nicer - even though the actual math behind the improvement made the algorithm overall much worse. If your approximation of 4^4 returns 255.997, then please return that and don't try to lie to the user by making it appear nicer than it is. The numerics behind it was bad in first place, and no later fix can improve it.

 

Same *probably* goes to the Atari calculator, though I don't know: *If* the math pack is used, then the result of CLOG(1) is *not* zero. No matter how hard you try. That it is a defect in the math pack, and not a defect in the caller. You can notice "oops, the result is a power of ten", and then provide the right answer afterwards, but again, such a kind of "polish" will destroy some of the properties of the CLOG, as for example that it is monotonic and has no jumps. Such defects can kill any serious application.

 

The *correct* way of doing it is to use a better and more careful implementation of CLOG, and not to twiddle with the end result.

 

I can certainly not claim of doing exactly everything right - and there is more than one thing that is broken with the Atari mathpack and the BCD format it depends on, but at least one thing: CLOG(1) *is* zero. And not because I observe the argument and the result, but because the actual polynomial approximation is done in a (slightly) better way. There are certainly even better ways to compute the approximation of CLOG, but that's likely as good as it goes with the ROM space as limited as it is.

 

Hope this helps what I mean.

Edited June 19, 2013 by thorfdbg

[Faicuai]

(...)

 

The *correct* way of doing it is to use a better and more careful implementation of CLOG, and not to twiddle with the end result.

 

I can certainly not claim of doing exactly everything right - and there is more than one thing that is broken with the Atari mathpack and the BCD format it depends on, but at least one thing: CLOG(1) *is* zero. And not because I observe the argument and the result, but because the actual polynomial approximation is done in a (slightly) better way. There are certainly even better ways to compute the approximation of CLOG, but that's likely as good as it goes with the ROM space as limited as it is.

 

(...)

 

 

 

Not even touching the depth of your detailed (and thoughtful) ordeal, it would only take performing (1/9)*9 to realize what is happening:

 

1. Atari basic outputs 0.999999999, which seems correct for (10?) digits BCD.

2. The HP-48GX outputs 0.99999(...) even up to twenty (20) digits, via LongFloat arbitrary precision library.

3. Now, AtariCalculator outputs 1 (which is analytically correct, but NOT numerically, because results have to be correct to the underlying precision DIGITS for the computation!)

 

At the end of the day, the most important and critical FP calaculations are (most likely in the following order): 1) Addition, 2) Subtraction, 3) Multiplication, 4) Division, and 5) Rounding.

 

 

Another interest test is a simple Transcendental functions test: SIN(Pi-delta), which turns out to be delta, for a sufficiently small delta. For example:

 

if you calculate SIN(3.141592 = Pi - 0.00000065358979...) on the 48GX, amazingly you get 6.53589793238E-7, which is nothing but all extra digits of Pi, precise to twelve (12) digits! If you perform SIN(3.14159265358 = Pi - 0.000000000009.79323846264...) you get 9.79323846264E-12, yielding in yet another 12-digits precise computation (like the 48GX would be tracking Pi to "24 digits", internally). That is pretty impressive.

 

Now, if you try that on Atari Basic, you will notice that you only get "real' stuff up to Sin(3.1415). Past that point, the rest of non-sense (that is 5 or 6 digits correct, best-case).

 

Now, if you try the same with AtariCalculator, you get:

 

Sin(3.1415)= 9.2645567E-05, which is precise to the first three digits (total of 8 digits correct)

Sin(3.14159) = 2.6546458E-06, which is precise to the first three digits (total of 9 digits correct, the third one most likely a "ricochet")

Sin(3.141592) = 6.4402649E-07, which is precise to the first digit (total of 8 digits correct).

 

There seem to be important differences between AtariCalculator and (say) Atari Basic, for sure, probably routed on rounding, polynomial approximation, etc.

 

More testing may be needed to develop a better picture, though.

Edited June 20, 2013 by Faicuai

[+Larry]

I searched a bit and found the "FASTMATH.ROM" image. Applied it to an 800XL and got a time of 117.167; accuracy of 0.0139; ramdom of 10.768.

 

Not a "scorcher," but compares competitively with other math pack enhancements, and certainly way better than the original math pack results of about 405 seconds.

 

-Larry

[thorfdbg]

Not even touching the depth of your detailed (and thoughtful) ordeal, it would only take performing (1/9)*9 to realize what is happening:

 

1. Atari basic outputs 0.999999999, which seems correct for (10?) digits BCD.

The question mark is one of the problems of the mathpack. Actually, it is not a base-ten representation, but a base-100 representation. Thus, you have 5 digits of base 100, which makes it between 10 and 9 digits of base 10. Of course, then less precise by (depending on the number) a true base-10. Or less precise than a base-2, though round-off when converting to and from human readable is less.

 

 

2. The HP-48GX outputs 0.99999(...) even up to twenty (20) digits, via LongFloat arbitrary precision library.

3. Now, AtariCalculator outputs 1 (which is analytically correct, but NOT numerically, because results have to be correct to the underlying precision DIGITS for the computation!)

It depends on what they are doing here. The story above does not end there. Actually, depending on the number format, if you *round* correctly, you can keep the precision. Neither the mathpack nor BASIC round correctly, but here is at least some theory behind it: If you use binary math (as in IEEE numbers, found in almost all today's chips) and keep the right number of extra bits in precision (I believe one round bit, one guard bit and one sticky bit), then one can prove that algorithmic operations like +,-,*,/ return the "right" result after rounding the three extra bits away. That is, if you assume that your input had infinite precision, and all the extra bits *not* present in the mantissa were zero, and then you perform the add or subtract *with* the three extra bits, the output is again correct up to the input precision.

 

Of course, neither the math-pack nor BASIC do that, and while there might be a result like this for BCD arithmetic, I at least do not know it. In any case, what I believe happens here most likely is just traditional round-off of the last digit, which works probably ok most the time, but does not give you results as strong as the above.

 

At the end of the day, the most important and critical FP calaculations are (most likely in the following order): 1) Addition, 2) Subtraction, 3) Multiplication, 4) Division, and 5) Rounding.

Everything else is typically derived from that. Ok, there is a nice binary square-root algorithm, and there are CORDIC algorithms for the transcendental functions, but these are rarely used today as polynomial approximation is usually faster and as precise as it.

 

 

Another interest test is a simple Transcendental functions test: SIN(Pi-delta), which turns out to be delta, for a sufficiently small delta. For example:

 

if you calculate SIN(3.141592 = Pi - 0.00000065358979...) on the 48GX, amazingly you get 6.53589793238E-7, which is nothing but all extra digits of Pi, precise to twelve (12) digits! If you perform SIN(3.14159265358 = Pi - 0.000000000009.79323846264...) you get 9.79323846264E-12, yielding in yet another 12-digits precise computation (like the 48GX would be tracking Pi to "24 digits", internally). That is pretty impressive.

Actually, not so much if you think about how a sin() is usually implemented. What you typically do first is to reduce the argument to the range from -Pi/2 to Pi/2 (otherwise reflect, or compute the cos). That gives you sin(pi-x) = sin(x), which is the very first step. Then, the very next step in a sane enough implementation is to test whether x is small enough, and if so, return x directly without further calculation. So in effect, the only thing the above test tests is for the internal implementation precision of Pi, at least for the numerical implementations of sin() I know of. (And there is CORDIC, which is a different hourse, but in this case it would only give you the precision of the lookup tables).

 

Atari BASIC screws it by actually using the Taylor polynomial, which is a) not the correct mathematical tool for getting a good precision over a longer interval, and b) they use way too many coefficients, thus it is a lot slower than necessary. But sin() is not in the math-pack, except for the generic Horner-scheme polynomial approximation. This part is actually fine, except for the elementary math it is based on.

[ClausB]

I searched a bit and found the "FASTMATH.ROM" image. Applied it to an 800XL and got a time of 117.167; accuracy of 0.0139; ramdom of 10.768.

 

Not a "scorcher," but compares competitively with other math pack enhancements, and certainly way better than the original math pack results of about 405 seconds.

 

I tried your Ahl benchmark on regular Atari BASIC with the FAFMUL triple-speed multiplier patch (http://atariage.com/...m/#entry1508306) and got a time of 222.5 sec and an accuracy of 0.004044.

[Faicuai]

Some quick tests here:

1. Atari Basic (XL), Fast-FP XL ROM, AnticDMA = OFF, ran in ~46.36 secs, with Error 0.013649, and Random Sum = 7.179418. Precision-wise, seems tens time less precise than ClausB, albeit much faster.
    
   
2. TurboBasic (XL), Fast-FP XL ROM, AnticDMA = OFF, ran in ~26.71 secs, with Error 0.013649.
   

 

Here is the XL rom (for Altirra or 800-Incognito): AtariOS-800XL-fastmath.rom

 

 

Here is the code (you can copy-and-paste in Altirra 2.30):

 

100 REM AHL FLOATPOINT BENCHMARK

180 DMA=559:ANTICON=34:ANTICOFF=0

190 RPT=100:TH=19:TL=20:A=0:R=0:E=0

200 REM

210 GRAPHICS 0:POKE DMA,ANTICOFF

220 POKE TL,0:POKE TH,0

230 FOR N=1 TO RPT:A=N

240 FOR I=1 TO 10:A=SQR(A):R=R+RND(0)

250 NEXT I

260 FOR I=1 TO 10:A=A*A:R=R+RND(0)

270 NEXT I

280 E=E+A:NEXT N

290 REM

300 TL=PEEK(TL):TH=PEEK(TH)

310 ? "TIME: ";(256*TH+TL)/60;" SEC"

320 ? "ERROR: ";ABS(1010-E/5)

330 ? "RND: ";ABS(1000-R)

340 POKE DMA,ANTICON

 

 

I will later unroll the inner loops, and see how much time goes down... But precision is not good enough, as it is, though. Not what you would expect out of 8-10 BCD digits.

[Faicuai]

(...) So in effect, the only thing the above test tests is for the internal implementation precision of Pi, at least for the numerical implementations of sin() I know of. (...)

 

 

Not necessarily, because it does help testing most of your assumptions or implementation observations (above), from one system to another... Cases like sin( ) are particularly important or difficult when hovering a "zero" argument either from "above" (slight higher than zero) or from "below" (slightly lower than Pi).

 

I intuivitely think that something is wrong with Atari's ROM FP rounding code, besides other embedded numerical code / approximations. AHL's benchmark is yielding in abysmal performance for a 8-10 BCD digits system. Edit: Even a cyclic 1/(1/7) or 1/(1/9) will come back to "7" or "9" exact, which seems really odd in a limited-precision BCD system.

[JamesD]

Some quick tests here:

1. Atari Basic (XL), Fast-FP XL ROM, AnticDMA = OFF, ran in ~46.36 secs, with Error 0.013649, and Random Sum = 7.179418. Precision-wise, seems tens time less precise than ClausB, albeit much faster.
    
   
2. TurboBasic (XL), Fast-FP XL ROM, AnticDMA = OFF, ran in ~26.71 secs, with Error 0.013649.
   

IF someone were writing a small scientific app to calculate something that might take hours or days... yeah I can see someone turning off Antic DMA back in the 80s. But it's not an indicator of typical performance.

How many applications can get away with turning Antic DMA off?

 

Unrolling loops, etc... may be faster but just remember you can only get away with so much of that sort of thing if you are writing a large program or you run out of memory and if you intend to compare the results against other machines you have to give the other machines the same leeway.

FWIW, I helped someone optimize the setup routine in an MC-10 program recently and through combining lines, unrolling an inner loop, etc... the 20+ second startup dropped to under 5 seconds. So, I don't have a problem with such optimizations in general, I just don't think fine tuning benchmarks is appropriate... at least not beyond comparing two math libs anyway.

[Faicuai]

So here is a really simple (yet revealing) basic program that basically performs C=1/(1/n) for n=1...100, and calculates the Error/Delta as (C-n). C should, in reality, be a VERY close number to n, for any n (for the most part, as some cases will yield in exact inverse).

 

So here's the code (easy to port to ANY platform):

 

100 REM FP ARITHMETIC ROUNDING TEST

180 A=1:B=0:C=0:E=0:N1=1:N2=100

200 REM

210 GRAPHICS 0:FOR N=N1 TO N2:C=N

220 C=A/C:C=A/C:E=E+ABS(N-C)

230 ? "N: ";N;" ERROR: ";(N-C)

250 NEXT N

260 ? "CUMULATIVE ERROR: ";E

 

And here's is Atari Basic (XL-ROM Rev2) output (notice how LARGE the errors become past n=35):

N: 1 ERROR: 0

N: 2 ERROR: 0

N: 3 ERROR: 0

N: 4 ERROR: 0

N: 5 ERROR: 0

N: 6 ERROR: 0

N: 7 ERROR: 0

N: 8 ERROR: 0

N: 9 ERROR: 0

N: 10 ERROR: 0

N: 11 ERROR: 0

N: 12 ERROR: 0

N: 13 ERROR: 0

N: 14 ERROR: 0

N: 15 ERROR: -1E-08

N: 16 ERROR: 0

N: 17 ERROR: 0

N: 18 ERROR: -1E-08

N: 19 ERROR: -1E-08

N: 20 ERROR: 0

N: 21 ERROR: 0

N: 22 ERROR: -2E-08

N: 23 ERROR: -3E-08

N: 24 ERROR: -3E-08

N: 25 ERROR: 0

N: 26 ERROR: -4E-08

N: 27 ERROR: -2E-08

N: 28 ERROR: -1E-08

N: 29 ERROR: -1E-08

N: 30 ERROR: -3E-08

N: 31 ERROR: -1E-08

N: 32 ERROR: 0

N: 33 ERROR: 0

N: 34 ERROR: 0

N: 35 ERROR: -8E-08

N: 36 ERROR: -1.0E-07

N: 37 ERROR: -3E-08

N: 38 ERROR: -1.0E-07

N: 39 ERROR: -6E-08

N: 40 ERROR: 0

N: 41 ERROR: 0

N: 42 ERROR: -1E-08

N: 43 ERROR: -9E-08

N: 44 ERROR: -5E-08

N: 45 ERROR: -4E-08

N: 46 ERROR: -7E-08

N: 47 ERROR: -9E-08

N: 48 ERROR: -7E-08

N: 49 ERROR: -1.5E-07

N: 50 ERROR: 0

N: 51 ERROR: -9E-08

N: 52 ERROR: -8E-08

N: 53 ERROR: -7E-08

N: 54 ERROR: -5E-08

N: 55 ERROR: -2.4E-07

N: 56 ERROR: -1.7E-07

N: 57 ERROR: -1.5E-07

N: 58 ERROR: -3E-08

N: 59 ERROR: -1.4E-07

N: 60 ERROR: -2.4E-07

N: 61 ERROR: -8E-08

N: 62 ERROR: -2.2E-07

N: 63 ERROR: -2.8E-07

N: 64 ERROR: 0

N: 65 ERROR: -3.5E-07

N: 66 ERROR: -2.2E-07

N: 67 ERROR: -1.5E-07

N: 68 ERROR: -2.4E-07

N: 69 ERROR: -1.1E-07

N: 70 ERROR: -4.2E-07

N: 71 ERROR: -2.1E-07

N: 72 ERROR: -4.6E-07

N: 73 ERROR: -1.9E-07

N: 74 ERROR: -7E-08

N: 75 ERROR: -1.8E-07

N: 76 ERROR: -2.1E-07

N: 77 ERROR: -5.1E-07

N: 78 ERROR: -1.2E-07

N: 79 ERROR: -3.0E-07

N: 80 ERROR: 0

N: 81 ERROR: -8E-08

N: 82 ERROR: -3.4E-07

N: 83 ERROR: -4.8E-07

N: 84 ERROR: -3E-08

N: 85 ERROR: -5.9E-07

N: 86 ERROR: -5.6E-07

N: 87 ERROR: -5.5E-07

N: 88 ERROR: -4.9E-07

N: 89 ERROR: -4.4E-07

N: 90 ERROR: -9E-08

N: 91 ERROR: -7.3E-07

N: 92 ERROR: -1.4E-07

N: 93 ERROR: -6.2E-07

N: 94 ERROR: -6.3E-07

N: 95 ERROR: -8.0E-07

N: 96 ERROR: -6.1E-07

N: 97 ERROR: -4.7E-07

N: 98 ERROR: -3.1E-07

N: 99 ERROR: 0

N:100 ERROR: 0

 

CUMULATIVE ERROR: 1.471E-05

 

 

I will later port the above code to the 48GX and run the test using LongFloat library set to an arbitrary precision of nine (9) digits which should be pretty close to Atari's FP math, and come back with such results.

 

All in all, I am seeing PRETTY LARGE errors on the above list, though, assuming ~9-10 digits BCD math.