Floating Point Atari BASIC

[+yetanothertroll]

2 hours ago, ClausB said:

When I worked at New Dimensions in Computing in 1981 they asked me to find out why their accounting program was dropping pennies. It was in MS BASIC for CP/M on a Vector Graphic S100 system. The floating point variables were in dollars, so 0.01 dollars was not exact because of the binary representation. I added some rounding to fix it. Also sales tax percentage, 4% or 0.04, was not exact plus there were rounding rules specified in the law.

 

Atari's BCD representation would not have lost pennies, nor would have MS if the variables had been defined in cents instead of dollars.

That's why IBM and other mainframe manufacturers loved them some BCD, as did bean counters everywhere, although scaled 64 bit integer data types like M$'s Currency or bignum-like Decimal fit the bill as well. There are also modern "densely packed decimal" schemes to store three decimal digits in every ten bits to ease the space inefficiency pain.

[+yetanothertroll]

On 6/22/2024 at 11:54 PM, thorfdbg said:

"different" is an euphemism. "Many more" is more appropriate. It has serious rounding issues.

 

Is it because of the BCD or because of the six bytes, like how everyone uses 64 bit double even when 32 bit float would often do

[thorfdbg]

On 6/24/2024 at 10:32 PM, yetanothertroll said:

 

Is it because of the BCD or because of the six bytes, like how everyone uses 64 bit double even when 32 bit float would often do

Its because it arithmetic to the basis of 100. The rounding loss a number format creates depends on this basis, and larger bases have larger losses. With its base-100 arithmetic, the math pack performs considerably worse than binary implementations. Six bytes for floating point are fine. IEEE single precision only takes four, which is quite sufficient for many elementary needs.

[+yetanothertroll]

3 hours ago, thorfdbg said:

Its because it arithmetic to the basis of 100. The rounding loss a number format creates depends on this basis, and larger bases have larger losses. With its base-100 arithmetic, the math pack performs considerably worse than binary implementations. Six bytes for floating point are fine. IEEE single precision only takes four, which is quite sufficient for many elementary needs.

 

I wonder if Atari went with BCD because early electronic calculators did, and it wouldn't do for a $500-1000 home computer to have a smaller range or show different results for simple calculations than dad's fourbanger

 

http://datamath.org/EarlyArchitecture.htm

[Rybags]

The story I read is they grabbed what was used off the shelf at low or no cost rather than paying for or developing a better one.

[+yetanothertroll]

On 6/22/2024 at 5:15 AM, TGB1718 said:

I'm writing a program that will be running on a vanilla 800XL that's extensively using floating point numbers, the

data will be saved to disk. [...]

Depending on what you're doing with the data, this might be of interest to you, especially if you later want to play with 6 000, 6 000 000, or 6 000 000 000+ numbers instead of merely 600 or so

 

https://www.johndcook.com/blog/skewness_kurtosis/

 

Edit: I dun goofed. Even with the above code, expect trouble after processing only 999 999 999 numbers or so even with the OS-B mathpack. There are likely to be other gotchas

Edited Thursday at 03:27 AM by yetanothertroll
Atari floating point, how does it work

[TGB1718]

6 hours ago, yetanothertroll said:

Edit: I dun goofed. Even with the above code, expect trouble after processing only 999 999 999 numbers or so even with the OS-B mathpack. There are likely to be other gotchas

Yes, I spotted that, I'm only interested in printable numbers without the "E", and this is what I found that

the conversion process does with large numbers.

 

look what happens if you exceed that number of characters (it's not the value, it's the number of characters)

it does exactly the same thing with 9999999.99 and then make it 99999999.99

this is ok

A=1234567.99

?A
1234567.99

 

but add another number and it truncates the last character

A=12345678.99
?A
12345678.9

 

I wasn't aware it did this, it's not a limit of the value, but the floating point package is used

to convert numbers to strings for display, and I think that's where the limit comes from, the output buffer

is only big enough to accommodate 10 characters including the "."

 

Luckily that's good enough for what I'm doing

 

EDIT: just checked and the FP package uses BASIC's line buffer which is 128 bytes long at $580 to $5FF

so it's not a buffer limit, just probably the max characters the FP package will process.

 

Edited Thursday at 09:19 AM by TGB1718

[thorfdbg]

20 hours ago, yetanothertroll said:

 

I wonder if Atari went with BCD because early electronic calculators did, and it wouldn't do for a $500-1000 home computer to have a smaller range or show different results for simple calculations than dad's fourbanger

Atari Basic the math pack is part of was a quick rough job, and given the time it was developed in, it is actually quite good. But, apparently, mathematics was not quite in focus here. Also multiplication and division would have been easier in binary than in BCD.

[thorfdbg]

9 hours ago, TGB1718 said:

this is ok

A=1234567.99

?A
1234567.99

 

but add another number and it truncates the last character

A=12345678.99
?A
12345678.9

This is the result of the base 100 computation I was talking about. The mathpack can only adjust/shifts numbers by bytes, and thus pairs of digits. It adds to the rather large rounding loss of the mathpack implementation.

[+yetanothertroll]

9 hours ago, TGB1718 said:

Yes, I spotted that, I'm only interested in printable numbers without the "E", and this is what I found that

the conversion process does with large numbers.

 

look what happens if you exceed that number of characters (it's not the value, it's the number of characters)

it does exactly the same thing with 9999999.99 and then make it 99999999.99

this is ok

A=1234567.99

?A
1234567.99

 

but add another number and it truncates the last character

A=12345678.99
?A
12345678.9

 

I wasn't aware it did this, it's not a limit of the value, but the floating point package is used

to convert numbers to strings for display, and I think that's where the limit comes from, the output buffer

is only big enough to accommodate 10 characters including the "."

 

Luckily that's good enough for what I'm doing

 

EDIT: just checked and the FP package uses BASIC's line buffer which is 128 bytes long at $580 to $5FF

so it's not a buffer limit, just probably the max characters the FP package will process.

 

 

Part of it is that I've gotten a little too used to dmsc's FastBasic, which behaves differently than Atari BASIC in some ways. FB seems to be no better than BASIC at converting string to floating point, still losing that pesky tenth digit even when there's room for it in memory, but it can do accurate arithmetic involving the tenth digit in some circumstances BASIC doesn't,

 

test.rom test.bas

[+yetanothertroll]

59 minutes ago, thorfdbg said:

This is the result of the base 100 computation I was talking about. The mathpack can only adjust/shifts numbers by bytes, and thus pairs of digits. It adds to the rather large rounding loss of the mathpack implementation.

Doesn't multiplying or dividing by 10 require shifting by nybble? There's nybble shifting going on somewhere, somehow. I modified the FastBasic program to divide then multiply by 10,

' Program FPTest

 Dim Z%(2)
 
 Do

  Input "Number or Q to quit? "; X$

  If X$ = "Q" Then Exit

  Print X$; " entered"

  Z%(0) = Val(X$)
  Print Z%(0); ": ";
  @FPDump Adr(Z%) + 0

  Z%(1) = Z%(0) / 10.0
  Print Z%(1); ": ";
  @FPDump Adr(Z%) + 6

  Z%(2) = Z%(0) * 10.0
  Print Z%(2); ": ";
  @FPDump Adr(Z%) + 12

 Loop

 Print
 Print "OK"
 Get ZZ

End

Proc FPDump Za

 Data Hex() Byte ROM = "0123456789ABCDEF"

 ' Hex dump

 Print "$";
 For i = 0 to 5
  If i Then Print "'";
  j = Peek(Za + i)
  Print Chr$(Hex(1 + (j / 16)));  ' So which way of doing this is better?
  Print Chr$(Hex(1 + (j & 15)));
 Next i
 Print

 ' Quick and dirty Str$(), sort of

 Print " = ";
 If (Peek(Za) & 128) Then Print "-";
 For i = 1 to 5
  j = Peek(Za + i)
  Print $(&Hex)[1 + (j / 16), 1]; ' I have absolutely no idea whatsoever!
  Print $(&Hex)[1 + (j & 15), 1];
  If i = 1 Then Print ".";
 Next i
 Print " * 100 ^ "; (127 & Peek(Za)) - 64

EndProc

 

test.rom test.bas

[phaeron]

That's the AFP issue I had mentioned earlier. It only shifts in up to 9 digits when converting ATASCII to floating point, even in cases where a 10th digit would fit.

 

[+yetanothertroll]

28 minutes ago, phaeron said:

That's the AFP issue I had mentioned earlier. It only shifts in up to 9 digits when converting ATASCII to floating point, even in cases where a 10th digit would fit.

 

 

It's even worse than that. Even FP to ATASCII is goofy in Atari BASIC, even with integer values, while under the hood simple arithmetic appears to work,

 

10 V=VAL("9999999989")
15 W=V:? W;" ";V;" ";ABS(W-V)
20 X=W+1
30 Y=X-W
40 Z=Y-1
45 PRINT W-V;" ";
50 PRINT W;" ";X;" ";Y;" ";Z
60 IF Z<>0 THEN 90
70 W=X
80 GOTO 20
90 END

 

 

EDIT: ...well, up to a point, anyway.

 

My brain hurts

 

Edited Friday at 02:34 AM by yetanothertroll
Specialist: It will have to come out.

[thorfdbg]

10 hours ago, yetanothertroll said:

Doesn't multiplying or dividing by 10 require shifting by nybble?

It does, but the math pack does not normalize numbers by nibbles, but only by bytes. Normalizing here means that the exponents of two numbers to add or subtract are identical.

[+yetanothertroll]

On 6/28/2024 at 12:19 AM, thorfdbg said:

It does, but the math pack does not normalize numbers by nibbles, but only by bytes. Normalizing here means that the exponents of two numbers to add or subtract are identical.

I'm not sure why the base 100 thing is so bad. I've done base 100 myself when writing my own bignum code in various languages or even base 1'000'000'000 when attempting a bignum package in 8-bit Logo. I think the issues are, five bytes for the mantissa aren't a lot, and Atari went and burned the 0.9 alpha to the production OS ROMs. Maybe the 1.0 would have had ten digit conversion routines and cleaned up the rest, who knows

 

https://atariwiki.org/wiki/Wiki.jsp?page=Atari BASIC