World: r3wp

no /seed - rebol always starts with the same seed (not sure, maybe 
0), in order to allow testing

The starting seed seems to be 1.

Ah yes, there is a 24 hour cycle problem with my approach. I could 
construct a more unique decimal taking year, month and day into account. 
Hm, random/seed returns a value, if called with a decimal!? Called 
with an integer, it doesn't. A reason for this?
>> random/seed 100
>> random/seed 100.0
== 41.0

Maybe random ignore the /seed and just give me a decimal random number?

Yes, random/seed with a decimal doesn't use the seed:

>> loop 10 [random/seed 1 random/seed to decimal! now/time/precise 
prin [random 100 ""]]                                            
                           
52 52 52 52 52 52 52 52 52 52

So I need to construct an integer from the time.

This is misleading to me. I got the impression, that I could do
random/seed to decimal! now/time/precise
but that's no good! Should it be reported as a bug/flaw?

It seems, that
random/seed now
does exactly the same as
random/seed now/precise
(Only tested under OS X so far.)

Does anyone know, that now/time show at midnight? Is it 24:00 or 
0:00?

that -> what

try to switch you PC to 23:59 and do some loop which will print time 
:-)

Oh no, I go for 0:00. :-)

A suggestion for an algorithm to produce a random seed from the time:


s: to integer! 2 ** 32 / 86400 * (to decimal! now/time/precise) - 
(2 ** 31)
s: enbase/base debase/base to-hex s 16 2
reverse s
s: to integer! to issue! enbase/base debase/base s 2 16
random/seed s

It does this:
1) convert now/time/precise to an integer using all possible bits
2) make a string of 0 and 1 from it
3) reverse the string
4) convert it back to an integer
5) And finally use it as a seed


Doing it this way, I hope to have a good span of possible start values 
for the random generator. Did I miss anything?

Now I think of it, all this probably isn't necessary, because the 
actual number of possible outcome of my routine still is low compared 
to all the bits in an integer. I don't get 2 ** 32 possible passwords 
from this. If the routine is mainly used doing the day (maybe 12 
hours), I still just get half the possible outcome, even with all 
this, right?

So this should be about as good:

random/seed to integer! 2 ** 32 / 86400 * (to decimal! now/time/precise) 
- (2 ** 31)

This might be a good example to illustrate my point in the other 
thread about randomness and the difference between digital computers 
and analog human brains.


In my example, I'm about to produce a 8 character random password. 
Each character can be one of 60 possible chars. So I set up a random/seed 
with 2 ** 32 = 4'294'967'296 possible start values, so I can at best 
produce the same amount, 4'294'967'296, different passwords with 
my routine. I can't change this by putting new random/seed in after 
each character found, because of the determinism in how a computer 
work. I would need to get input from the outside to produce more 
different 8 char passwords.


As a human, I can pick between 60 possible chars, and I have to do 
it 8 times, so I can make 60 ** 8 = 167'961'600'000'000 different 
passwords. That's a lot more than the computer. When we go to abstract 
thoughts with no clear limits (like 60 and 8), we are far superior 
to the digital computer.


It would be much easier to make an artificial intelligence, if our 
computers were analog.

You could grab some starter randomness from
   http://random.org

Yes, something like that would be needed between each character to 
raise the number of possible passwords produced.

The pseudo-random generator used in REBOL (rand( ) C function) like 
in most other languages, is not limited to the size of the seed, 
it doesn't work that way. The seed just gives the starting point 
in a series of values produced by a math formula with a far greater 
range than the 32 or 64bits would give. So, if your code is correctly 
written, you'll get close to 60 ** 8 possible passwords (depends 
on the quality of value distribution in the internal math formula). 
The C rand( ) is notoriously poor, but far enough for most uses. 
IIRC python, for example, uses a different generator with a period 
or 2**19937-1.

John wrote "It seems to be 1."


And this is probably correct from a social point of view.  But I 
will stick with "unkown without extensive testing" because many integers 
can give the same sequence, and might even give the same sequence 
for a long time before they diverge.


This is the subtle point I'm trying to make about what is random 
vs pattern.


Things that "seem" are the reason hackers crack codes…this is where 
I used to start when I cracked other people's systems…

The seed just gives the starting point in a series of values produced 
by a math formula with a far greater range than the 32 or 64bits 
would give. So, if your code is correctly written, you'll get close 
to 60 ** 8 possible passwords


That's interesting. Do you know a good link, where I can read more 
about this?

google for pseudo number generator

pseudo random number generator

I guess that a good start woul be : http://en.wikipedia.org/wiki/Pseudorandom_number_generator

It puzzles me, how you can get more than 2 ** 32 possible outcome 
from 2 ** 32 different input, so I'll start reading... :-)

My test show, that random/secure give the exact same sequence of 
numbers every time, if started with the same seed. Check it with 
code like:

>> random/seed 1 loop 1000000 [random/secure 10000000] random/secure 
10000000
== 1253129

>> x: 1 loop 10 [random/seed 1 loop 1000000 [random/secure 10000000] 
if 1253129 <> random/secure 10000000 [print x] x: x + 1]


So I conclude, that I can only make 2 ** 32 different passwords with 
this, not 60 ** 8.

Do you need the passwords to be unique?

that random/secure give the exact same sequence of numbers every 
time, if started with the same seed

 That's an intended feature ! You should set the seed only *once* 
 with a random (or pseudo-random) value like now/time.

Peter, I'm just investigating, what's the best way to produce random 
passwords. In some applications, they might need to be unique, not 
in others. If they need to be unique, the easiest would be to check 
with passwords produced in the past, I guess.

A psuedo-random generator should always give the same sequence if 
you start with the same seed. That's what Reichart was saing. Try 
the site that Sunanda suggested for an explanation; random.org

Doc, then I can't see, how I can get close to 60 ** 8 different passwords, 
as you claimed.

Peter, yes random.org is a solution, and a good one. But it doesn't 
hold in a real application, because what if there's no web connection. 
I have a routine, that is good enough for my problem. What I'm after, 
is the best way to do this. I and others might learn from this.

The more I think about it, the more I come to the conclusion that 
you're right. REBOL's random function might have a period of 2**32 
(with a 32bits seed) maybe even less (I can't find the exact period 
of C rand( )).

!!! :-)

You should maybe search for a free implementation of Mersenne twister 
generator, it can give you up to 2**19937 unique combinations which 
is far enough for covering the 60**8 range. http://en.wikipedia.org/wiki/Mersenne_twister

So a way to get good random numbers over a long period of time, is 
to start such a routine (like the Mersenne twister) only once. The 
routine should then work with a high number of bits, the more the 
better and store the state, it has come to, to disk. Every time the 
computer is turned on, it can pick the state from disk, and start 
from where it left off. A password generator should use this routine 
and call it between each character in the password. If the routine 
has high enough resolution, it should be possible to produce 60 ** 
8 different passwords.

Exactly.

Cool, thanks! :-)

And if a hacker get acces to the state stored on disk, we're screwed 
again. ;-)

The algorithm used in the C library provided with gcc has a period 
of  2.88 * 10E9
 http://hepwww.ph.qmul.ac.uk/sim/random.html

This is the randomize func I use, FWIW: Alan Parman did quite a bit 
of R&D and posted this as his best solution.

    randomize: func [
        "Reseed the random number generator."

        /with seed "date, time, and integer values are used directly; others 
        are converted."
    ][

        random/seed either find [date! time! integer!] type?/word seed [seed] 
        [

            to-integer checksum/secure form any [seed now/precise]
        ]
    ]

And if a hacker get acces to the state stored on disk, we're screwed 
again. ;-)

And that is why we set the random seed randomly...

John;  If you ever get a chance, check out R.   http://www.r-project.org
  It's a statistical analysis language (in the main) and goes to 
great length to ensure a reproducible random sequence on each run. 
  This allows for verification, stable screen shots of sample graphs 
etc.   I like the fact that REBOL has the same feature of "known" 
random numbers across runs, until a forced seeding.


In Quebec, someone figured out the sequence of the provinicial Keno 
game.  He won three times before someone got suspicious.  The lotto 
corp wanted to deny him his prize money.  A judge ruled that if they 
did, they would have to deny and claw back all winnings from everyone. 
 So they paid.  And fumed and puffed out their chest, and then went 
back to school to learn better programming.   :)   Last I heard, 
the guy hasn't cracked the new sequence ... yet.

I installed R on my Mac more than a year ago, but haven't found the 
time to use it yet (or did't find the need). I've heard, it should 
be good at doing graphs.

Yep.  Bean counter code by bean counter people.   :)   But the  random 
packages, there are at least five, go into great detail and the issues. 
  Then again, this is REBOL/Core.  Beats the pants off R, we just 
lack the bean counters.  :)

Keno, yup....keno programmers are like script kiddies...

lol, so if you pick each character separately you don't make 60 ** 
8 different password? Geomol, you're being really funny. I guess 
this is what happens when religion takes the place of logic.

:-)
No, it's what happens, when insight takes the place of ignorance.

(For the record, I'm not religious.)

so if you pick each character separately you don't make 60 ** 8 different 
password?


If I, as a human, pick each char separately, I can make 60 ** 8 different 
passwords. If I make a digital computer do it based on 2 ** 32 integer 
pseudo-randomness, I can't! If you disagree, then show me. Doc seems 
to get it now, so I'm not completely alone with my insight.

I'm not fair using the word "ignorance". I don't think, you are. 
I base my conclusion on the following:


See the password generator as a black box, that you feed with an 
integer, and out come a password. The integer input has 2 ** 32 different 
combinations and is used for the random/seed. Out come a password, 
and there can only be 2 ** 32 different passwords coming out at most. 
It doesn't matter, how the algorithm is constructed, if you put time 
delay in, call random or random/seed more than once, etc, as long 
as you don't get other input as the first integer. This is basic 
in information theory. And it's related to the determinism in digital 
computing.