World: r3wp

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

Google is really specific about which languages it will support itself 
- they won't even let their employees use alternate languages for 
Google products. REBOL's niche is taken up by Python there. Nothing 
stopping you from cloning one of the official APIs for a third-party 
API though.

Hi, how can I avoid to get back NONE for something like this:
	a: compose [ (if 0 > 1 ["b"]) ]


I just want to get nothing back, like the parens were never there.

>> void: [ ]
>> a: compose [ (either 0 > 1 ["b"][void]) ]
== [ ]

Ok... very tricky. ;-)

if you want to hide the "tricky part" :

>> if*: func [cond body][either cond body [[ ]]]
>> a: compose [ (if* 0 > 1 ["b"]) ]
== [ ]

>> a: compose [(either 0 > 1 ["b"][])]
== []

Does protect work inside an object's context?  For example if i have 
a: context [b: 0]  can I then protect 'b from being changed?

I might be able to figure this out if I take a look at the protect-system.

In cases like this, Robert, I usually use somthing like

>> pass: func [value] [any [value []]]

which makes code somewhat readable

>> a: compose [ (pass if 0 > 1 ["b"]) ]

Clean and simple solution.

a: compose [(pick [["b"][]] 0 > 1)]

If I wish to compute a checksum on an image file, I can do this

checksum read/binary %image.png


but how do I get the same result when I have the image as image data 
?

eg. i: load %image.png

and to compute the checksm on i ?

guess I can't

convert it to binary first

or if you want to avoid loading the image twice:

i: read/binary %image.png
checksum i
i: load i