Random Numbers? - page 2 - Script Writing - CHDK Forum

Random Numbers?

  • 23 Replies
  • 15948 Views
*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Random Numbers?
« Reply #10 on: 29 / April / 2008, 02:15:02 »
Advertisements
nope, no difference. it is the same procedure. one piece of advice: backup your CHDK folder (this folder contains your *.cfg file and so on).

*

Offline ab

  • *
  • 17
Re: Random Numbers?
« Reply #11 on: 29 / April / 2008, 02:52:54 »
So can I define the size of the random number in the script?

say like

@param b size of focus shift

get_focus f
random z
a=z%b
set_focus f+a
??

It seems like it needs to be defined with integers.

*

Offline fbonomi

  • ****
  • 469
  • A570IS SD1100/Ixus80
    • Francesco Bonomi
Re: Random Numbers?
« Reply #12 on: 29 / April / 2008, 03:05:04 »
Yes, a pseudo-random sequence that is (only) long 256 numbers is quite discernible to the eye as a pattern.

Our brains are VERY good at detecting patterns in things, especially in moving things (and sounds btw).

My UNTESTED suggestion to "disrupt" the regularity of the sequence.

So, let's get inspired by the coolest random number generator on the web:

HotBits: Genuine Random Numbers (Genuine random numbers, generated by radioactive decay)

The principle is that you get any physical measurement, and look only at the least significant part (the last digit, so to say)  where you know our measures will have a lot of errors.

What? physical measurement? How can we do that in our camera?

Well, our camera can measure luminosity (Bv) so, take luminosity, throw away the "large numbers" keep only the "small numbers" and you MIGHT have something that looks quite random-like...

The disadvantage is that these numbers will be rather small (as we keep only the least siignificant part).

I would therefore compose the two methods: use the Bv-generated numbers for the "high part" of the random number, and use the lfsr for the low part of the number.

i.e., replace the middle part of the script above with the following UNTESTED code:

Code: [Select]
rem read luminance
get_bv96 b

rem keep only luminance modulo 3 (pseudo-randomly alternating between 0,1 and 2)
b = b % 3

rem use it to generate the high part (becomes 0, 256, and 512)
b = b * 256

rem get your usual random number (0 to 255)
gosub "lfsr8"

rem add them up (getting numbers in the range fro 0+0 to 512+255)
d = c + b

rem if needed, bring the number back in the 0-255 range
d=d/3

rem d has our (maybe more) random number
print d

Instead of 3 above, you could use other numbers. Better if odd, prime, small numbers like 3, 5 or 7

Otherwise, you could also have LSFR longer than 256-numbers. That would be maybe better, but WAAAY less cool :-)

Below a graph of a sequence of 300 pseduo-random numbers ranging from 0 to 6, generated from the Bv logs I had for my sunset-time-lapse script ( Timelapse with variable shutter speed )

Iin this case, I did Bv modulo 7 and it still seems rather random.
« Last Edit: 29 / April / 2008, 03:07:45 by fbonomi »

*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Random Numbers?
« Reply #13 on: 29 / April / 2008, 03:18:47 »
 
So can I define the size of the random number in the script?

say like

@param b size of focus shift

get_focus f
random z
a=z%b
set_focus f+a
??

It seems like it needs to be defined with integers.
this portion of your code should work, b being the range of random numbers you want to generate.
i just noticed by looking at the code of ubasic.c that "get_tick_count" is available in ubasic. should be better to use than luminosity, since for example ab wants to shoot using random "DOF", meaning his light conditions are somewhat static.

*

Offline fbonomi

  • ****
  • 469
  • A570IS SD1100/Ixus80
    • Francesco Bonomi
Re: Random Numbers?
« Reply #14 on: 29 / April / 2008, 03:32:02 »
i just noticed by looking at the code of ubasic.c that "get_tick_count" is available in ubasic.

I know, but I couldn't find out what the granularity of get_tick_count is.

Quote
meaning his light conditions are somewhat static.

sure, but this does not really matter. We are using the 1 or 2 least significant bits of the measurement, and there's plenty of noise down there.

EDIT:
I have done a few tests, it's not practical to do it like this...
« Last Edit: 29 / April / 2008, 03:36:53 by fbonomi »

*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Random Numbers?
« Reply #15 on: 29 / April / 2008, 10:03:20 »
what do you mean by granularity? it's quite a big number, constantly changing. should be useful.


ab did you have any success? in your blog entry i read
Quote
You can see a patern develope in the randomness in the way the shots pulse. The script needs more work.
is it so? so waldos script didnt do the trick? maybe logging the output to a file will show us how random it is (or nor)?

*

Offline ab

  • *
  • 17
Re: Random Numbers?
« Reply #16 on: 29 / April / 2008, 12:26:25 »
I couldn't get the code to work for parameterizing the size of the random number.

Waldos script works for me, but it would be cool to be able to constrain the random numbers to different limits each time I run the script. 

Could you check to see if you can parameterize random numbers?

*

Offline fbonomi

  • ****
  • 469
  • A570IS SD1100/Ixus80
    • Francesco Bonomi
Re: Random Numbers?
« Reply #17 on: 29 / April / 2008, 15:45:10 »
what do you mean by granularity?

Sorry, I meant resolution. I have never tried it and I was wondering if it was in in seconds, milliseconds or else

*

Offline fbonomi

  • ****
  • 469
  • A570IS SD1100/Ixus80
    • Francesco Bonomi
Re: Random Numbers?
« Reply #18 on: 29 / April / 2008, 15:55:06 »
you don't say what problem you have in the script... it makes it harder to solve it.

If the problem is non-randomness, then I must say that this bit of code:

Code: [Select]
random z
a=z%b

can introduce some non-randomness, especially evident if b is rather large..

for example, let's say b=200.

for values of z going from 0 to 199, a=z (in the range 0-199)
for values of z going from 200 to 255, a=z-200 (in the range 0-55)

so, assuming z is uniformly distributed, a will have a very non-uniform distribution: values of a in the range 0-55 will be double as frequent as larger values.

your method works well for values of b that are powers of two (128,64, 32...) or that are much smaller than 255, so this "folding" effect is less strong..

Is this your problem?

*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Random Numbers?
« Reply #19 on: 29 / April / 2008, 19:43:56 »
what do you mean by granularity?

Sorry, I meant resolution. I have never tried it and I was wondering if it was in in seconds, milliseconds or else

it's ms.

okay, i created the following script that is compatible with my build that does what you want, ab. at least i hope so. i guessed by parametrization of the random numbers you meant the range, eh?
Code: (freebasic) [Select]
@param h rand_min
@default h 5
@param i rand_max
@default i 7
random x
a = h + x%(i-h+1)
print "between "h "and "i ": "a
this generates numbers between (and including) 5 and 7.
i wrote a second script that can be used to "benchmark" the random number generator:
Code: (freebasic) [Select]
@param y iterations
@default y 1000
@param h rand_min
@default h 5
@param i rand_max
@default i 7
print_screen 1
k=get_tick_count
print "rand_max: "i
print "rand_min: "h

for z=0 to y
random x
a = h + x%(i-h+1)
print a
next z
l=get_tick_count
print "Duration: ",(l-k)/1000," Seconds"
print "the end."
print_screen 0
wait_click
end
you can specify the loop count and the range the random numbers should be in.
attached is a sample file with 10.000 iterations and random numbers ranging from 0 to 100 (i should have taken 0 to 10 i guess, but i wont do it again this night, took me 20 minutes :D
can be made faster though, for example by writing multiple random numbers per line, as writing to the sdcard (imo!) is the limiting factor here.
maybe one of you can check my attached file for randomness.
edit: i guess my generated numbers arent so random at all. i guess it is having to do with the 10 ms script delay and thus the same variations in tickcount. so a better and faster check would really be to either throw in some random sleeps or multiple randoms per line.
« Last Edit: 29 / April / 2008, 19:59:38 by PhyrePhoX »

 

Related Topics


SimplePortal © 2008-2014, SimplePortal