First RND call is ignoring RANDOMIZE, subsequent calls are fine (*solved*)

[patters]

I have noticed while testing my program that the very first random number is always the same when the compiled program is loaded into an emulator. Subsequent ones are indeed random.

That first result is normal - you might think - because RND will be invoked at the same number of ticks after power-on each time. However, I use RANDOMIZE after an INPUT (which won't always be submitted at a consistent time by the user) before the first RND in the program is requested, so this should not happen. I presume this is a bug because after the first RND, it behaves as normal. If I deliberately insert a dummy RND before the RND values I need, then my program runs with the expected randomness.

Simple test case which demonstrates the issue:

Code:

#include <input.bas>

DIM i$ AS STRING
CLS
i$=INPUT(1)
RANDOMIZE
PRINT INT (RND*100) 'this number is consistent every time the emulator is launched with the tap file
PRINT INT (RND*100) 'this number will be random

When I run the tap file in Fuse on Mac OS I usually get 60 for the first random number. Very occasionally I get 61 though, so that may help for debugging. It's always those two values though. The second number will be in the range 0-99 as expected.

This issue is present in release version 1.14 and in 1.14beta9

[boriel]

I have noticed while testing my program that the very first random number is always the same when the compiled program is loaded into an emulator. Subsequent ones are indeed random.

That first result is normal - you might think - because RND will be invoked at the same number of ticks after power-on each time. However, I use RANDOMIZE after an INPUT (which won't always be submitted at a consistent time by the user) before the first RND in the program is requested, so this should not happen. I presume this is a bug because after the first RND, it behaves as normal. If I deliberately insert a dummy RND before the RND values I need, then my program runs with the expected randomness.

Simple test case which demonstrates the issue:

Code:

#include <input.bas>

DIM i$ AS STRING
CLS
i$=INPUT(1)
RANDOMIZE
PRINT INT (RND*100) 'this number is consistent every time the emulator is launched with the tap file
PRINT INT (RND*100) 'this number will be random

When I run the tap file in Fuse on Mac OS I usually get 60 for the first random number. Very occasionally I get 61 though, so that may help for debugging. It's always those two values though. The second number will be in the range 0-99 as expected.

This issue is present in release version 1.14 and in 1.14beta9

For me the numbers are not always the same, but it's true that their values are closer in every sample, hence not truly random.
I'll inspect it since I suspect there's a bug in the random number sequencer...

Please, try this beta:
http://www.boriel.com/files/zxb/zxbasic-...ta7.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...-beta7.zip
http://www.boriel.com/files/zxb/zxbasic-...-win32.zip
http://www.boriel.com/files/zxb/zxbasic-...x64.tar.gz
http://www.boriel.com/files/zxb/zxbasic-...cos.tar.gz

Also notice that 1.14.0 was officially released last weekend and fixes many bugfixes (not only those you reported).

I'll send you later probably another beta that might improve the randomize command itself.

[patters]

Thanks, yes I had seen that is was released and so I had switched over to using 1.14.
I haven't checked in detail by leaving a program running printing random stuff to the screen (to see if patterns emerge like with the Sinclair RND function), but 14.1beta7 does seem to have fixed the issue I reported here. Thanks!

[boriel]

Ok. I will include this change then
There was an ASM bug in the random routine and nobody noticed!
Thanks!