World: r3wp

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.

Given a good algorithm (like Mersenne twister), and a true random 
generator for seeding (like hardware sensors) a computer could cover 
the 60**8 range. A humain brain, even given enough time, can't (I'm 
talking about generating random combinations, not using loops to 
generate every single combination). Even worse, humain results would 
show heterogeneous distribution of results, while computer will give 
a uniform distribution. So in that case, computers would give you 
better randomness than analog brains.

Yes, valid points, but it's not what I described at first.

If I should construct a random password given the rules, my output 
will land in a pool of 60 ** 8 possible passwords. I don't have to 
actual do it. The statement holds anyway.

If a computer should construct a random password given the rules 
(using any deterministic computer and any algorithm, but only with 
a 32-bit integer input, as in the case of REBOL random/seed), the 
output will land i a pool of 2 ** 32 possible passwords at most.


Of course we can change the frame and get a better result from the 
computer, but then we change the 'experiment'. In general, I would 
say the pool from human thoughts and decisions is infinite. It's 
not from a deterministic computer. So we need true random input and 
true analog computing with infinite states, if we want our computers 
to be as good as our brains.

Why restricting the computer to 32bits input only, when you can feed 
it with gigabits of inputs ? That's not a fair comparaison.

In general, I would say the pool from human thoughts and decisions 
is infinite

. That needs to be proved. It can be very high without being infinite.

In my password generator, how would you feed it with more input?

By using a better than REBOL default RANDOM function and using a 
source of true randomness for seeding.

That needs to be proved. It can be very high without being infinite.

I think, it's proven by quantum mechanics in the number of possible 
outcome from a wave equation.

Well...the magical "quantum" is back again. :-) Sorry, but you still 
didn't prove anything...Do we need to get back to how a neuron fires 
? Show me any experiment that has been done proving that neuron's 
firing is not deterministic (meaning it can be predicted knowing 
the inputs).

How do I use a better random function, now that it's a routine programmed 
in REBOL? I could get the source of a better routine and implement 
it myself. That will give me a better result, yes. I'm not going 
to do that, as my current routine is good enough for the purpose.


How do I access a source of true randomness from within REBOL? random.org 
has been suggested. Other ways?

Maybe this thread should be move in another channel

can = can't

reading mouse moves is usually a good source for seeding

Moving to chat

A long time ago, I remember reading something where the author suggested, 
as a shared seed, using a substring of PI.

a human picking chars "randomly" will most likely not be random. 
sadly, i guess we're not going to be able to do a test with a few 
million people to get a decent sample.

about 2 ** 32, that's a limitation of *your* algorithm, not RANDOM. 
indeed, if you don't reset the seed each time, and use random/secure, 
you probably get all of the possible passwords (and very likely more 
than humans would pick). besides, it is not proven that random/seed 
only takes 32 bits of data when seeded with a date!. (C rand() is 
most likely 32 bit, but random/secure could be using more than that.)

if you feed a human a 32 bit int and ask him/her to get you back 
a password, and it has to give you the same password for the same 
int, then how many password would the user give you?

besides... neurons are know to only be able to fire or not to fire. 
they are digital, not analog. if the input is above the threashold, 
the neuron fires. otherwise it does not fire.

wave equations have nothing to do with the human brain as far as 
we know it. if you know more, you should publish an article somewhere, 
as that would be a breakthrough.

A psych prof I knew, wrote papers on the quantum clock in our brains. 
 Google "kristofferson professor rate of tone and brain clock" for 
some references to his research. Sorry for clogging Core.  But yeah, 
his experiments concluded that we definetly think in "waves"; some 
events go undetected if they occur between 'brain ticks'.  He couldn't 
explain the 'how or why', but he could measure the effect.

As better at REBOL I am getting, I am trying to find the trick to 
rename the title of the Console window itself.  I am glad I can probe 
system, but I just haven't probed it in the right orafice...

Right now it is "REBOL/View" on the console title bar.  I know I'm 
gonna be embarrased when I find out what it is...

I do that via winapi calls currently.

I asked Carl years ago to allow us to change this within REBOL ... 
he agreed but has not done this.  So, I too use Winapi calls.

shucks.

win-lib: make object! [
	
	user-lib: load/library %user32.dll

	SetWindowText: make routine! [
		handle			[integer!]
		Title			[string!]
		return:			[integer!]
	] user-lib "SetWindowTextA"
	
	set 'WindowTitle func [
		Title [string!] 
	] [
		SetWindowText get-modes system/ports/system 'window Title
	]	
]

Actually maybe it was Terry that wrote this .. can't recall now.

Use Resource Hacker http://www.angusj.com/resourcehacker/to change 
the title and or icons.

Is there a way to get MAX-INT from Rebol?

I know it's 2 ** 31 - 1 but any other way? Is there an unsigned version 
as well?

>> to integer! #7fffffff
== 2147483647


No unsigned version directly. You might be able to make code, that 
can implement unsigned int.

Looks my solution for changing the name.)

Google api client libraries ... http://code.google.com/apis/gdata/clientlibs.html

No REBOL included of course