Not so much a bug, as slow!

[einar]

Just to complement my previous answer... My suggestion for INTRND(n) was that the compiler would generate an Assembly code equivalent to this:

Code:

'Generate random number between 0 and n-1
function INTRND(n AS UINTEGER) AS UINTEGER
    DIM result AS UINTEGER
    DIM bits AS UBYTE
    LET bits = number of bits in value n-1
    DO
        LET result = RND MOD (1<<(bits-1))
    LOOP UNTIL (result <= n-1)
    RETURN result
end function

The reason I suggest this behavior to be generated internally by the compiler, instead of provided as a library, is as follows: If n is a constant, then the compiler will know the number of bits and replace it directly above. Otherwise, if n is not constant, then it should generate a simple routine to find out this value.

[britlion]

It doesn't automatically optimize that (and it might be interesting if it does).

Random number generators that are faster, and, sans rom probably smaller, here:

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


ZXB does use the same random stream generator (the one Patrik rak came up with), but it doesn't use it as integers natively.


The replacement function to use is randomLimit(n)

[einar]

Random number generators that are faster, and, sans rom probably smaller, here:

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

Thanks for the link! This is exactly the functionality I was looking for, except it can't skip the part that counts number of bits. So there would be still some advantage in incorporating this logic into the compiler...

BTW it seems you are always mispelling my name!

<!-- m --><a class="postlink" href="https://www.google.com.br/search?q=saukus+site:www.boriel.com/">https://www.google.com.br/search?q=sauk ... oriel.com/</a><!-- m -->

[boriel]

Random number generators that are faster, and, sans rom probably smaller, here:

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

Thanks for the link! This is exactly the functionality I was looking for, except it can't skip the part that counts number of bits. So there would be still some advantage in incorporating this logic into the compiler...

It's what Britlion said: the compiler uses RND as a float for compatibility reasons with Sinclair Basic. RND is a float between 0 and 1.

Some BASICs implements RAND(a, b) as a RANDOM integer generator, but I think it's not a good idea to extend the BASIC language anymore (like C). C is a tiny language with a huge library set which makes it very portable. On the contrary BASIC is very system-dependent, and some library functions are embedded in the language (RND, SIN, COS).

This is one of the problems I'm tackling right now: If SIN, COS, RND were libraries and not functions, development and porting to other systems would be easier (and this wouldn't change the syntax). Thus RANDOM function created by Britlion is a good example of a function that should go into a Library and not embedded in the language.

BTW RND is a function with 0 params. Try RND() instead. I discovered this in 2008! hock:

[britlion]

BTW it seems you are always mispelling my name!

<!-- m --><a class="postlink" href="https://www.google.com.br/search?q=saukus+site:www.boriel.com/">https://www.google.com.br/search?q=sauk ... oriel.com/</a><!-- m -->

OMG! Google is getting it wrong? OMG!

I sincerely apologise on their behalf.

Joking aside - Apologies. I apparently have vowel-itis.

[einar]

Joking aside - Apologies. I apparently have vowel-itis.

No problem!

[einar]

Some BASICs implements RAND(a, b) as a RANDOM integer generator, but I think it's not a good idea to extend the BASIC language anymore

OK, it makes sense!

Even so, there's still the suggestion that ZXB could internally recognize amd optimize INT(RND * n) as a special case, since this situation is quite common, should make quite a difference in performance, and this would not require any changes to the language... Although I agree that britlion's alternative is quite good.

[britlion]

If SIN, COS, RND were libraries and not functions

I just realised - you do know I did all of those as libraries in the wiki, right?
Game versions, however; not very accurate. You may want to look at stuff like <!-- m --><a class="postlink" href="http://www.andreadrian.de/oldcpu/sincos.z80">http://www.andreadrian.de/oldcpu/sincos.z80</a><!-- m --> for better versions!

[boriel]

If SIN, COS, RND were libraries and not functions

I just realised - you do know I did all of those as libraries in the wiki, right?
Game versions, however; not very accurate. You may want to look at stuff like <!-- m --><a class="postlink" href="http://www.andreadrian.de/oldcpu/sincos.z80">http://www.andreadrian.de/oldcpu/sincos.z80</a><!-- m --> for better versions!

Of course I know, britlion!!
But I meant SIN, COS, RND are part of the BASIC Syntax (there are no #include nor import sentences to use these functions in a basic program: SIN, COS, etc are part of the language). So to maintain compatibility across platforms they must be defined within the compiler backend. I'm figuring out a solution for this (and yes, your functions could be also used as in C in the future).

[boriel]

Update on this: I'm completely refactoring (again!) the main parser. This will allow more easily to do what you say and even allow people to define its own library like you propsed (that is: use your own SIN / COS version instead of the one packaged, etc).