Not so much a bug, as slow!

[einar]

Anyway, I've found a floating point library. It is faster, but a bit less precise (it's like the traditional Ansi C IEEE FP library, 4 bytes per float, not 5). I guess I can implement it, and will be much faster, a bit less precise (but enough for most purposes), and take more memory.

In case the FP library mentioned above was not added to ZX BASIC yet, I would like to provide my 2 cents about this idea...

It seems ZX BASIC is used almost exclusively for games, assuming this list is accurate enough:

<!-- m --><a class="postlink" href="http://www.boriel.com/wiki/en/index.php/ZX_BASIC:Released_Programs">http://www.boriel.com/wiki/en/index.php ... d_Programs</a><!-- m -->

Notice that games almost never use FP for performance reasons, except to calculate INT (RND * n) typically. Also it's important for games to save as much memory as possible. Because of this, my suggestions are:

• Change the ZX BASIC builder so it will only include the FP library if the program really uses FP somehow;
  
  
  
• To avoid INT(RND * n) from forcing the builder to include the FP library (and probably also to optimize compiled code), change RND to accept an optional parameter, such that using RND(n) will return an UINTEGER value between 0 and n-1, and just using RND without parameters will return a FLOAT value as before. Alternatively, if this dual behavior would be a problem for the parser, then provide instead a new function INTRND(n) that works as I described here.

Makes sense?