Re: Random algorithm

[François Chaplais]

Le 13 nov. 08 à 19:35, Randall Reetz a écrit :


Thank you Francois,

Can statistics be rigorously derived from proability math?  I hope so.
yes, that is the "clean" way, which is, by the way, the best suited  
for academic teaching.


Both are heavily dependent on what appears to be statistics ("both"  
refers here to my twin gods).  I am a self admitted thermodynamics  
and information science freak.  I'd hate to think that my whole  
world was anecdotally argued.  I do see a strange but familiar  
symmetry between the finite/infinite distinction that seperates  
probability theory and practice, and the open/closed system maths  
that seperates the thermodynamic engineering from pure science.


Randall



I dug up my old textbooks on statistical physics (which is another  
word for thermodynamics) and the textbook is entirely based on  
probabilistic methods. The official motivation for statistical physics  
is that, for "macroscopic" systems, the behaviour of" individual"  
elements are not observable, so you only have access to their  
statistics.


I won't digress more on this subject, as it is OT. Just one last word:  
even in you stick to deterministic models, sampling, aka A/D  
converters, is a tricky issue, for reasons which are similar to  
experiments on probabilistically modeled systems: the data set that is  
accessible to you is of measure zero with respect to the (hidden) set  
of data that lives in the model. In practice, unless you enforce  
stronger assumptions on the model, there is now way to bring  
contradiction to the mathematical model by means of a suitable  
experiment.


Now, back to rev...

cheers
François

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Richard Gaskin]

Dave Cragg wrote:


On 17 Nov 2008, at 16:04, Richard Gaskin wrote:


Dave Cragg wrote:
...
> The two scripts  measure the number of repeated sequences that are
> generated by the two methods. The first method has yet to produce a
> repeated sequence here.
...
> METHOD 1 (no resetting)

Bingo.  The psuedo-random algo used in Rev is pretty good as it is.


I'm not sure if you can safely draw that conclusion. (Although I've no  
reason to think it isn't pretty good.)


There's the rub:  when attempting to compare anything to a truly random 
set, there's always the possibility that even repeating patterns may be 
the result of randomness too. :)


But I think we're on the same page here: short of calling some 
supercomputer over the web which uses some fancier means, monkeying with 
Rev's built-in random function may not be much better than just leaving 
it alone, which seems suitable for a great many practical applications.


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Dave Cragg]

On 17 Nov 2008, at 16:04, Richard Gaskin wrote:


Dave Cragg wrote:
...
> The two scripts  measure the number of repeated sequences that are
> generated by the two methods. The first method has yet to produce a
> repeated sequence here.
...
> METHOD 1 (no resetting)

Bingo.  The psuedo-random algo used in Rev is pretty good as it is.


I'm not sure if you can safely draw that conclusion. (Although I've no  
reason to think it isn't pretty good.) My example script sliced the  
25000 random numbers into sets of 5 and found no repeats among the  
sets. It's possible there were repeating sequences that crossed the  
"set boundaries".


Looking at the responses to my last mail, I'm not sure if I made my  
point clearly. (It wouldn't be the first time.) I was just wanting to  
point out the danger of repeatedly resetting the randomSeed with a  
random number (or any other technique that involves a risk of  
repeating the randomSeed value). The scripts I posted were to  
demonstrate a probably unwanted outcome that, although entirely  
predictable, is not always obvious.


Cheers
Dave
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Richard Gaskin]

Dave Cragg wrote:
...
> The two scripts  measure the number of repeated sequences that are
> generated by the two methods. The first method has yet to produce a
> repeated sequence here.
...
> METHOD 1 (no resetting)

Bingo.  The psuedo-random algo used in Rev is pretty good as it is.

--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: Random algorithm

[Randall Reetz]

This is good detextive work.  Good science.  I think richard has found out how 
long the truncated ticks number is that rev uses as a seed.

-Original Message-
From: "Dave Cragg" <[EMAIL PROTECTED]>
To: "How to use Revolution" 
Sent: 11/15/2008 12:55 AM
Subject: Re: Random algorithm


On 13 Nov 2008, at 19:38, Richard Gaskin wrote:

> So unless I'm missing something obvious (and it certainly wouldn't  
> be the first time), beginning with a fresh seed as Rev does and then  
> resetting it each time during the session seems a fair way to avoid  
> discernible reproducible patterns for most applications.


Sorry for going back to this, but I'd just like to repeat my concern  
for resetting the seed using a "random" value.  I may have  
misunderstood what "resetting it each time" means. In some posts  
people have talked about resetting it before "each run" and others  
have talked about resetting before each call to the random function.  
My concern was with a particular "each run" situation.

Say the task is to produce 5000 sets of 5 random numbers from 1 to  
1000. (perhaps for a gaming task) The straightforward way to do this  
is to use the default Rev seed and call random(1000) 25000 times,  
dividing the results into 5000 sets of 5.

An alternative would be to reset the randomSeed before generating each  
set of five numbers. At first glance, this might seem like a  
reasonable thing to do. But depending on how the seed is set, it could  
produce unwanted results. In the second script below, the seed is  
reset using the random of an incremented number. (4570422 incremented  
by 1 to avoid getting stuck with the same seed)

The two scripts  measure the number of repeated sequences that are  
generated by the two methods. The first method has yet to produce a  
repeated sequence here. But the second produces repeated sequences on  
almost every run. So by resetting the seed for "each run", the  
occurrence of a repeated sequence changes from a highly improbable  
event to a fairly safe bet.


Cheers
Dave


METHOD 1 (no resetting)
on mouseUp

repeat 5000
   put empty into tVal
   repeat 5
  put random(1000) & "," after tVal
   end repeat
   add 1 to tValArray[tVal]
end repeat

put 0 into tCount

repeat for each element tEl in tValArray
   if tEl > 1 then
  add 1 to tCount
   end if
end repeat
put tCount
end mouseUp

METHOD 2 (reset on every "set")
on mouseUp
---
put 4570422 into tSeedBase


[truncated by sender]
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Jacques Hausser]

Interesting  demonstration ! If I'm not wrong, the probablity to get  
twice the same sequence with the first method is about 6.25E-32 for  
"really random" numbers (equiprobability for each number from 1 to  
1000), what's a quite satisfying zero for dirty statisticians !


Jacques

Le 15 nov. 2008 à 09:55, Dave Cragg a écrit :



On 13 Nov 2008, at 19:38, Richard Gaskin wrote:

So unless I'm missing something obvious (and it certainly wouldn't  
be the first time), beginning with a fresh seed as Rev does and  
then resetting it each time during the session seems a fair way to  
avoid discernible reproducible patterns for most applications.



Sorry for going back to this, but I'd just like to repeat my concern  
for resetting the seed using a "random" value.  I may have  
misunderstood what "resetting it each time" means. In some posts  
people have talked about resetting it before "each run" and others  
have talked about resetting before each call to the random function.  
My concern was with a particular "each run" situation.


Say the task is to produce 5000 sets of 5 random numbers from 1 to  
1000. (perhaps for a gaming task) The straightforward way to do this  
is to use the default Rev seed and call random(1000) 25000 times,  
dividing the results into 5000 sets of 5.


An alternative would be to reset the randomSeed before generating  
each set of five numbers. At first glance, this might seem like a  
reasonable thing to do. But depending on how the seed is set, it  
could produce unwanted results. In the second script below, the seed  
is reset using the random of an incremented number. (4570422  
incremented by 1 to avoid getting stuck with the same seed)


The two scripts  measure the number of repeated sequences that are  
generated by the two methods. The first method has yet to produce a  
repeated sequence here. But the second produces repeated sequences  
on almost every run. So by resetting the seed for "each run", the  
occurrence of a repeated sequence changes from a highly improbable  
event to a fairly safe bet.



Cheers
Dave


METHOD 1 (no resetting)
on mouseUp

  repeat 5000
 put empty into tVal
 repeat 5
put random(1000) & "," after tVal
 end repeat
 add 1 to tValArray[tVal]
  end repeat

  put 0 into tCount

  repeat for each element tEl in tValArray
 if tEl > 1 then
add 1 to tCount
 end if
  end repeat
  put tCount
end mouseUp

METHOD 2 (reset on every "set")
on mouseUp
  ---
  put 4570422 into tSeedBase
  repeat 5000
 put empty into tVal2
 add 1 to tSeedBase
 set the randomSeed to random(tSeedBase)
 repeat 5
put random(1000) & "," after tVal2
 end repeat
 add 1 to tValArray2[tVal2]
  end repeat
  ---

  put 0 into tCount2

  repeat for each element tEl in tValArray2
 if tEl > 1 then
add 1 to tCount2
 end if
  end repeat

  put tCount2

end mouseUp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax:++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: [EMAIL PROTECTED]
***

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Dave Cragg]

On 13 Nov 2008, at 19:38, Richard Gaskin wrote:

So unless I'm missing something obvious (and it certainly wouldn't  
be the first time), beginning with a fresh seed as Rev does and then  
resetting it each time during the session seems a fair way to avoid  
discernible reproducible patterns for most applications.



Sorry for going back to this, but I'd just like to repeat my concern  
for resetting the seed using a "random" value.  I may have  
misunderstood what "resetting it each time" means. In some posts  
people have talked about resetting it before "each run" and others  
have talked about resetting before each call to the random function.  
My concern was with a particular "each run" situation.


Say the task is to produce 5000 sets of 5 random numbers from 1 to  
1000. (perhaps for a gaming task) The straightforward way to do this  
is to use the default Rev seed and call random(1000) 25000 times,  
dividing the results into 5000 sets of 5.


An alternative would be to reset the randomSeed before generating each  
set of five numbers. At first glance, this might seem like a  
reasonable thing to do. But depending on how the seed is set, it could  
produce unwanted results. In the second script below, the seed is  
reset using the random of an incremented number. (4570422 incremented  
by 1 to avoid getting stuck with the same seed)


The two scripts  measure the number of repeated sequences that are  
generated by the two methods. The first method has yet to produce a  
repeated sequence here. But the second produces repeated sequences on  
almost every run. So by resetting the seed for "each run", the  
occurrence of a repeated sequence changes from a highly improbable  
event to a fairly safe bet.



Cheers
Dave


METHOD 1 (no resetting)
on mouseUp

   repeat 5000
  put empty into tVal
  repeat 5
 put random(1000) & "," after tVal
  end repeat
  add 1 to tValArray[tVal]
   end repeat

   put 0 into tCount

   repeat for each element tEl in tValArray
  if tEl > 1 then
 add 1 to tCount
  end if
   end repeat
   put tCount
end mouseUp

METHOD 2 (reset on every "set")
on mouseUp
   ---
   put 4570422 into tSeedBase
   repeat 5000
  put empty into tVal2
  add 1 to tSeedBase
  set the randomSeed to random(tSeedBase)
  repeat 5
 put random(1000) & "," after tVal2
  end repeat
  add 1 to tValArray2[tVal2]
   end repeat
   ---

   put 0 into tCount2

   repeat for each element tEl in tValArray2
  if tEl > 1 then
 add 1 to tCount2
  end if
   end repeat

   put tCount2

end mouseUp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Mark Wieder]

Richard-

Thursday, November 13, 2008, 11:38:35 AM, you wrote:

> True, and I've used this to my advantage in some modest encryption
> algorithms to arrive at non-obvious but reproducible patterns.

In my world of software testing it is also quite advantageous to be
able to craft "random" data streams but in a way that is reproducible
in order to be able to recreate a situation that might cause an error.
Setting the random seed to a known value before starting this process
and saving the random seed used is the key to repeatable randomness.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Richard Gaskin]

Dave Cragg wrote:


On 13 Nov 2008, at 19:38, Richard Gaskin wrote:

Fortunately, it doesn't.  Rev sets the randomSeed to some non-fixed  
number (a truncated portion of the milliseconds?) each time it starts.


This implies that each session starts with a unique seed, so each  
sequence derived from it will be similarly unique.


This occurred to me last night while reviewing my comment on your  
seeding method. Does a different randomSeed guarantee a different  
random sequence in the same way that the same seed produces the same  
sequence?


"Guarantee" is a tough claim to verify, since it's possible that even a 
truly random sequence might by chance appear as a repeated pattern. :)


But to test this I made a simple test stack with a button and two 
fields, with this in the button script:


on mouseUp
  put empty into fld 1
  put empty into fld 2
  --
  -- Test 1: psuedo-random randomSeed:
  repeat 2
set the randomseed to random(44)
repeat 10
  set the randomSeed to random(44)
  put random(10) &cr after fld 1
end repeat
put cr&cr after fld 1
  end repeat
  --
  -- Test 2: fixed randomSeed:
  repeat 2
set the randomseed to 10
repeat 10
  set the randomSeed to random(10)
  put random(10) &cr after fld 2
end repeat
put cr&cr after fld 2   
  end repeat
  --
end mouseUp


Results:

Field 1:
1 5 10 8 8 6 4 4 9 3
1 4 10 10 9 3 9 7 3 9


Field 2:
1 1 6 8 1 1 6 8 1 1
1 1 6 8 1 1 6 8 1 1


This seems to support the hypothesis that using a fixed randomSeed will 
result in the same sequence being generated even if you later set the 
randomSeed using random(), but changing the randomSeed to a non-fixed 
number changes the resulting sequence.


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Dave Cragg]

On 13 Nov 2008, at 19:38, Richard Gaskin wrote:

Fortunately, it doesn't.  Rev sets the randomSeed to some non-fixed  
number (a truncated portion of the milliseconds?) each time it starts.


This implies that each session starts with a unique seed, so each  
sequence derived from it will be similarly unique.


This occurred to me last night while reviewing my comment on your  
seeding method. Does a different randomSeed guarantee a different  
random sequence in the same way that the same seed produces the same  
sequence? (I had a feeling this was relevant to my argument but then I  
fell asleep. :-) ) It might be useful to know this.


Cheers
Dave
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Dave Cragg]

On 13 Nov 2008, at 19:50, Malte Brill wrote:


Somewhat related :)

http://web.archive.org/web/20011027002011/http://dilbert.com/comics/dilbert/archive/images/dilbert2001182781025.gif
http://xkcd.com/221/



Love them!!

Dave
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Malte Brill]

> It looks like the limit is 2^31 -- 2147483648


Thanks for testing that Dave!


Somewhat related :)

http://web.archive.org/web/20011027002011/http://dilbert.com/comics/dilbert/archive/images/dilbert2001182781025.gif
http://xkcd.com/221/

Cheers,

Malte
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Richard Gaskin]

Jan Schenkel wrote:

> --- Richard Gaskin  wrote:
>> >>set the randomSeed to random(4570422)
>>
>> It would seem that resetting the randomSeed each
>> time you use the random function would only have
>> a 1-in-4,570,422 chance of getting the same seed
>> as the previous run, no?
>
> If you set off with the same randomSeed, the random
> function will return the same result; ergo you're
> resetting the randomSeed with the same number, which
> means the next number coming out of the random
> function would also be the same.

True, and I've used this to my advantage in some modest encryption 
algorithms to arrive at non-obvious but reproducible patterns.


To make a simplistic example, we could assume this:

 set the randomSeed to 10

...will produce this result for calling random(10) 3 times:

  5
  8
  2

If you then set the randomSeed to 10 again and call random(10) another 
three times, you'll get the same set of results (5,8,2).


This is useful if you want to reproduce a given pattern, but of course 
less useful to simulate the ideal of true randomness.


To closer approximate that ideal (and like all ideals in an imperfect 
world, it can only be an approximation) we can change the randomSeed to 
a different number each time we want to use it.


But as you noted, since random() will deliver the same sequence of 
results for a given seed, using it to set the randomSeed will provide 
nothing more than a level of misdirection for what is ultimately still a 
fixed pattern of results.


So we might try something like this:

  set the randomSeed to 10
  put random(10) into x -- x is now 5
  set the randomSeed to x
  put random(10) into y

...and no matter how many times we run this, y will always be the same 
number.


But this is different from my original suggestion.  This one sets the 
randomSeed to a fixed number, while my original suggestion changes it on 
the fly:


  set the randomSeed to random(tSomeLargeNumber)

Even then we might get the same randomSeed in every session if Rev 
started out each time using the same number.


Fortunately, it doesn't.  Rev sets the randomSeed to some non-fixed 
number (a truncated portion of the milliseconds?) each time it starts.


This implies that each session starts with a unique seed, so each 
sequence derived from it will be similarly unique.


Further permutations within that session will also be reasonably unique 
as long as we continue to avoid setting the randomSeed to a fixed number.


So unless I'm missing something obvious (and it certainly wouldn't be 
the first time), beginning with a fresh seed as Rev does and then 
resetting it each time during the session seems a fair way to avoid 
discernible reproducible patterns for most applications.



Of course, randomness being what it is, we may just as likely find a 
pattern in a truly random series as in a pseudo-random one.


In a universe replete with synchronicity while seemingly devoid of true 
randomness, the pursuit of ideal randomness is the domain of the 
philosopher and perhaps a few pernickety referees of academic journals. :)


For us mere applications programmers, we're faced with a simpler, 
arguably more pragmatic question:  What are the implications of 
psuedo-randomness for our work?


For my own modest needs, Malte summed it up well:

  I really like the way the random algorithm the way it is
  implemented in Revolution, as a seeded algorithm can be
  used in many ways in games. It prevents the ability to
  cheat with undo systems in casual games, or even lets you
  set up whole galaxies without stuffing memory.

--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: Random algorithm

[Randall Reetz]

Thank you Francois,

Can statistics be rigorously derived from proability math?  I hope so.  Both 
are heavily dependent on what appears to be statistics ("both" refers here to 
my twin gods).  I am a self admitted thermodynamics and information science 
freak.  I'd hate to think that my whole world was anecdotally argued.  I do see 
a strange but familiar symmetry between the finite/infinite distinction that 
seperates probability theory and practice, and the open/closed system maths 
that seperates the thermodynamic engineering from pure science.

Randall

-Original Message-
From: "Eric Chatonet" <[EMAIL PROTECTED]>
To: "How to use Revolution" 
Sent: 11/13/2008 9:51 AM
Subject: Re: Random algorithm

Bonsoir François,

Great post indeed :-)
I fully agree.

Le 13 nov. 08 à 18:47, François Chaplais a écrit :

>
> Le 13 nov. 08 à 03:39, Randall Reetz a écrit :
>
>> And another problem is that a random and unique solution actually  
>> reduces randomness as it is run.  Each time you eliminate a  
>> number, the set of numbers left is reduced.  This is even true of  
>> an infinate number randomizer.  Sometimes i wonder if this  
>> fascination with random number generation isnt a good diagnosis of  
>> severe case of the geeks.
>
> maybe it is just a lack of mathematical background
>>
>>
>> -Original Message-
>> From: "Randall Reetz" <[EMAIL PROTECTED]>
>> To: "How to use Revolution" 
>> Sent: 11/12/2008 6:18 PM
>> Subject: RE: Random algorithm
>>
>> There is a huge difference between random and unique.  If you are  
>> after unique then just use the counting numbers.  If you need both  
>> random and unique you will have to check each number generated  
>> against a saved list of every previous number.  There is nothing  
>> wrong with a random number generator that spits out duplicate  
>> numbers.  Random is blind to history (and future).  Random is not  
>> nostalgic.  A coin with two sides is just as good at random as a  
>> pair of thousand sided dice.
>>
>
> actually, random is so little nostalgic that a random sequence of  
> zeros and ones (with equal probabilities) can produce ones for a  
> zillion consecutive ones without invalidating the probabilistic  
> model. This fact holds (mathematically) as long as the number of  
> events is finite (which is always the case in practice). The  
> central limit theorem only holds for an "actual" infinite number of  
> values.
> Of course, some may object that having a zillion consecutive ones  
> is unprobable; however, this assumption itself can only be verified  
> by repeating the experience an actual infinity of times, so we're  
> back to the same modelling problem.
>
> In practice, people do not refer to probabilities but to  
> statistics. As far as I know there are two schools of statisticians  
> (at least when it comes to teaching)
> 1) the "clean" statisticians present statistics as an offspring of  
> probabilities; it is mathematically clean but has the same  
> weaknesses when to it comes to confronting the model to the  
> experiment.
> 2) the "dirty" statisticians admit that if your random process  
> produces a zillion ones, then you have to pull the trigger on the  
> model, arguing that modelling the sequence by a constant is closer  
> to what happens and as economical as the flawed statistical model.  
> A zillion or two zillion limit: you chose.


[truncated by sender]
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Eric Chatonet]

Bonsoir François,

Great post indeed :-)
I fully agree.

Le 13 nov. 08 à 18:47, François Chaplais a écrit :



Le 13 nov. 08 à 03:39, Randall Reetz a écrit :

And another problem is that a random and unique solution actually  
reduces randomness as it is run.  Each time you eliminate a  
number, the set of numbers left is reduced.  This is even true of  
an infinate number randomizer.  Sometimes i wonder if this  
fascination with random number generation isnt a good diagnosis of  
severe case of the geeks.


maybe it is just a lack of mathematical background



-Original Message-
From: "Randall Reetz" <[EMAIL PROTECTED]>
To: "How to use Revolution" 
Sent: 11/12/2008 6:18 PM
Subject: RE: Random algorithm

There is a huge difference between random and unique.  If you are  
after unique then just use the counting numbers.  If you need both  
random and unique you will have to check each number generated  
against a saved list of every previous number.  There is nothing  
wrong with a random number generator that spits out duplicate  
numbers.  Random is blind to history (and future).  Random is not  
nostalgic.  A coin with two sides is just as good at random as a  
pair of thousand sided dice.




actually, random is so little nostalgic that a random sequence of  
zeros and ones (with equal probabilities) can produce ones for a  
zillion consecutive ones without invalidating the probabilistic  
model. This fact holds (mathematically) as long as the number of  
events is finite (which is always the case in practice). The  
central limit theorem only holds for an "actual" infinite number of  
values.
Of course, some may object that having a zillion consecutive ones  
is unprobable; however, this assumption itself can only be verified  
by repeating the experience an actual infinity of times, so we're  
back to the same modelling problem.


In practice, people do not refer to probabilities but to  
statistics. As far as I know there are two schools of statisticians  
(at least when it comes to teaching)
1) the "clean" statisticians present statistics as an offspring of  
probabilities; it is mathematically clean but has the same  
weaknesses when to it comes to confronting the model to the  
experiment.
2) the "dirty" statisticians admit that if your random process  
produces a zillion ones, then you have to pull the trigger on the  
model, arguing that modelling the sequence by a constant is closer  
to what happens and as economical as the flawed statistical model.  
A zillion or two zillion limit: you chose.


Now, if you admit that computers are deterministic, then, knowing  
the initial state of your machine (which may be LARGE), you are  
able to predict every output of it provided you know the inputs.  
Relying on unmodelled input (such as the time at which you computer  
is turned on) only makes the thing unmodelled; it does not garantee  
randomness.


If you go further, if all comes to a problem of semantics: what  
people want with random series is a user triggered event that will  
defeat prediction (that's what the las vegas folks want). However  
this definition is severely hampered the the limitations of the  
existing languages (man or machine language). You should consider  
the possibility that one will produce a language/model that can  
predict what happens.


cheers,
François

P.S. on the lighter side, my wife's experience with M$ Word on the  
PC suggest that a large amount of Word's behaviour is unpredictable.


Best regards from Paris,
Eric Chatonet.

Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/
Email: [EMAIL PROTECTED]/



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[François Chaplais]

Le 13 nov. 08 à 03:39, Randall Reetz a écrit :

And another problem is that a random and unique solution actually  
reduces randomness as it is run.  Each time you eliminate a number,  
the set of numbers left is reduced.  This is even true of an  
infinate number randomizer.  Sometimes i wonder if this fascination  
with random number generation isnt a good diagnosis of severe case  
of the geeks.


maybe it is just a lack of mathematical background



-Original Message-
From: "Randall Reetz" <[EMAIL PROTECTED]>
To: "How to use Revolution" 
Sent: 11/12/2008 6:18 PM
Subject: RE: Random algorithm

There is a huge difference between random and unique.  If you are  
after unique then just use the counting numbers.  If you need both  
random and unique you will have to check each number generated  
against a saved list of every previous number.  There is nothing  
wrong with a random number generator that spits out duplicate  
numbers.  Random is blind to history (and future).  Random is not  
nostalgic.  A coin with two sides is just as good at random as a  
pair of thousand sided dice.




actually, random is so little nostalgic that a random sequence of  
zeros and ones (with equal probabilities) can produce ones for a  
zillion consecutive ones without invalidating the probabilistic model.  
This fact holds (mathematically) as long as the number of events is  
finite (which is always the case in practice). The central limit  
theorem only holds for an "actual" infinite number of values.
Of course, some may object that having a zillion consecutive ones is  
unprobable; however, this assumption itself can only be verified by  
repeating the experience an actual infinity of times, so we're back to  
the same modelling problem.


In practice, people do not refer to probabilities but to statistics.  
As far as I know there are two schools of statisticians (at least when  
it comes to teaching)
1) the "clean" statisticians present statistics as an offspring of  
probabilities; it is mathematically clean but has the same weaknesses  
when to it comes to confronting the model to the experiment.
2) the "dirty" statisticians admit that if your random process  
produces a zillion ones, then you have to pull the trigger on the  
model, arguing that modelling the sequence by a constant is closer to  
what happens and as economical as the flawed statistical model. A  
zillion or two zillion limit: you chose.


Now, if you admit that computers are deterministic, then, knowing the  
initial state of your machine (which may be LARGE), you are able to  
predict every output of it provided you know the inputs. Relying on  
unmodelled input (such as the time at which you computer is turned on)  
only makes the thing unmodelled; it does not garantee randomness.


If you go further, if all comes to a problem of semantics: what people  
want with random series is a user triggered event that will defeat  
prediction (that's what the las vegas folks want). However this  
definition is severely hampered the the limitations of the existing  
languages (man or machine language). You should consider the  
possibility that one will produce a language/model that can predict  
what happens.


cheers,
François

P.S. on the lighter side, my wife's experience with M$ Word on the PC  
suggest that a large amount of Word's behaviour is unpredictable. 
___

use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Dave Cragg]

On 13 Nov 2008, at 07:36, Malte Brill wrote:


on each run of the following script:

on mouseUp pMouseBtnNo
   repeat with i= 2130706432 to 2130706442
   set the randomseed to i
   put random(34) & cr after fld 1
   end repeat
end mouseUp



Malte

It looks like the limit is 2^31 -- 2147483648

This returns 23 on each line after the first 2:

on mouseUp

   put empty into field 1

   repeat with i= 2147483646 to 2147483656
   set the randomseed to i
   put random(34) & cr after fld 1
   end repeat


end mouseUp

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Dave Cragg]

But I think the principal behind generating random numbers is  
different from generating a random seed. If we could generate a  
reliably random randomSeed then we would never need to do it.  We  
would be just as well to generate a reliably random sequence of random  
numbers.



On 13 Nov 2008, at 02:18, Randall Reetz wrote:

There is a huge difference between random and unique.  If you are  
after unique then just use the counting numbers.  If you need both  
random and unique you will have to check each number generated  
against a saved list of every previous number.  There is nothing  
wrong with a random number generator that spits out duplicate  
numbers.  Random is blind to history (and future).  Random is not  
nostalgic.  A coin with two sides is just as good at random as a  
pair of thousand sided dice.


Randall

-Original Message-
From: "Dave Cragg" <[EMAIL PROTECTED]>
To: "How to use Revolution" 
Sent: 11/12/2008 5:26 PM
Subject: Re: Random algorithm


It would seem that resetting the randomSeed each time you use the
random function would only have a 1-in-4,570,422 chance of getting
the same seed as the previous run, no?


Yes, but the chances of having the same seed as any of teh previous
runs becomes progressively larger. Is it not a bit like the shared
birthdays in a classroom. It only takes 23 people gathered in a room
to make the chance of two of them sharing a birthday more than 50%.

From my probably poor calculation, I think if you ran your randomSeed
algorithm about 2500 times, there would be a 50% chance that the same
randomSeed had been chosen at least twice. (At 4000, I think the
chance is over 80%) In many situations, I think a repeated sequence
would be worse than a biased sequence.

A long time since I did this kind of thing, so apologies if I have
this wrong.

Dave
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Dave Cragg]

Malte

It looks like I miscalculated the upper limit, or have goofed  
something entirely.


The script I ran first was this:

on mouseUp
   put the milliseconds  into tSeed
   set the randomSeed to tSeed
   put empty into field 1
   repeat 5
  put random (1000)  & cr after field 1
   end repeat
end mouseUp

This always gives me the same sequence:

671
250
597
371
78

When I use the script below, I get a different sequence each time as  
expected (so long as I wait at least 1 second between clicks.)


on mouseUp

   put the seconds  into tSeed
   set the randomSeed to tSeed
   put empty into field 1
   repeat 5
  put random (1000)  & cr after field 1
   end repeat

end mouseUp



On 13 Nov 2008, at 07:36, Malte Brill wrote:


Dave wrote:

> The  maximum number it can be set to seems to be 2130706432.

Hi Dave (and all)

I am not too sure about that, though I would love to know if there  
are upper limits. On my Intel mac I get:


9
4
34
30
25
21
16
12
8
3
33

on each run of the following script:

on mouseUp pMouseBtnNo
   repeat with i= 2130706432 to 2130706442
   set the randomseed to i
   put random(34) & cr after fld 1
   end repeat
end mouseUp

So it does not appear to be upper limited at 2130706432. Given the  
game writers perspective to this, I really like the way the random  
algorithm the way it is implemented in Revolution, as a seeded  
algorithm can be used in many ways in games. It prevents the ability  
to cheat with undo systems in casual games, or even lets you set up  
whole galaxies without stuffing memory.


Cheers,

Malte

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Re: Re: Random algorithm

[Malte Brill]

Dave wrote:

> The  maximum number it can be set to seems to be 2130706432.

Hi Dave (and all)

I am not too sure about that, though I would love to know if there are  
upper limits. On my Intel mac I get:


9
4
34
30
25
21
16
12
8
3
33

on each run of the following script:

on mouseUp pMouseBtnNo
repeat with i= 2130706432 to 2130706442
set the randomseed to i
put random(34) & cr after fld 1
end repeat
end mouseUp

So it does not appear to be upper limited at 2130706432. Given the  
game writers perspective to this, I really like the way the random  
algorithm the way it is implemented in Revolution, as a seeded  
algorithm can be used in many ways in games. It prevents the ability  
to cheat with undo systems in casual games, or even lets you set up  
whole galaxies without stuffing memory.


Cheers,

Malte

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Jan Schenkel]

--- Richard Gaskin <[EMAIL PROTECTED]> wrote:
> >>set the randomSeed to random(4570422)
> > 
> > In theory, that could result in the same series of
> > random numbers multiple times, as the first random
> may
> > start with the same randomseed as another, thus
> > resulting in the same random first number, and
> thus
> > the same second number and so forth.
> 
> I'm pretty sure I'm missing something that will make
> the dim light in my 
> head brighter.
> 
> It would seem that resetting the randomSeed each
> time you use the random 
> function would only have a 1-in-4,570,422 chance of
> getting the same 
> seed as the previous run, no?
> 
> -- 
>   Richard Gaskin
> 

If you set off with the same randomSeed, the random
function will return the same result; ergo you're
resetting the randomSeed with the same number, which
means the next number coming out of the random
function would also be the same.

Try it by making a stack with two buttons.

- The script of button 1
##
on mouseUp
  answer random(5)
end mouseUp
##

- The script of button 2
##
on mouseUp
  set the randomSeed to 1
  answer random(5)
end mouseUp
##

Save the stack to disk and open it in a second
Revolution instance. Then click the first button in
both instances, and chances are very slim that you'll
see the same number.

But click on the second button and you'll see two
answer boxes with the number 2082 - at least on my
iMac PPC, you may see a different number but it should
be the same in both instances.
This happens as the same calculation is applied to the
same randomSeed. One implementation that I've seen
involved adding a number and then multiplying with
another number, followed by a modulo operator to make
it fit in the upper limit.

So one shouldn't assume the original random(4570422)
will turn up a different number every time. Had the
randomSeed in the engine been initialized with 1, you
would end up with the same next randomSeed. Lucky for
us, the randomSeed is initialized wioth some magic
formula that makes it fairly unlikely that two
instances churn out the same numbers.

Jan Schenkel.

Quartam Reports & PDF Library for Revolution


=
"As we grow older, we grow both wiser and more foolish at the same time."  (La 
Rochefoucauld)


  
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Mark Brownell]

random(upperLimit - lowerLimit + 1) + lowerLimit - 1

Gads, I've given myself a headache. The Vegas stuff is interesting. The modern 
RNGs are safe up to a half a million spins for their one armed bandits. After 
that an attack can find repeats of the random sequences. Before they fixed it 
they were hacked from the inside by their own people and that was when they had 
to improve things. And that is where we are now with RNGs. Any sequence that 
starts from some unknown random seed will not have discernible repeats before 
500,000 unique numbers generated.

For my Blowfish CBC I use any number from 1 to 255, sixteen times to produce 
the first 16 characters to be encrypted. Then they are used to encrypt the next 
16 characters to be encrypted.

I could set the seed for each of those first 16 characters. That would be 
almost bomb proof for a brute force attack.

put random(1000 - 100 + 1) + (100 - 1) into hNewRandomSeed
set the randomSeed to hNewRandomSeed
put random(hNewRandomSeed - 100 + 1) + (100 - 1) into hNewRandomSeed
set the randomSeed to hNewRandomSeed
put random(hNewRandomSeed - 100 + 1) + (100 - 1) into hNewRandomSeed
set the randomSeed to hNewRandomSeed
put random(hNewRandomSeed - 100 + 1) + (100 - 1) into hNewRandomSeed
put random(38) into nextSpin

What a lively discussion.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[John Vokey]

All,

This has bugged me for a long time (back to the days of the Apple //,  
at least).  All programming languages should *document* their RNGs, so  
we have some idea of what they are, and, especially, how bad they are  
(and most are very bad).  LGN RNGs are not necessarily bad (a  
colleague and I developed some quite good ones, back in the day: , but, as Marsaglia has documented more recently, we can do so much  
better.  If you want the Rev (actually, old hypercard) code for my and  
Kaner's LNG RNGs, I can send it to you, but it is recursive (it  
replaces itself in place), so can only be used in the IDE or Rev  
Player (or any variant that doesn't render the RNG stack as a  
standalone).


But, the better principle is the more RNGs (even bad ones) the  
better.  Then, as Marsaglia demonstrated, simply *combine* them in  
some way: e.g., use RNG 1 to choose which of n RNGs you choose from  
next, use the result of that second RNG to select among the remaining  
n-1, and so on, until you get a number. Even a collection of bad RNGs  
will produce quite random numbers under Marsaglia's insight.



On 12-Nov-08, at 6:38 PM, [EMAIL PROTECTED] wrote:


Many thanks for your two cents !

I wonder if the first name of people answering my first question is
really random : Mark, Mark and Mark...

Jacques


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: Random algorithm

[Randall Reetz]

And another problem is that a random and unique solution actually reduces 
randomness as it is run.  Each time you eliminate a number, the set of numbers 
left is reduced.  This is even true of an infinate number randomizer.  
Sometimes i wonder if this fascination with random number generation isnt a 
good diagnosis of severe case of the geeks.

-Original Message-
From: "Randall Reetz" <[EMAIL PROTECTED]>
To: "How to use Revolution" 
Sent: 11/12/2008 6:18 PM
Subject: RE: Random algorithm

There is a huge difference between random and unique.  If you are after unique 
then just use the counting numbers.  If you need both random and unique you 
will have to check each number generated against a saved list of every previous 
number.  There is nothing wrong with a random number generator that spits out 
duplicate numbers.  Random is blind to history (and future).  Random is not 
nostalgic.  A coin with two sides is just as good at random as a pair of 
thousand sided dice.

Randall

-Original Message-
From: "Dave Cragg" <[EMAIL PROTECTED]>
To: "How to use Revolution" 
Sent: 11/12/2008 5:26 PM
Subject: Re: Random algorithm

> It would seem that resetting the randomSeed each time you use the  
> random function would only have a 1-in-4,570,422 chance of getting  
> the same seed as the previous run, no?

Yes, but the chances of having the same seed as any of teh previous  
runs becomes progressively larger. Is it not a bit like the shared  
birthdays in a classroom. It only takes 23 people gathered in a room  
to make the chance of two of them sharing a birthday more than 50%.

 From my probably poor calculation, I think if you ran your randomSeed  
algorithm about 2500 times, there would be a 50% chance that the same  
randomSeed had been chosen at least twice. (At 4000, I think the  
chance is over 80%) In many situations, I think a repeated sequence  
would be worse than a biased sequence.

A long time since I did this kind of thing, so apologies if I have  
this wrong.

Dave
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: Random algorithm

[Randall Reetz]

There is a huge difference between random and unique.  If you are after unique 
then just use the counting numbers.  If you need both random and unique you 
will have to check each number generated against a saved list of every previous 
number.  There is nothing wrong with a random number generator that spits out 
duplicate numbers.  Random is blind to history (and future).  Random is not 
nostalgic.  A coin with two sides is just as good at random as a pair of 
thousand sided dice.

Randall

-Original Message-
From: "Dave Cragg" <[EMAIL PROTECTED]>
To: "How to use Revolution" 
Sent: 11/12/2008 5:26 PM
Subject: Re: Random algorithm

> It would seem that resetting the randomSeed each time you use the  
> random function would only have a 1-in-4,570,422 chance of getting  
> the same seed as the previous run, no?

Yes, but the chances of having the same seed as any of teh previous  
runs becomes progressively larger. Is it not a bit like the shared  
birthdays in a classroom. It only takes 23 people gathered in a room  
to make the chance of two of them sharing a birthday more than 50%.

 From my probably poor calculation, I think if you ran your randomSeed  
algorithm about 2500 times, there would be a 50% chance that the same  
randomSeed had been chosen at least twice. (At 4000, I think the  
chance is over 80%) In many situations, I think a repeated sequence  
would be worse than a biased sequence.

A long time since I did this kind of thing, so apologies if I have  
this wrong.

Dave
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Noel]

I came into this discussion late, so apologies if this has been mentioned.

Have you considered utilizing http://www.random.org  ?

They might have something available that would work for a solution.

 - Noel

At 04:58 PM 11/12/2008, you wrote:


Le 12 nov. 2008 à 23:41, Richard Gaskin a écrit  (excerpts):


for pure science, probably not.  But for getting work done in Rev,
maybe.


One not-so-marginal problem is the criticism of pernickery* referees
when you (try to) publish your results. They DO want pure science, and
usually ask how you did obtain your random numbers !


What is the application in question?



The application I'm developping presently is a general-purpose analyse
program of ecological data mostly designed for students training (but
it should be useful for "serious" work too). I don't want a good RNG
for THIS application only, it's to be used as a library for several
applications, mostly simulations in population biology and population
genetics, but also research of solutions of systems of equations by
processes like simulated annealing. And I suppose you will be glad to
hear that I find Revolution excellent to built such simulations, and
decently fast even without using externals. One quality of Revolution
is the ease to produce (among other things) a visual and animated view
of the progress of the simulation (progressive spreading and
diversification of genes across a geographic area with variable
climatic conditions, for instance). As a teacher, I like that, among
plenty of other qualities of Rev. As a researcher, I like also the
possibility to easy built quick-and-dirty, but efficient, programs to
solve problems when you meet them. And as an emeritus (hum,hum)
professor, I want to use some of the time suddently available to
replace my quick-and-dirty programs by well presented and well
structured applications. Made with Revolution, of course !

Jacques

* I went to the dictionary for this one ;o)

**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax:++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: [EMAIL PROTECTED]
***

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe 
and manage your subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Jacques Hausser]

Hi Richard,

In the future, why not ? But I would be ashamed to show my quick-and- 
dirty scripts in their present state...


Jacques


Le 13 nov. 2008 à 01:41, Richard Gaskin a écrit :


Any chance we'll see a screen shot or two of the output and/or input  
UIs?


Simulations are an interest of mine but one I've had little chance  
to dabble in, so I've had to be content reading about others' work.   
I may have the opportunity to port a predation simulation related to  
a prehistoric North American tribe, but such projects don't come  
along often.


Can you tell us anything about its innards?  Perhaps in an article  
for revJournal.com?  I'm sure it would be of interest to a great  
many people.

Richard Gaskin
Managing Editor, revJournal
___
Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax:++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: [EMAIL PROTECTED]
***

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Dave Cragg]

It would seem that resetting the randomSeed each time you use the  
random function would only have a 1-in-4,570,422 chance of getting  
the same seed as the previous run, no?


Yes, but the chances of having the same seed as any of teh previous  
runs becomes progressively larger. Is it not a bit like the shared  
birthdays in a classroom. It only takes 23 people gathered in a room  
to make the chance of two of them sharing a birthday more than 50%.


From my probably poor calculation, I think if you ran your randomSeed  
algorithm about 2500 times, there would be a 50% chance that the same  
randomSeed had been chosen at least twice. (At 4000, I think the  
chance is over 80%) In many situations, I think a repeated sequence  
would be worse than a biased sequence.


A long time since I did this kind of thing, so apologies if I have  
this wrong.


Dave
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Richard Gaskin]

Jacques Hausser wrote:

> The application I'm developping presently is a general-purpose analyse
> program of ecological data mostly designed for students training (but
> it should be useful for "serious" work too). I don't want a good RNG
> for THIS application only, it's to be used as a library for several
> applications, mostly simulations in population biology and population
> genetics, but also research of solutions of systems of equations by
> processes like simulated annealing. And I suppose you will be glad to
> hear that I find Revolution excellent to built such simulations, and
> decently fast even without using externals. One quality of Revolution
> is the ease to produce (among other things) a visual and animated view
> of the progress of the simulation (progressive spreading and
> diversification of genes across a geographic area with variable
> climatic conditions, for instance). As a teacher, I like that, among
> plenty of other qualities of Rev. As a researcher, I like also the
> possibility to easy built quick-and-dirty, but efficient, programs to
> solve problems when you meet them. And as an emeritus (hum,hum)
> professor, I want to use some of the time suddently available to
> replace my quick-and-dirty programs by well presented and well
> structured applications. Made with Revolution, of course !

If you'll parson the California colloquialism, those sims sound way 
flippin' cool!  :)


Any chance we'll see a screen shot or two of the output and/or input UIs?

Simulations are an interest of mine but one I've had little chance to 
dabble in, so I've had to be content reading about others' work.  I may 
have the opportunity to port a predation simulation related to a 
prehistoric North American tribe, but such projects don't come along often.


Can you tell us anything about its innards?  Perhaps in an article for 
revJournal.com?  I'm sure it would be of interest to a great many people.



> One not-so-marginal problem is the criticism of pernickery* referees
> when you (try to) publish your results.
...
> * I went to the dictionary for this one ;o)

Good find. :)

--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Dave Cragg]

On 12 Nov 2008, at 21:21, Jan Schenkel wrote:

If memory serves me well (and I admit mine is
comparable to that of a goldfish) then the engine
initializes the randomseed to the value of the
milliseconds at startup.


I thought the same. But while playing just now (as a result of this  
thread :-)), I see that setting the randomSeed to the milliseconds  
actually produces the same sequence of random numbers on each run. The  
maximum number it can be set to seems to be 2130706432. Any number  
higher, and the same sequence is produced. (on an Intel Mac)


Not sure if this is a bug, or just an undocumented limitation.

Dave


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Jacques Hausser]

Le 12 nov. 2008 à 23:41, Richard Gaskin a écrit  (excerpts):

for pure science, probably not.  But for getting work done in Rev,  
maybe.


One not-so-marginal problem is the criticism of pernickery* referees  
when you (try to) publish your results. They DO want pure science, and  
usually ask how you did obtain your random numbers !



What is the application in question?



The application I'm developping presently is a general-purpose analyse  
program of ecological data mostly designed for students training (but  
it should be useful for "serious" work too). I don't want a good RNG  
for THIS application only, it's to be used as a library for several  
applications, mostly simulations in population biology and population  
genetics, but also research of solutions of systems of equations by  
processes like simulated annealing. And I suppose you will be glad to  
hear that I find Revolution excellent to built such simulations, and  
decently fast even without using externals. One quality of Revolution  
is the ease to produce (among other things) a visual and animated view  
of the progress of the simulation (progressive spreading and  
diversification of genes across a geographic area with variable  
climatic conditions, for instance). As a teacher, I like that, among  
plenty of other qualities of Rev. As a researcher, I like also the  
possibility to easy built quick-and-dirty, but efficient, programs to  
solve problems when you meet them. And as an emeritus (hum,hum)  
professor, I want to use some of the time suddently available to  
replace my quick-and-dirty programs by well presented and well  
structured applications. Made with Revolution, of course !


Jacques

* I went to the dictionary for this one ;o)

**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax:++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: [EMAIL PROTECTED]
***

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Joe Lewis Wilkins]

Thank you Richard. My middle name. (smile)

Joe Wilkins

On Nov 12, 2008, at 2:44 PM, Richard Gaskin wrote:


Joe Lewis Wilkins wrote:
In my personal use, I have followed the users mouse clicks, used  
the  last one to plug into a pretty exotic personal equation that  
spits out  a seed number for use. Since the mouse clicks of a user  
are pretty  much uncharted, except for being limited pretty much to  
the  screenrect, a fairly high degree of unpredictability should  
ensue.


Damn clever, Joe.  Inspiringly simple.  Almost devious. :)

--
Richard Gaskin
Managing Editor, revJournal
___
Rev tips, tutorials and more: http://www.revJournal.com
___





___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Richard Gaskin]

Joe Lewis Wilkins wrote:
In my personal use, I have followed the users mouse clicks, used the  
last one to plug into a pretty exotic personal equation that spits out  
a seed number for use. Since the mouse clicks of a user are pretty  
much uncharted, except for being limited pretty much to the  
screenrect, a fairly high degree of unpredictability should ensue.


Damn clever, Joe.  Inspiringly simple.  Almost devious. :)

--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Richard Gaskin]

Jacques Hausser wrote:

>>> --- Richard Gaskin  wrote:
 Me too.  Wouldn't it suffice to do this before each
 run?:
   set the randomSeed to random(4570422)
...
>> It would seem that resetting the randomSeed each time you use the
>> random function would only have a 1-in-4,570,422 chance of getting
>> the same seed as the previous run, no?
>
> It depends of what you use to reset the randomSeed.

Right.  Using even a psuedo-random number would seem acceptable in most 
cases because it's being used to reset the basis of the next 
psuedo-random number.


By changing the basis each time it's run, it would seem that the 
likelihood of emerging patterns would be greatly reduced.


Since Rev's randomSeed is in the range of 4 million+, it seems that it 
would take an extraordinarily large sequence of operations to have any 
discernible pattern.



> Some papers (reference burried to deep in my memory to be retrieved)
> suggest to generate an array of random numbers at start, and then to
> reset the seed each time it's needed with one of these elements, the
> index being randomly choosen. And the first x random numbers you draw
> are used to replace the array for the next time...
> But that is only a sophisticated kind of reshuffling.
> I just looked at the Web of Science for "Random number generator":
> 1252 papers. I do not think there is ONE obvious solution...

For pure science, probably not.  But for getting work done in Rev, maybe.

True, the method I mentioned above is still not truly "random", but some 
philosophers among us might argue that in the meta-patterns that drive 
the universe there is ultimately no such thing as pure "randomness". 
Even roulette wheels have a discernible bias; more than a few people 
have made good money from observing them carefully (which is why casinos 
today often swap wheels among tables periodically).



So all that said, I'm having a tough time imagining the sorts of 
applications for which a one-in-four-million chance of having a pattern 
which even then might be discernible only after hundreds of thousands of 
iterations would be built in Rev.


Maybe I just missed something from an earlier post.

What is the application in question?

People build the most amazing stuff with this tool

--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Joe Lewis Wilkins]

Gentle Rev users,

If you have ever watched any of the History Channels exposés regarding  
this topic, the Las Vegas gerús have come to the conclusion that there  
is no such thing as a random number generator, or they would be using  
it to foil "us". Read all you want, but it is a waste of time to  
expect that you will ever come up with anything that is truly random.  
In my personal use, I have followed the users mouse clicks, used the  
last one to plug into a pretty exotic personal equation that spits out  
a seed number for use. Since the mouse clicks of a user are pretty  
much uncharted, except for being limited pretty much to the  
screenrect, a fairly high degree of unpredictability should ensue. I  
haven't used this with Rev, so I'm not sure how well one can hide the  
personal equation.


My 2 centavos,

Joe Wilkins

On Nov 12, 2008, at 2:06 PM, Jacques Hausser wrote:

It depends of what you use to reset the randomSeed.  Some papers  
(reference burried to deep in my memory to be retrieved) suggest to  
generate an array of random numbers at start, and then to reset the  
seed each time it's needed with one of these elements, the index  
being randomly choosen. And the first x random numbers you draw are  
used to replace the array for the next time...

But that is only a sophisticated kind of reshuffling.
I just looked at the Web of Science for "Random number generator":  
1252 papers. I do not think there is ONE obvious solution...


Jacques


Le 12 nov. 2008 à 22:30, Richard Gaskin a écrit :


Jan Schenkel wrote:


--- Richard Gaskin  wrote:

Mark Brownell wrote:
> I'm surprised that the random seed was not
mentioned.
Me too.  Wouldn't it suffice to do this before each
run?:
 set the randomSeed to random(4570422)

In theory, that could result in the same series of
random numbers multiple times, as the first random may
start with the same randomseed as another, thus
resulting in the same random first number, and thus
the same second number and so forth.


I'm pretty sure I'm missing something that will make the dim light  
in my head brighter.


It would seem that resetting the randomSeed each time you use the  
random function would only have a 1-in-4,570,422 chance of getting  
the same seed as the previous run, no?


--
Richard Gaskin
Managing Editor, revJournal
___
Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax:++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: [EMAIL PROTECTED]
***




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Jacques Hausser]

It depends of what you use to reset the randomSeed.  Some papers  
(reference burried to deep in my memory to be retrieved) suggest to  
generate an array of random numbers at start, and then to reset the  
seed each time it's needed with one of these elements, the index being  
randomly choosen. And the first x random numbers you draw are used to  
replace the array for the next time...

But that is only a sophisticated kind of reshuffling.
I just looked at the Web of Science for "Random number generator":  
1252 papers. I do not think there is ONE obvious solution...


Jacques


Le 12 nov. 2008 à 22:30, Richard Gaskin a écrit :


Jan Schenkel wrote:


--- Richard Gaskin  wrote:

Mark Brownell wrote:
> I'm surprised that the random seed was not
mentioned.
Me too.  Wouldn't it suffice to do this before each
run?:
  set the randomSeed to random(4570422)

In theory, that could result in the same series of
random numbers multiple times, as the first random may
start with the same randomseed as another, thus
resulting in the same random first number, and thus
the same second number and so forth.


I'm pretty sure I'm missing something that will make the dim light  
in my head brighter.


It would seem that resetting the randomSeed each time you use the  
random function would only have a 1-in-4,570,422 chance of getting  
the same seed as the previous run, no?


--
Richard Gaskin
Managing Editor, revJournal
___
Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax:++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: [EMAIL PROTECTED]
***

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Richard Gaskin]

Jan Schenkel wrote:


--- Richard Gaskin  wrote:

Mark Brownell wrote:
> I'm surprised that the random seed was not
mentioned.

Me too.  Wouldn't it suffice to do this before each
run?:

   set the randomSeed to random(4570422)


In theory, that could result in the same series of
random numbers multiple times, as the first random may
start with the same randomseed as another, thus
resulting in the same random first number, and thus
the same second number and so forth.


I'm pretty sure I'm missing something that will make the dim light in my 
head brighter.


It would seem that resetting the randomSeed each time you use the random 
function would only have a 1-in-4,570,422 chance of getting the same 
seed as the previous run, no?


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Jan Schenkel]

--- Richard Gaskin <[EMAIL PROTECTED]> wrote:
> Mark Brownell wrote:
> > I'm surprised that the random seed was not
> mentioned.
> 
> Me too.  Wouldn't it suffice to do this before each
> run?:
> 
>set the randomSeed to random(4570422)
> 
> 
> -- 
>   Richard Gaskin
> 

In theory, that could result in the same series of
random numbers multiple times, as the first random may
start with the same randomseed as another, thus
resulting in the same random first number, and thus
the same second number and so forth.

If memory serves me well (and I admit mine is
comparable to that of a goldfish) then the engine
initializes the randomseed to the value of the
milliseconds at startup. Which means that unless
you're a really-really-fast doubleclicker, two
separate Rev instances will give you different random
numbers out of the box.

The ability to set the randomSeed is great, but it's
even better that it starts off random, unlike .NET
where you actually have to kick off the randomseed
with something before you use the randomizer,
otherwise you end up with the same series of 'random'
numbers every time you run the same application.

Jan Schenkel.

Quartam Reports & PDF Library for Revolution


=
"As we grow older, we grow both wiser and more foolish at the same time."  (La 
Rochefoucauld)


  
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Mark Smith]

It all depends on what you need.

This wouldn't do for high quality cryptography, for instance, since a  
brute-force trial of possible seeds would eventually produce the same  
sequence of numbers.


For many other purposes, the fact that rev sets a new randomseed  
every time it starts up is good enough.


Best,

Mark

On 12 Nov 2008, at 19:54, Richard Gaskin wrote:


set the randomSeed to random(4570422)


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Brian Yennie]

Although this is fit for 99% of people's purposes, I would be careful  
about expecting randomSeed or multiple samples to actually improve the  
underlying random algorithm.


For sake of a silly example, suppose you had a "bad" random algorithm  
which only returns even numbers. No matter how many samples and seeds  
you took, you'd still have a hard time generating odd numbers.


Point being, using a random() function many times doesn't necessarily  
make it of better quality for crypto or other serious purposes. It  
just makes it slightly more obscure to the human eye.



Mark Brownell wrote:

I'm surprised that the random seed was not mentioned.


Me too.  Wouldn't it suffice to do this before each run?:

set the randomSeed to random(4570422)


--
Richard Gaskin
Managing Editor, revJournal




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Richard Gaskin]

Mark Brownell wrote:

I'm surprised that the random seed was not mentioned.


Me too.  Wouldn't it suffice to do this before each run?:

  set the randomSeed to random(4570422)


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Mark Smith]

Splitter :)

On 12 Nov 2008, at 19:09, J. Landman Gay wrote:


Mark Smith wrote:
One day, all people will be called Mark, unlike now, when it's  
only  people


The rest of us are named Jacque.

Jacques



Jacque

--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[J. Landman Gay]

Mark Smith wrote:
One day, all people will be called Mark, unlike now, when it's only 
 people


The rest of us are named Jacque.

Jacques



Jacque

--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Thomas McGrath III]

I am very glad that Mark posted the random seed idea. I have spent  
some time trying to get better random results in different projects  
but I think that reseting the random seed would have been a lot easier.


Regards,

Mark  (Tom McGrath)

Lazy River Software
[EMAIL PROTECTED]

iTunes Library Suite - libITS
Information and download can be found on this page:
http://www.lazyriversoftware.com/RevOne.html

On Nov 12, 2008, at 1:04 PM, Jacques Hausser wrote:


Many thanks for your two cents !

I wonder if the first name of people answering my first question is  
really random : Mark, Mark and Mark...


Jacques

Le 12 nov. 2008 à 18:46, Mark Brownell a écrit :

I'm surprised that the random seed was not mentioned. Please excuse  
this if someone has responded with that. I'm on digest mode.


I've solved the random RNG problem by simulating the function of  
the Roulette wheel. This idea of using random bits or like some  
websites do it is the clue. When Revolution starts up it sets a new  
random seed and uses that same seed until the application shuts  
down. If you reset the random seed for each spin, like on a  
roulette wheel, then you can combine several things that must  
happen before the ball lands in a single slot. You can randomize  
the spin speed, the wheel speed, the track resistance, the bumper  
strike positions or misses, and the slot fin strikes or misses. In  
this way, by combining several random conditions you can do as well  
as any accepted form of so called true randomness.


So I would stack about five different conditions that include  
millions of possibilities and use that to randomize the final  
outcome. I would always set a new random seed before starting.


My two cents,

another; Mark



Message: 8
Date: Tue, 11 Nov 2008 22:16:18 +0100
From: Jacques Hausser <[EMAIL PROTECTED]>
Subject: Random algorithm
Hi,

Does somebody know which algorithm is hidden behind the random
function ? Native random number generators have usually a poor
reputation, and I need trustable random numbers. I have translated  
the
Mersenne twister algorithm which works OK, but slowly (47  
milliseconds
for 1000 numbers against five for the random function). If the  
native

function is a good one, I'll keep it...

Thanks for any hint

Jacques











___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Mark Smith]

One day, all people will be called Mark, unlike now, when it's only  
 people


Best,

Mark

On 12 Nov 2008, at 18:04, Jacques Hausser wrote:


Many thanks for your two cents !

I wonder if the first name of people answering my first question is  
really random : Mark, Mark and Mark...


Jacques


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Jacques Hausser]

Many thanks for your two cents !

I wonder if the first name of people answering my first question is  
really random : Mark, Mark and Mark...


Jacques

Le 12 nov. 2008 à 18:46, Mark Brownell a écrit :

I'm surprised that the random seed was not mentioned. Please excuse  
this if someone has responded with that. I'm on digest mode.


I've solved the random RNG problem by simulating the function of the  
Roulette wheel. This idea of using random bits or like some websites  
do it is the clue. When Revolution starts up it sets a new random  
seed and uses that same seed until the application shuts down. If  
you reset the random seed for each spin, like on a roulette wheel,  
then you can combine several things that must happen before the ball  
lands in a single slot. You can randomize the spin speed, the wheel  
speed, the track resistance, the bumper strike positions or misses,  
and the slot fin strikes or misses. In this way, by combining  
several random conditions you can do as well as any accepted form of  
so called true randomness.


So I would stack about five different conditions that include  
millions of possibilities and use that to randomize the final  
outcome. I would always set a new random seed before starting.


My two cents,

another; Mark



Message: 8
Date: Tue, 11 Nov 2008 22:16:18 +0100
From: Jacques Hausser <[EMAIL PROTECTED]>
Subject: Random algorithm
Hi,

Does somebody know which algorithm is hidden behind the random
function ? Native random number generators have usually a poor
reputation, and I need trustable random numbers. I have translated  
the
Mersenne twister algorithm which works OK, but slowly (47  
milliseconds

for 1000 numbers against five for the random function). If the native
function is a good one, I'll keep it...

Thanks for any hint

Jacques


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax:++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: [EMAIL PROTECTED]
***

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Mark Brownell]

I'm surprised that the random seed was not mentioned. Please excuse this if 
someone has responded with that. I'm on digest mode.

I've solved the random RNG problem by simulating the function of the Roulette 
wheel. This idea of using random bits or like some websites do it is the clue. 
When Revolution starts up it sets a new random seed and uses that same seed 
until the application shuts down. If you reset the random seed for each spin, 
like on a roulette wheel, then you can combine several things that must happen 
before the ball lands in a single slot. You can randomize the spin speed, the 
wheel speed, the track resistance, the bumper strike positions or misses, and 
the slot fin strikes or misses. In this way, by combining several random 
conditions you can do as well as any accepted form of so called true randomness.

So I would stack about five different conditions that include millions of 
possibilities and use that to randomize the final outcome. I would always set a 
new random seed before starting.

My two cents,

another; Mark

>
>Message: 8
>Date: Tue, 11 Nov 2008 22:16:18 +0100
>From: Jacques Hausser <[EMAIL PROTECTED]>
>Subject: Random algorithm
>Hi,
>
>Does somebody know which algorithm is hidden behind the random  
>function ? Native random number generators have usually a poor  
>reputation, and I need trustable random numbers. I have translated the  
>Mersenne twister algorithm which works OK, but slowly (47 milliseconds  
>for 1000 numbers against five for the random function). If the native  
>function is a good one, I'll keep it...
>
>Thanks for any hint
>
>Jacques

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Jacques Hausser]

Very interesting ! I didn't know that... my information is slightly  
obsolete.


Many thanks

Jacques

Le 12 nov. 2008 à 03:34, Mark Smith a écrit :

Interestingly, on OS X and Linux, you can read from "/dev/random"  
and get crypto-quality random numbers:


 put "/dev/random" into tFile
 open file tFile for binary read
 read from file tFile for 1000 uint4
 put it into tRandNums
 close file tFile

will get you a comma delimited list of 1000 numbers bewteen 0 and 2  
^ 32.


I can't find anything similar on Windows, but maybe one of Ken's  
crafty VB scripts can get at the relevant OS API call  
"CryptGenRandom".


http://en.wikipedia.org/wiki/Urandom

Best,

Mark
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax:++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: [EMAIL PROTECTED]
***

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Mark Smith]

Interestingly, on OS X and Linux, you can read from "/dev/random" and  
get crypto-quality random numbers:


  put "/dev/random" into tFile
  open file tFile for binary read
  read from file tFile for 1000 uint4
  put it into tRandNums
  close file tFile

will get you a comma delimited list of 1000 numbers bewteen 0 and 2 ^  
32.


I can't find anything similar on Windows, but maybe one of Ken's  
crafty VB scripts can get at the relevant OS API call "CryptGenRandom".


http://en.wikipedia.org/wiki/Urandom

Best,

Mark
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Mark Smith]

Jaques, I wonder if it would be practical to do what some of the  
crypto-quality RNGs do, and use the microphone input of the users  
computer as a source of random bits.


Hmm..

Best,

Mark

On 11 Nov 2008, at 22:57, Jacques Hausser wrote:


Hi Mark (and Mark),

For small series, sure, it is random enough. But I'm afraid that  
the period is actually rather short for what I suppose is a linear  
congruential generator (for instance Excel algorithm was famous for  
its period of 32000 numbers only), not speaking of the pattern due  
to serial correlations you can detect if you spread your numbers in  
a multidimentional space. In contrast, Mersenne twister has  
theoretically a period of 4.3 E 106001-1, and does not show  
patterning in spaces of more than 600 dimensions. But even this  
algorithm is not fit for encryption... that's not my problem,  
luckily !
... and for the other Mark (Schonneville) to spare a mail ;o) : Its  
a very good idea, but not practicable in my case. I want the  
application to be an independant one, that the students can use not  
only in the formal exercise sessions, but also for their personnal  
work.


Thank you for your remarks and suggestions anyway

Jacques


Le 11 nov. 2008 à 23:02, Mark Smith a écrit :

Jacques, as you probably know, there are many measures of  
randomness...


Taking the 'r' correlation as a measure of it, I've done this test:

generate two series of 1000 numbers between 1 and 1 each,  
using the random() function. Take the correlation between the two  
series, and append it to a list.

repeat 1000 times
from that list of 1000 correlations, take the mean and standard  
deviation.


I got: mean correlation = -0.000681, standard deviation= 0.032986
on my macBookPro.

So is that random enough?

Best,

Mark

On 11 Nov 2008, at 21:16, Jacques Hausser wrote:


Hi,

Does somebody know which algorithm is hidden behind the random  
function ? Native random number generators have usually a poor  
reputation, and I need trustable random numbers. I have  
translated the Mersenne twister algorithm which works OK, but  
slowly (47 milliseconds for 1000 numbers against five for the  
random function). If the native function is a good one, I'll keep  
it...


Thanks for any hint

Jacques
**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax:++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: [EMAIL PROTECTED]
***

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax:++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: [EMAIL PROTECTED]
***

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Jacques Hausser]

Hi Mark (and Mark),

For small series, sure, it is random enough. But I'm afraid that the  
period is actually rather short for what I suppose is a linear  
congruential generator (for instance Excel algorithm was famous for  
its period of 32000 numbers only), not speaking of the pattern due to  
serial correlations you can detect if you spread your numbers in a  
multidimentional space. In contrast, Mersenne twister has  
theoretically a period of 4.3 E 106001-1, and does not show patterning  
in spaces of more than 600 dimensions. But even this algorithm is not  
fit for encryption... that's not my problem, luckily !
... and for the other Mark (Schonneville) to spare a mail ;o) : Its a  
very good idea, but not practicable in my case. I want the application  
to be an independant one, that the students can use not only in the  
formal exercise sessions, but also for their personnal work.


Thank you for your remarks and suggestions anyway

Jacques


Le 11 nov. 2008 à 23:02, Mark Smith a écrit :

Jacques, as you probably know, there are many measures of  
randomness...


Taking the 'r' correlation as a measure of it, I've done this test:

generate two series of 1000 numbers between 1 and 1 each, using  
the random() function. Take the correlation between the two series,  
and append it to a list.

repeat 1000 times
from that list of 1000 correlations, take the mean and standard  
deviation.


I got: mean correlation = -0.000681, standard deviation= 0.032986
on my macBookPro.

So is that random enough?

Best,

Mark

On 11 Nov 2008, at 21:16, Jacques Hausser wrote:


Hi,

Does somebody know which algorithm is hidden behind the random  
function ? Native random number generators have usually a poor  
reputation, and I need trustable random numbers. I have translated  
the Mersenne twister algorithm which works OK, but slowly (47  
milliseconds for 1000 numbers against five for the random  
function). If the native function is a good one, I'll keep it...


Thanks for any hint

Jacques
**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax:++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: [EMAIL PROTECTED]
***

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax:++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: [EMAIL PROTECTED]
***

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Mark Schonewille]

Hi Jacques,

Depending on the kind of project you are working on, you could  
download a few thousand (or more) random numbers from the site at once  
and simulate the random series for your students.


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
http://economy-x-talk.com
http://www.salery.biz
Dutch forum: http://runrev.info/rrforum

Color Converter has been updated! Get it at
http://colorconverter.economy-x-talk.com !

On 11 nov 2008, at 23:04, Jacques Hausser wrote:


Many thanks, Mark,

That's far better than an algorithm, (true random numbers, not  
pseudo ones ! ). I'll use it for "serious research" simulation  
programs, but not in the standalone I'll distribute to the students.  
I do not want random.org to be drowned under simultaneous queries  
from 70 people during their practicals !


All the best

Jacques



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Jacques Hausser]

Many thanks, Mark,

That's far better than an algorithm, (true random numbers, not pseudo  
ones ! ). I'll use it for "serious research" simulation programs, but  
not in the standalone I'll distribute to the students. I do not want  
random.org to be drowned under simultaneous queries from 70 people  
during their practicals !


All the best

Jacques


Le 11 nov. 2008 à 22:27, Mark Schonewille a écrit :


Hi Jacques,

You can find a library for random.org here: .


I have never seen any specific documention on the algorithm behind  
Rev's built-in random function. I suspect it is a standard C++  
function.


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
http://economy-x-talk.com
http://www.salery.biz
Dutch forum: http://runrev.info/rrforum

Color Converter has been updated! Get it at
http://colorconverter.economy-x-talk.com !

On 11 nov 2008, at 22:16, Jacques Hausser wrote:


Hi,

Does somebody know which algorithm is hidden behind the random  
function ? Native random number generators have usually a poor  
reputation, and I need trustable random numbers. I have translated  
the Mersenne twister algorithm which works OK, but slowly (47  
milliseconds for 1000 numbers against five for the random  
function). If the native function is a good one, I'll keep it...


Thanks for any hint




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax:++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: [EMAIL PROTECTED]
***

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Mark Smith]

Jacques, as you probably know, there are many measures of randomness...

Taking the 'r' correlation as a measure of it, I've done this test:

generate two series of 1000 numbers between 1 and 1 each, using  
the random() function. Take the correlation between the two series,  
and append it to a list.

repeat 1000 times
from that list of 1000 correlations, take the mean and standard  
deviation.


I got: mean correlation = -0.000681, standard deviation= 0.032986
on my macBookPro.

So is that random enough?

Best,

Mark

On 11 Nov 2008, at 21:16, Jacques Hausser wrote:


Hi,

Does somebody know which algorithm is hidden behind the random  
function ? Native random number generators have usually a poor  
reputation, and I need trustable random numbers. I have translated  
the Mersenne twister algorithm which works OK, but slowly (47  
milliseconds for 1000 numbers against five for the random  
function). If the native function is a good one, I'll keep it...


Thanks for any hint

Jacques
**
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax:++ 41 22 366 19 40
mobile: ++ 41 79 757 05 24
E-Mail: [EMAIL PROTECTED]
***

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Random algorithm

[Mark Schonewille]

Hi Jacques,

You can find a library for random.org here: .


I have never seen any specific documention on the algorithm behind  
Rev's built-in random function. I suspect it is a standard C++ function.


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
http://economy-x-talk.com
http://www.salery.biz
Dutch forum: http://runrev.info/rrforum

Color Converter has been updated! Get it at
http://colorconverter.economy-x-talk.com !

On 11 nov 2008, at 22:16, Jacques Hausser wrote:


Hi,

Does somebody know which algorithm is hidden behind the random  
function ? Native random number generators have usually a poor  
reputation, and I need trustable random numbers. I have translated  
the Mersenne twister algorithm which works OK, but slowly (47  
milliseconds for 1000 numbers against five for the random function).  
If the native function is a good one, I'll keep it...


Thanks for any hint




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution