random number between 0 and 41

[johnlobo]

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.

[SpDizzy]

Maybe you can compare with highest value, and substract it if carry (for example)

Code Select Expand

;; 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

[TotO]

Modulo?

[johnlobo]

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)

Code Select Expand

;; 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

[Bread80]

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 0-3 will have a higher probability of being generated than 4-41.


You can try dividing the initial RNG output, but with an 8-bit RNG the resolution won't be great - you may want to consider using a 16-bit 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 re-run for number >= 252 and modulo any other value.


(All of which depends on your need for randomness and your need for speed).

[Cwiiis]

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 0-63) 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 21-42 and reduce the impact of the otherwise obvious weighting.

[SpDizzy]

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 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 suggested looks fine to me.

[gerald]

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

[Animalgril987]

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]

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...

Code Select Expand



;; 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


[johnlobo]

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.

[johnlobo]

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.

[Animalgril987]

@SpDizzy

Oh my bad, just as simple as that! Time for me to go to bed...

I have those kind of days too

[eto]

Would this also work?

Create a random 8 Bit number, get the upper 3 bits 0-7 and the lower 5 bits 0-31, add these values (0-38) and finally add the lowest 2 bits (0-3) of register R. That should give you a number between 0-41.

[Animalgril987]

@eto: That's an interesting and novel approach
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.

[andycadley]

Would this also work?

Create a random 8 Bit number, get the upper 3 bits 0-7 and the lower 5 bits 0-31, add these values (0-38) and finally add the lowest 2 bits (0-3) of register R. That should give you a number between 0-41.

It will give you a number in the right range, though I suspect the distribution won't necessarily be very even.

[Animalgril987]

@andycadley  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. 

[andycadley]

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.

[eto]

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.

[eto]

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.

[Animalgril987]

I have tested both @eto 's method and SpDizzy's ( as modified) and ego's is slightly more effective at being random.

[SpDizzy]

I have tested both @eto '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'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.

[andycadley]

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.

[eto]

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).

[Targhan]

Just to be sure, do you guys know about this article about generating pseudo-random numbers, written by @Grim ?