Random Numbers

[KevKelley]

I was curious as to the random number generation. I had usually based everything off of the chart on Random Terrain’s website. I had read various posts on the generation but was wondering if the chart was just examples or if the generation is limited to just those numbers. 
 

I was playing around with some values and seemed to have it still work as expected in the new range but was wondering if there was a reason that I did not understand. 

[KevKelley]

For example, instead of doing temp5=(rand&31) use temp5=(rand&27)…

[+Random Terrain]

I was confused about it back in 2008:

 

https://forums.atariage.com/topic/124529-magic-with-rand-and/?do=findComment&comment=1504667

 

[+SpiceWare]

1 hour ago, KevKelley said:

For example, instead of doing temp5=(rand&31) use temp5=(rand&27)…

 

You can use a spreadsheet to see what happens. I threw this together using the free LibreOffice^*.

 

bitwise and.ods

 

Change the & value in B1. The values you'll get back are in the yellow columns.

 

 

 

^* OpenOffice should work as well. I used to use it but switched. I believe it was due to @Thomas Jentzsch posting this topic, OpenOffice wouldn't show the colorized results at the time (it might now).

 

 

[KevKelley]

3 hours ago, Random Terrain said:

I was confused about it back in 2008:

 

https://forums.atariage.com/topic/124529-magic-with-rand-and/?do=findComment&comment=1504667

 

I never really questioned it before and just accepted it as some quirk of the Atari. But I was tweaking some values like adding or subtracting to the randomly generated number and couldn’t quite get the effect I was looking for. But I was bored so I messed with the random statement directly and changed a (rand&7) to a (rand &8) and it seemed to make the difference.

 

I continued to add and subtract to it and to my untrained eye it seemed to work but I was curious if I was missing something. I read the forums and couldn’t really understand some of the finer points in the previous posts while I read on my lunch. 

[KevKelley]

3 hours ago, SpiceWare said:

 

You can use a spreadsheet to see what happens. I threw this together using the free LibreOffice^*.

 

bitwise and.ods 29.38 kB · 0 downloads

 

Change the & value in B1. The values you'll get back are in the yellow columns.

 

 

 

^* OpenOffice should work as well. I used to use it but switched. I believe it was due to @Thomas Jentzsch posting this topic, OpenOffice wouldn't show the colorized results at the time (it might now).

 

 

Thanks! I just saw your response. I will have to play with it and see what gets the best results. I kind of understand what’s going on seeing a chart. It was just one of those lingering questions I always had that never really needed asked until I finally messed with it. 

[+Random Terrain]

47 minutes ago, KevKelley said:

I never really questioned it before and just accepted it as some quirk of the Atari. But I was tweaking some values like adding or subtracting to the randomly generated number and couldn’t quite get the effect I was looking for. But I was bored so I messed with the random statement directly and changed a (rand&7) to a (rand &8) and it seemed to make the difference.

 

I continued to add and subtract to it and to my untrained eye it seemed to work but I was curious if I was missing something. I read the forums and couldn’t really understand some of the finer points in the previous posts while I read on my lunch. 

 

Did you see this part on the bB page:

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#random_sprite_placement

 

If you need a number range that isn't included in one of the choices in the list, you select ones that add up to what you want. For example, if you need a number between 0 and 8, you'd use (rand&7) + (rand&1).

[+Karl G]

It is difficult to explain without breaking the numbers down into their binary forms. Without modifying the rand result, you get a number between 0 and 255, which means any of the eight bits in the number can be either 0 or 1. When you do a logical AND (&) to the result, you are deciding which of these bits you are forcing to be 0, which restricts the value of the random number. The number 7 in binary is %00000111. So, if you do a (rand&7), then all of the bits except for bits 0, 1, and 2 will be 0 in value, and the remaining bits can be either 0 or 1, depending on the random value of the initial number. This gives a range of 0-7 as expected.

 

Now, the number 8 in binary is %00001000. If you do a (rand&8), then all of the bits in the result will be 0 except for bit 3, which may be either 0 or 1 depending on the randomly-generated number. This means that about half the time (rand&8) will give a result of 8, and half the time (rand&8) will give a result of 0, with no other numbers being possible.

 

I hope this makes sense. I'm not sure how well I'm explaining it.

[KevKelley]

1 hour ago, Random Terrain said:

 

Did you see this part on the bB page:

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#random_sprite_placement

 

If you need a number range that isn't included in one of the choices in the list, you select ones that add up to what you want. For example, if you need a number between 0 and 8, you'd use (rand&7) + (rand&1).

That is what I actually used as reference in my game and define one of the temp values using to random numbers but I was messing around with it to get better distribution. 
 

 

[KevKelley]

35 minutes ago, Karl G said:

It is difficult to explain without breaking the numbers down into their binary forms. Without modifying the rand result, you get a number between 0 and 255, which means any of the eight bits in the number can be either 0 or 1. When you do a logical AND (&) to the result, you are deciding which of these bits you are forcing to be 0, which restricts the value of the random number. The number 7 in binary is %00000111. So, if you do a (rand&7), then all of the bits except for bits 0, 1, and 2 will be 0 in value, and the remaining bits can be either 0 or 1, depending on the random value of the initial number. This gives a range of 0-7 as expected.

 

Now, the number 8 in binary is %00001000. If you do a (rand&8), then all of the bits in the result will be 0 except for bit 3, which may be either 0 or 1 depending on the randomly-generated number. This means that about half the time (rand&8) will give a result of 8, and half the time (rand&8) will give a result of 0, with no other numbers being possible.

 

I hope this makes sense. I'm not sure how well I'm explaining it.

I think I follow. It is still a little out there for me but seeing the binary definitely helps put things into context. 

[+Random Terrain]

1 hour ago, KevKelley said:

That is what I actually used as reference in my game and define one of the temp values using to random numbers but I was messing around with it to get better distribution. 

 

Even when using rand16 or DPC+, it seems that using only division or only AND (&) from the chart can create visible patterns sometimes. If you notice a pattern when using AND, mixing in a little division should get rid of the patterns.

 

So instead of (rand&63) + (rand&31) + (rand&15) + (rand&1) you might try (rand/4) + (rand&31) + (rand&15) + (rand&1).

[KevKelley]

7 hours ago, Random Terrain said:

 

Even when using rand16 or DPC+, it seems that using only division or only AND (&) from the chart can create visible patterns sometimes. If you notice a pattern when using AND, mixing in a little division should get rid of the patterns.

 

So instead of (rand&63) + (rand&31) + (rand&15) + (rand&1) you might try (rand/4) + (rand&31) + (rand&15) + (rand&1).

What got me started looking at this was that I was working on my Crossdock game. When the box comes off the conveyor belt a box should appear on the floor. My original set up of a couple rand&whatever commands did okay but after I ran it for a while I noticed that it did not take generate a box in certain spots. I also ran into the issue where if it were to pick coordinates where a box already existed it would not place a box (but that was because I had no further checks). 
 

I started messing with the rand commands to get more boxes generated. I think for the most part I don’t see any discernible patterns but it was neat playing with the different options because some of them would make clear patterns. To get the most out I tweaked the rand numbers and added a pfread so that if a box shares the generated coordinates it moves it over by one. I wanna mess with it a little more just so I get a better understanding of those charts above but at least I have an answer to one of those questions in the back of my mind. 

[+SpiceWare]

As @Karl G says it helps to see the values in binary, so I've added a 2nd tab that shows the numbers in binary.

 

bitwise and.ods

 

Set the & value on the Decimal tab:

 

 

Switch to the Binary tab to see the decimal values in binary.  To help with the analysis, the & value has been cloned to the tops and bottom of each result column.

 

 

 

 

[KevKelley]

Thank you again @Random Terrain, @Karl G, and @SpiceWare

 

After looking over the spreadsheets it was very enlightening to see the distribution of the "random" numbers and how they work and I can see some application of using the oddball numbers depending on what outcome desired, but it was interesting to play with this and substitute the various values into my game to see how well the pixels generate, if any discernible pattern can be seen, etc. 

 

I am just trying to fine tune some things and am combing through all the lines of code in some of my games and this was one area where I wondered if I could save a little space or do things a little better and it actually helped come up with a little better in the end and hopefully makes for a more enjoyable game!