CPCWiki forum
General Category => Programming => Topic started by: johnlobo on 12:31, 14 August 21

Hi,
I'm generating in assembler a pseudo random number of one byte (0 to 255) , but a need to limit the result to a number between 0 to 41.
Is there an easy way to do this?? I'm trying to avoid to include a routine to calculate the modulus just for this.
Regards.

Maybe you can compare with highest value, and substract it if carry (for example)
;; assuming 'a' register already has random calculated number
ld b, #42 ;; highest value + 1
cp b
jr c, _returnValue
sub b
_returnValue:
ld l,a
ret

Modulo?

Thanks for the answer, but I think that this method only works while the random number is lower than 84, becasue if it's higher than that, when you substract 42 (sub b), you get a number higher than 41... so, the result it's out of range, isn't it??
Maybe you can compare with highest value, and substract it if carry (for example)
;; assuming 'a' register already has random calculated number
ld b, #42 ;; highest value + 1
cp b
jr c, _returnValue
sub b
_returnValue:
ld l,a
ret

If you just do a modulo then the result won't be truly random. Since 255 isn't an even multiple of 42 some output values will have a slightly higher probability than others. Ie. 42*6 = 252. So the values 252..255 will modulo to a value of 0..3 (if you repeatedly modulo until in range). Thus 03 will have a higher probability of being generated than 441.
You can try dividing the initial RNG output, but with an 8bit RNG the resolution won't be great  you may want to consider using a 16bit one.
The other option would be to generate another number if the output isn't in range. This obviously carries a time penalty.
The compromise might be to rerun for number >= 252 and modulo any other value.
(All of which depends on your need for randomness and your need for speed).

If you're not too worried about the weighting being uneven, you could discard the top 2 bits (so you end up with a number between 063) and take away 42 if it's greater than 42... I suppose you could also use the discarded bits to choose 4 different strata of number to subtract between 2142 and reduce the impact of the otherwise obvious weighting.

Thanks for the answer, but I think that this method only works while the random number is lower than 84, becasue if it's higher than that, when you substract 42 (sub b), you get a number higher than 41... so, the result it's out of range, isn't it??
Of course, sorry, that's my fault.
Out of modulus, I think as @Bread80 (https://www.cpcwiki.eu/forum/index.php?action=profile;u=4222) has said, generate another random number if the output is out of range may be a possibility.
Even better, discard top 2 bits as @Cwiiis (https://www.cpcwiki.eu/forum/index.php?action=profile;u=3482) suggested looks fine to me.

If you already have a 8x8bit multiplication, just multiply the random number by 42, and keep the MSB of the result.

SpDizzy almost had it:
Label the "Dec b" as "_loop", and put "jr , _loop" after the "sub b"
Now the routine will loop until the value in a is less than 42.

SpDizzy almost had it:
Label the "Dec b" as "_loop", and put "jr , _loop" after the "sub b"
Now the routine will loop until the value in a is less than 42.
Oh my bad, just as simple as that! Time for me to go to bed...
;; assuming 'a' register already has random calculated number
ld b, #42 ;; highest value + 1
_loop:
cp b
jr c, _returnValue
sub b
jr _loop
_returnValue:
ld l,a
ret

Yes, now it works.
If I don't find anything more accurate, I'll go with this.
Thank you.
SpDizzy almost had it:
Label the "Dec b" as "_loop", and put "jr , _loop" after the "sub b"
Now the routine will loop until the value in a is less than 42.

Yes I have implemented 8x8 multiplication... I will try this too.
Thank you.
If you already have a 8x8bit multiplication, just multiply the random number by 42, and keep the MSB of the result.

@SpDizzy (https://www.cpcwiki.eu/forum/index.php?action=profile;u=2740)
Oh my bad, just as simple as that! Time for me to go to bed...
I have those kind of days too :D

Would this also work?
Create a random 8 Bit number, get the upper 3 bits 07 and the lower 5 bits 031, add these values (038) and finally add the lowest 2 bits (03) of register R. That should give you a number between 041.

@eto (https://www.cpcwiki.eu/forum/index.php?action=profile;u=3625): That's an interesting and novel approach :D
It should work ok, and if the OP isn't using R for his random number, it will add an "extra randomness" to the bottom 2 bits.

Would this also work?
Create a random 8 Bit number, get the upper 3 bits 07 and the lower 5 bits 031, add these values (038) and finally add the lowest 2 bits (03) of register R. That should give you a number between 041.
It will give you a number in the right range, though I suspect the distribution won't necessarily be very even.

@andycadley (https://www.cpcwiki.eu/forum/index.php?action=profile;u=327) Real random numbers aren't evenly distributed anyway, just take a look at a lottery draw: there are often "clumps" of numbers at one end or in the middle. :D

Indeed. But a property of a "good" random number routine is usually that it gives a reasonably even distribution over a long enough sample set, "clumps" can lead to results seeming too predictable or pattern like.
Obviously it depends what you're doing. Sometimes good enough is all it needs.

Real random numbers aren't evenly distributed anyway,
then they are not good random numbers. At least when the sample size is big enough, the random numbers should be (almost) evenly distributed.

though I suspect the distribution won't necessarily be very even.
can you share why? The only thing I see could be R, but at least if the random number generation is not at predictable times, R should be "random" enough to ensure the even distribution as long as the random number generator is good. I'd love to test this now, but I don't have access to my machine right now, as I'm on vacation.

I have tested both @eto (https://www.cpcwiki.eu/forum/index.php?action=profile;u=3625) 's method and SpDizzy's ( as modified) and ego's is slightly more effective at being random.

I have tested both @eto (https://www.cpcwiki.eu/forum/index.php?action=profile;u=3625) 's method and SpDizzy's ( as modified) and ego's is slightly more effective at being random.
In cases where speed is highly compromised, @eto (https://www.cpcwiki.eu/forum/index.php?action=profile;u=3625)'s method always take same amount of microseconds and is a bit faster, whereas mine could be slightly slower for bigger numbers, since you are repeating the loop until random number is below 42. On respect to size, I guess eto's takes 3  4 bytes more.

can you share why? The only thing I see could be R, but at least if the random number generation is not at predictable times, R should be "random" enough to ensure the even distribution as long as the random number generator is good. I'd love to test this now, but I don't have access to my machine right now, as I'm on vacation.
Yes, largely because of R which has a habit of introducing predictability to RNGs. As you say, it may not make a difference though and you'd have to try it out to see for sure.

Yes, largely because of R which has a habit of introducing predictability to RNGs.
All pseudo random generators generate predictable sequences (unless you are using a different seed every time but then also R is no longer an issue I guess).

Just to be sure, do you guys know about this article about generating pseudorandom numbers (https://64nops.wordpress.com/2021/02/07/pseudorandomnumbergenerators/), written by @Grim (https://www.cpcwiki.eu/forum/index.php?action=profile;u=123) ?

I have tested both @eto (https://www.cpcwiki.eu/forum/index.php?action=profile;u=3625) 's method and SpDizzy's ( as modified) and ego's is slightly more effective at being random.
Maybe combine them? In case the original number is below 42, use it. If not, apply my method. Or would that change the distribution of numbers?
(btw: my approach is not flexible. It works well for THIS scenario, but not for any range)