Random Numbers?

[ab]

Is there a way to have Ubasic generate random numbers?  If so that would be great!

Could I call out to the system clock at least and multiply through that to generate quasi-random numbers?

[fbonomi]

yes, you could... how accurate must this random generator be?

How often must you get those random numbers?

What range of nymbers do you need (how many different vakues yiu need)?

[ab]

[waldo]

From your description, I would think a pseudo-random sequence of 8 bit numbers that repeats every 256 values would suffice.  If so, consider using a Linear Feedback Shift Register (LFSR).  It's a very simple way of creating an arbitrarily long sequence.  Here's code for a CHDK script that does an 8-bit LFSR:

Code: [Select]

@title LFSR Test

rem 8 bit lfsr test
rem c contains pseudo-random number

c = 1

for g=0 to 1000
gosub "lfsr8"
print c
sleep 100
next g

end


:lfsr8
if (c & 1) = 1 then
c = (c/2) ^ 142
else
c = c / 2
endif

return

Have fun !

[ab]

How big are those numbers going to be???

[waldo]

0 to 255.  You can scale them down with division or use more bits in the sequence for a larger range.

[PhyrePhoX]

you can also use my build from http://chdk.setepontos.com/index.php/topic,978.0.html, it has (among other stuff) a random function for ubasic. someday in the future i guess it will be incorporated in the official build

[ab]

I posted some preliminary results over on my blog ---

 … timelapse focus wobble script … @ Arman Bohn

PhyrePhox - I'll look into your random function next.

[PhyrePhoX]

well, i guess waldo's script does it for you already
my build could help though when you need to write a smaller script (also it should be like 50 ms faster each time random is executed, to the least), also i guess it is "more random", as it uses the tickcount as seed.
looking forward to seeing your video, looks very promising. i also might add that i quite like your music

[ab]

Thanks!

I've been working on my first full length in 10 years.  Having a blast with an A640 and the scripts.

How can I get your firmware into my cam?

I'm downloading it now.....

Is it any different than loading the other firmwares?

[PhyrePhoX]

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

[ab]

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.

[fbonomi]

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.

[PhyrePhoX]

 

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.

[fbonomi]

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.

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