SRL Archive - General

i thought abouty random in a random, which i have used quite often. i decided to plot the ouput to see what the real probability was and it is exactly what i thought. its not a guassian function but it look human. try it:

{$i srl/srl.scar}
var b ,r,a,i: integer;
begin
    b := CreateBitmap(200,200);
  for i := 0 to 5000 do
  begin
    a := random(360);
    r := round(random(random(100)));
    FastSetPixel(b,round(r*cos(a))+100,round(r*sin(a))+100,clRed);
  end;
    DrawBitmapDebugImg(b);
    DisplayDebugImgWindow(200,200);
end.

Is this Simba or SCAR code (you listed it as Simba code)? Crashes my Simba, and I uninstalled SCAR.

IT looks simba as scar dont use $ iirc

From: Squancy
IT looks simba as scar dont use $ iirc

Crap, didn't notice that (I take it for granted xD)

EDIT:
Why did I chose JPEG… ugh

Either way, for some reason it now works :)


EDIT2: This was fun to play around with:

{$i srl/srl.scar}
var b, t,r,a,i: integer;
begin
  MarkTime(t);
  repeat
    b := CreateBitmap(200,200);
    for i := 0 to 0 do
    begin
      a := random(360);
      r := round(random(random(100)));
      FastSetPixel(b,round(r*cos(a))+100,round(r*sin(a))+100,clRed);
    end;
      DrawBitmapDebugImg(b);
      DisplayDebugImgWindow(200,200);
      FreeBitmap (b);
    until (TimeFromMark(t) > 10000)
end.         

But using a random inside another random is really redundant, if the function is truly random like it supposed to be (it's not, but thats for another thread) then random(random(100)) should return the same results over a period of calls as random(100). Try your code just doing it once instead of twice and see if they are the same or not.

From: moparisthebest
But using a random inside another random is really redundant, if the function is truly random like it supposed to be (it's not, but thats for another thread) then random(random(100)) should return the same results over a period of calls as random(100). Try your code just doing it once instead of twice and see if they are the same or not.

The difference is not too significant, but with the graph generated, it looks much more real (relative to human tendancies) with two randoms than one random.

no
ther is a big big difference
i have continually updated the script and hers is my finished script. the color of the pixels represents how many times that point was called. the more randoms i use, the closer most points are to center =]

{$i srl/srl.scar}
var b ,r,a,i,col,increment: integer;ch,cs,cl:extended;
begin
  increment := 10;
  ClearDebugImg;
  b := CreateBitmap(200,200);
  while not iskeydown(VK_RCONTROL) do
  begin
    for i := 0 to 1000 do
    begin
      a := random(360);
      r := round(random(random(random(100))));
      col := FastGetPixel(b,round(r*cos(a))+100,round(r*sin(a))+100);
      ColorToHSL(col,ch,cs,cl);
      cl := 50
      FastSetPixel(b,round(r*cos(a))+100,round(r*sin(a))+100,HSLtoColor(mine(99-increment,ch+increment),100,mine(cl,50)));
      end;
    DrawBitmapDebugImg(b);
    DisplayDebugImgWindow(200,200);
  end;
  FreeBitmap(b);
  //FreeBitmap(GetDebugBitmap);
end.

this is one of the things i have used in my scripts for a wiule :P

it works because the output of the first random becomes the input for the next, so a lower number is more likely to be called. the second random has a lower range than the first.

to make it easier for people to change the number of randoms used i changed the script( again >.<)

here is new one. lol :

{$i srl/srl.scar}
var b ,r,a,i,col,increment,randn,randi: integer;ch,cs,cl:extended;
const
  randcount=3;
begin
  increment := 10;
  ClearDebugImg;
  b := CreateBitmap(200,200);
  while not iskeydown(VK_RCONTROL) do
  begin
    for i := 0 to 1000 do
    begin
      a := random(360);
      randn := 100;
      for randi := 0 to randcount do
        randn := random(randn);
      r := random(random(random(100)));
      col := FastGetPixel(b,round(r*cos(a))+100,round(r*sin(a))+100);
      ColorToHSL(col,ch,cs,cl);
      cl := 50
      FastSetPixel(b,round(r*cos(a))+100,round(r*sin(a))+100,HSLtoColor(mine(99-increment,ch+increment),100,mine(cl,50)));
      end;
    DrawBitmapDebugImg(b);
    DisplayDebugImgWindow(200,200);
  end;
  FreeBitmap(b);                
end.

Pretty redundant, so many operations and assignments done for a simple random…

Many better methods of doing this ranging from from using simple mathematical operators to going into more complex methods such as seeding the random yourself (not sure if this is possible in simba/scar.)

The first is with Random(100), the second is with Random(Random(100)) ran for about 5 seconds.

Same as above, ran for 1 minute and 15 seconds

var b ,r,a,i,col,increment,randn,randi,t: integer;ch,cs,cl:extended;
const
  randcount=3;
begin
  t := getsystemtime;
  increment := 10;
  ClearDebugImg;
  b := CreateBitmap(400,200);
  DisplayDebugImgWindow(400,200);
  while not iskeydown(VK_RCONTROL) do
  begin
    for i := 0 to 1000 do
    begin
      a := random(360);
      randn := 100;
      for randi := 0 to randcount do
        randn := random(randn);
      r := random(random(100));
      col := FastGetPixel(b,round(r*cos(a))+100,round(r*sin(a))+100);
      ColorToHSL(col,ch,cs,cl);
      cl := 50
      FastSetPixel(b,round(r*cos(a))+100,round(r*sin(a))+100,HSLtoColor(mine(99-increment,ch+increment),100,mine(cl,50)));
    end;
    for i := 0 to 1000 do
    begin
      a := random(360);
      randn := 100;
      for randi := 0 to randcount do
        randn := random(randn);
      r := random(random(random(100)));
      col := FastGetPixel(b,round(r*cos(a))+100,round(r*sin(a))+100);
      ColorToHSL(col,ch,cs,cl);
      cl := 50
      FastSetPixel(b,200+(round(r*cos(a))+100),round(r*sin(a))+100,HSLtoColor(mine(99-increment,ch+increment),100,mine(cl,50)));
    end;
    DrawBitmapDebugImg(b);
  end;
  FreeBitmap(b);
  writeln(getsystemtime-t);
end.

I don't feel like doing it but someone should compare Random(1000)/Random(10000) to Random(Random(100)).

Random(Random(100)) Ofcourse! That's so brilliant!

Line 1: Random(1) = 0
Line 2: Random(2) = 0, 1
Line 3: Random(3) = 0, 1, 2
Line 4: Random(4) = 0, 1, 2, 3
Line 5: Random(5) = 0, 1, 2, 3, 4

Imagine you pick one of the lines. Just a random line.
After that you pick a random number listed in the series in the line.
Number 0 is always a possible pick, but number 1 is only available in 4 lines.
Number 2 is available in 3 lines. Number 4 is only available in one line.

Chance to get number 0 = 5 / 15 = 0.333
Chance to get number 1 = 4 /15 = 0.267
Chance to get number 2 = 3 / 15 = 0.200
Chance to get number 3 = 2 / 15 = 0.133
Chance to get number 4 = 1 / 15 = 0.067

Ergo the smaller the number, the higher the chance it occurs!
Perfect humanlike randomness! :)
So simple and none of us had thought of this yet.

Great find, rep++

Come to think about it, random(random(100)) would statistically be closer to something like random(75) or something similar. A mathematician could figure this out to exact numbers, but I'm not a mathematician, nor do I have the time. All I can tell you is calling random more times doesn't really help you.

well… random(random(100)) would sometimes get 99, while random(75) cant go higher than 74…

From: Zyt3x
well… random(random(100)) would sometimes get 99, while random(75) cant go higher than 74…

That's true, but the spread would look closer to the distributions that you guys have posted further up.

The mathematical functions could do same thing with less operations, or am I mistaken?

From: moparisthebest
Come to think about it, random(random(100)) would statistically be closer to something like random(75) or something similar. A mathematician could figure this out to exact numbers, but I'm not a mathematician, nor do I have the time. All I can tell you is calling random more times doesn't really help you.

Check out my thinking above, random(random(100)) will produce more small numbers than big ones. random(100) will produce the same amount of each number.

random(random(100)), random(75)

From: marpis
Check out my thinking above, random(random(100)) will produce more small numbers than big ones. random(100) will produce the same amount of each number.

How is that any more human though? It's different, that doesn't really make it more human though.

From: moparisthebest
How is that any more human though? It's different, that doesn't really make it more human though.

That way you will most likely click to the center of an area, and clicking far away from the center is unlikely but still possible, just like a human clicks.

however, it stilll doesn't take into account one thing i recon needs to be taken into account….the starting mouse position, if your mouse is above the button, you are probably going to click the upper portion of the button…

From: Bad Boy JH
however, it stilll doesn't take into account one thing i recon needs to be taken into account….the starting mouse position, if your mouse is above the button, you are probably going to click the upper portion of the button…

What if the human overshoots by accident in real life?
As a cool test, I tried moving my cursor to the word "still" in the quote above from the left hand side, I ended up overshooting it ;)

As such, that is just me though. Everyone is different

I decided to graph the radius with million instances.
Also did the same with a random gaussian value generating function:

I think that gaussian random function looks extremely similar to a cosine / sine graph…

var I : Integer;
begin
  for I := -3 to 36 do
    WriteLn((Cos(Radians(I*5))+1)*100);
end.

From: Zyt3x
I think that gaussian random function looks extremely similar to a cosine / sine graph…

var I : Integer;
begin
  for I := -3 to 36 do
    WriteLn((Cos(Radians(I*5))+1)*100);
end.

You what might be good about the sine graph?
It could be set up so that the dead center has sort of a valley started, therefore meaning that the player won't click dead center all the time as well

lol, TY marpis for your explantion :P i cant explain anyuthing very well :P

i had thought about using numbers but i didnt now where to start. lol. also ty for pics. i was too lazy to screen shot. also uber ty for rep >.<

sin and cosine arent very cpu intensive so they seem an even better alternative.

procedure ClickBox(box:TBox);
var x,y:integer;
begin
  x := (box.x2 - box.x1)/2;
  y := (box.y2 - box.y1)/2;
  Mouse(box.x1 + x + Random(RandomRange(-x,x)), box.y1 + y + Random(RandomRange(-y,y)), 0, 0, true);
end;   

you use a randomrange in a random, so the output of the random range will not include a minimum. you will get numbers under the munimum so you need randomrange in randomrange :P

EDIT: nvm i just glanced at your code. i didnt realise it was just opposite of centerx :P

No clue what you just said but I'm pretty sure my function should work although I haven't tested it.

lol. i told you im bad at explaining :P. but yea, i looked at your code quickly and thought you misunderstood the concept. i was thinking that random(randomrange(10,100) and randomrange(randomrange(10,100),100) or randomrange(100,randomrange(10,100)) or even randomrange(randomrange(10,100),randomrange(10,100)) were what you meant to use :P

My code finds the dimensions of the box, than adds a random(randomrange()) to the midpoint of the box, and as far as I know Random( RandomRange(-x,x) ) should work perfectly, since the x/y variable is 1/2 the dimension of the box and it's being added (or subtracted) to the midpoint.

Please point out the mistake if you do find my code to be incorrect though, since I'm using it in one of my scripts in the making.

no, i think its fine :P i just didnt realize at first what you were doing because i just glanced. =]
EDIT: lol, im glad my idea is already being put to use :P