IntyBASIC Fast Random Number Selection?

[First Spear]

What is the fast/elegant way to pick a random BACKTAB tile within a square area? In this example I want to pick one between 92/97/172/177. Should I be thinking about this in terms of "X/Y coordinates" instead of BACKTAB locations?

 

 

Thanks.

 

 

[artrag]

Maybe this

#BACKTAB(12+RANDOM(5+1)+(4+RANDOM(4+1))*20)  =  what_you_like

where 12 is the x offset, 4 is the y offset, 5 is the width and 4 is the height of the square area

Edited May 2, 2018 by artrag

[CrazyBoss]

dont know if its fast but i would use

 

92+random(6)+20*random(5)

 

but it dont seem to be very random

[intvnut]

It's a 6 * 5 area, so that has 30 squares. I'd just do something like this:

.

    idx = RANDOM(30)
    idx = idx + (idx / 6) * 19 + 92

.

 

 

When this is done, idx will be your BACKTAB index.

Edited May 1, 2018 by intvnut

[artrag]

Using a single random number is fine but it needs a modulus operator and a division

I would have used

 

(idx % 6)+idx/6*20+92

 

Where idx is random(30)

Edited May 2, 2018 by artrag

[intvnut]

Using a single random number is fine but it needs a modulus operator and a division

I would have used

 

(idx % 6)+idx/6*20+92

 

Where idx is random(30)

 

 

Since division rounds down, you don't need both division and modulus.

 

Instead, what you need is the formula I originally posted, and not the stupid edit I made after the fact. I originally posted: idx = idx + (idx / 6) * 14 + 92.

 

Notice the 14 rather than 19. I had it right, and then edited my post with that silly think-o. What was I thinking? *wipes egg from face* Anyway, if you put 14 there, it works great.

 

When idx = 6 .. 11, for example, we want row 1, col 0 .. 5. Your formula gets there bu computing the column and row directly. My formula takes advantage of the fact that 'idx' already added an extra 6 to the result, so it just needs 14 more to make 20.

 

When idx = 12 .. 17, my formulat takes advantage of the fact that 'idx' has already added an extra 12 to the result, and so it just needs an extra 28. etc.

 

I wrote the following C program to verify your formula against mine:

.

#include <stdio.h>

int main() {
  int i;

  for (i = 0; i < 30; ++i) {
    int jz = i + (i / 6) * 14 + 92;
    int at = (i % 6) + (i / 6) * 20 + 92;

    printf("i=%2d  jz=%2d  at=%2d\n", i, jz, at);
  }

  return 0;
}

.

That outputs:

.

i= 0  jz=92  at=92
i= 1  jz=93  at=93
i= 2  jz=94  at=94
i= 3  jz=95  at=95
i= 4  jz=96  at=96
i= 5  jz=97  at=97
i= 6  jz=112  at=112
i= 7  jz=113  at=113
i= 8  jz=114  at=114
i= 9  jz=115  at=115
i=10  jz=116  at=116
i=11  jz=117  at=117
i=12  jz=132  at=132
i=13  jz=133  at=133
i=14  jz=134  at=134
i=15  jz=135  at=135
i=16  jz=136  at=136
i=17  jz=137  at=137
i=18  jz=152  at=152
i=19  jz=153  at=153
i=20  jz=154  at=154
i=21  jz=155  at=155
i=22  jz=156  at=156
i=23  jz=157  at=157
i=24  jz=172  at=172
i=25  jz=173  at=173
i=26  jz=174  at=174
i=27  jz=175  at=175
i=28  jz=176  at=176
i=29  jz=177  at=177

.

Ta da!

 

It really is worth avoiding the modulo, as it's just as expensive as the division. Avoiding it cuts the cost nearly in half in the worst case. (Granted, the cost was never huge to begin with, but every cycle counts.)

[artrag]

Actually I see that

i=i%6+6*(i/6)

So we have

i%6+(i/6)*20=i+i/6*14

[Edited to fix a mistake]

Edited May 7, 2018 by artrag