FB: Floating Point Arrays

[Quiver]

Trying to learn FastBasic by working through the book "Your Atari Computer" translating the example Atari Basic programs into FB. Finally came to a program that requires floating point numbers in an array, and nothing works. I have FB puking scrolling garbage characters and no clue what I did wrong. Example of the problem follows:

DIM FPARR%(5)
FOR N=0 TO 5
  INPUT FPARR%(N)
  PRINT FPARR%(N)
NEXT N

The manual doesn't help as it gives no example of how to use floating point arrays so I have no idea how I'm violating syntax.

 

 

 

Quiver.

[vitoco]

I tried your code and it looks like you found a bug in FB. it seems that the loop index (N variable) receives part of the input data when you require a floating point variable using INPUT.

 

 

[Quiver]

This is both cool and frustrating. I'm surprised that this bug hasn't been discovered until now. I suppose this goes to show how unimportant floating point arrays are to most programming solutions for our Atari computers. I guess I'll have to set this particular programming problem aside until this bug is fixed.

[+Stephen]

There's almost never a reason to use floats on such an old machine.  With only 8-bit registers, it's not even nice working with 16-bit ints.

[vitoco]

There is something strange with the conversion of strings into float numbers.

 

This also fails:

DIM FPARR%(5)
FOR N=0 TO 5
  INPUT X$
  FPARR%(N) = VAL(X$)
  PRINT N,FPARR%(N)
NEXT N

It seems that the conversion breaks FOR loops. A stack conflict? Reuse of an internal register?

 

[dmsc]

Hi!

6 hours ago, Quiver said:

Trying to learn FastBasic by working through the book "Your Atari Computer" translating the example Atari Basic programs into FB. Finally came to a program that requires floating point numbers in an array, and nothing works. I have FB puking scrolling garbage characters and no clue what I did wrong. Example of the problem follows:

DIM FPARR%(5)
FOR N=0 TO 5
  INPUT FPARR%(N)
  PRINT FPARR%(N)
NEXT N

The manual doesn't help as it gives no example of how to use floating point arrays so I have no idea how I'm violating syntax.

 

 

Yes, you found a bug in the floating-point "VAL" function, it decremented the integer stack, but this was not needed. This in turn messed up the FOR loop.

 

I fixed it and added a new test to catch this problem: https://github.com/dmsc/fastbasic/commit/c9eed2bc0bc56b680612ac13e6c42c419ba030f5

 

Attached is a new version with the fix.

 

Have Fun!

 

fastbasic-v4.1-b5-cross-compiler.pdf fastbasic-v4.1-b5-manual.pdf fastbasic-v4.1-b5-macosx.zip fastbasic-v4.1-b5-win32.zip fastbasic-v4.1-b5.atr fastbasic-v4.1-b5-linux64.zip

[dmsc]

Hi!

12 minutes ago, vitoco said:

There is something strange with the conversion of strings into float numbers.

 

This also fails:

DIM FPARR%(5)
FOR N=0 TO 5
  INPUT X$
  FPARR%(N) = VAL(X$)
  PRINT N,FPARR%(N)
NEXT N

It seems that the conversion breaks FOR loops. A stack conflict? Reuse of an internal register?

 

Yes, that was the problem, the stack was being incremented (the last value was popped).

 

Have Fun!

[vitoco]

8 hours ago, dmsc said:

Hi!

Yes, that was the problem, the stack was being incremented (the last value was popped).

 

Have Fun!

There is another problem not solved yet... Running my latest example, if I do not enter a valid number (int, float, exp notation), VAL() is taking a value from somewhere else. The same happens with a direct INPUT into a FP variable... there is no runtime error as in Atari BASIC ?

[Quiver]

Thanks for the patch!

 

I had also noticed this in my program translation efforts. I had simply attributed this to differences in BASIC dialects. Of course it might require the programmer of the BASIC program in question to trap this error themselves. I don't know just a thought that occurred to me.

[dmsc]

Hi!

15 hours ago, vitoco said:

There is another problem not solved yet... Running my latest example, if I do not enter a valid number (int, float, exp notation), VAL() is taking a value from somewhere else. The same happens with a direct INPUT into a FP variable... there is no runtime error as in Atari BASIC ?

Yes, FastBasic does not trap any errors, only the "ERR()" value is updated, you need to check it yourself.

 

This code will retry INPUT until a valid FP value is entered:

REPEAT: INPUT A% : UNTIL ERR() = 1

Note that there is another subtle problem in the above: all errors are treated the same. This is because FastBasic compiles "INPUT A%" into " INPUT #0, TMP$ : A% = VAL(TMP$) ", so any error in the I/O call is overwritten by the error in VAL. If you want to detect I/O errors, you must input to a string first, check ERR() and then convert to INT or FP.

 

Have Fun!