Math.random() algorithm

[Johannes Baagoe]

About Math.random(), ECMA 262 just says "Returns a number value with
positive sign, greater than or equal to 0 but less than 1, chosen randomly
or pseudo randomly with approximately uniform distribution over that
range, using an implementation-dependent algorithm or strategy."

This is not good enough for my purposes (to generate identifiers with
sufficient entropy, say 256 bits or so, to effectively preclude any chance
of any two calls ever pricking the same), but it may be a starting point.

Does anyone have information about the Math.random() function in various
implementations?

More generally, is there any reliable way of picking up good noise, except
by setting up a server and calling it, say, with XMLHTTRequest?

--
Johannes
"Quand on dit c'est un Johannes, cela vaut autant que ce que maintenant
on appelle un pédant" (H. Estienne, in Littré, art. PÉDANT)

[Bart Van der Donck]

Johannes Baagoe wrote:

About Math.random(), ECMA 262 just says "Returns a number value with
positive sign, greater than or equal to 0 but less than 1, chosen randomly
or pseudo randomly with approximately uniform distribution over that
range, using an implementation-dependent algorithm or strategy."

This is not good enough for my purposes (to generate identifiers with
sufficient entropy, say 256 bits or so, to effectively preclude any chance
of any two calls ever pricking the same), but it may be a starting point.

Does anyone have information about the Math.random() function in various
implementations?

http://www.merlyn.demon.co.uk/js-randm.htm should keep you busy for a
while.

More generally, is there any reliable way of picking up good noise, except
by setting up a server and calling it, say, with XMLHTTRequest?

var unique_url = 'file.php?' + (new Date()).getTime();

Hope this helps,

--
Bart

[Johannes Baagoe]

Bart Van der Donck :

Johannes Baagoe :

>Does anyone have information about the Math.random() function in various
implementations?

http://www.merlyn.demon.co.uk/js-randm.htm should keep you busy for a
while.

About half an hour, since the interesting stuff appears to be off-line.

But if the parallel with Borland Pascal/Delphi is valid, the algorithm
would be good old linear congruential Ã* la Lehmer, which is both a bit
surprising for floating point random functions and certainly not good
enough especially when seeded with something as predictable as time.

>More generally, is there any reliable way of picking up good noise,
except by setting up a server and calling it, say, with XMLHTTRequest?

var unique_url = 'file.php?' + (new Date()).getTime();

That most certainly does not qualify as *good* noise, sorry...

http://www.random.org/integers/?num=...col=16&base=16
is more in line with what I want.

Hope this helps

It did, to a certain extent: ascertaining a negative is always useful.

--
Johannes
"Quand on dit c'est un Johannes, cela vaut autant que ce que maintenant
on appelle un pédant" (H. Estienne, cité dans le Littré, art. PÉDANT)

[Erwin Moller]

Johannes Baagoe wrote:

About Math.random(), ECMA 262 just says "Returns a number value with
positive sign, greater than or equal to 0 but less than 1, chosen randomly
or pseudo randomly with approximately uniform distribution over that
range, using an implementation-dependent algorithm or strategy."

This is not good enough for my purposes (to generate identifiers with
sufficient entropy, say 256 bits or so, to effectively preclude any chance
of any two calls ever pricking the same), but it may be a starting point.

Does anyone have information about the Math.random() function in various
implementations?

More generally, is there any reliable way of picking up good noise, except
by setting up a server and calling it, say, with XMLHTTRequest?

Hi Johannes,

Personally I WOULD go serverside if the 'quality' of the random numbers
is important for your current task.
You didn't tell us why you need 256 bits of entropy, but if you use
javascript you will stay OS/Browser dependent.
So you're stuck with finding out which OS/browser combi does what. Quite
a job.
Unless you find a nice trustworthy webpage that sums it all up. (I did a
quick search but could find one.)

I think you are probably better of using a good random package on the
server.
In case you need 1000 numbers, just let the server generate 1000 good
random numbers.
And get them in with a XMLHTTRequest.
Why do you want to avoid that solution (you gave yourself already)?

Or even use REAL random bytes, generated by nuclear radiation.
eg: http://www.fourmilab.ch/hotbits/how3.html

Not sure this helped. ;-)
Good luck.

Regards,
Erwin Moller

[Dr J R Stockton]

In comp.lang.javascript message <GK*********************@giganews.com>,
Tue, 4 Sep 2007 09:08:49, Johannes Baagoe <ba****@baagoe.orgposted:

>About Math.random(), ECMA 262 just says "Returns a number value with
positive sign, greater than or equal to 0 but less than 1, chosen randomly
or pseudo randomly with approximately uniform distribution over that
range, using an implementation-dependent algorithm or strategy."

This is not good enough for my purposes (to generate identifiers with
sufficient entropy, say 256 bits or so, to effectively preclude any chance
of any two calls ever pricking the same), but it may be a starting point.

If you mean by 256 bits what I think you mean : ISO/IEC 16262 permits it
but does not require it. The chance of Math.random providing it (before
PCs have 256-bit integers) is IMHO negligible. It will not, likewise,
be crypto-grade.

>Does anyone have information about the Math.random() function in various
implementations?

IE6 & IE7 appear to have 53 or more bits of randomness; FF 2.0.0.3 52
bits; Opera 9.21 31 bits. But think about the method used to test that.

One browser is reliably reported to have given 1.0 about once per 30000
calls to Math.random(). That suggests a 15- or 16-bit implementation,
with a bug.

The important questions are probably : what speed of generation do you
need, and have you access to Knuth's books.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zipTimo Salmi's Turbo Pascal FAQ.

[Dr J R Stockton]

In comp.lang.javascript message <11*********************@57g2000hsv.goog
legroups.com>, Tue, 4 Sep 2007 07:15:09, Bart Van der Donck
<ba**@nijlen.composted:

>

>More generally, is there any reliable way of picking up good noise, except
by setting up a server and calling it, say, with XMLHTTRequest?

var unique_url = 'file.php?' + (new Date()).getTime();

Round here, the UTC time is strictly monotonic.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6.
Web <URL:http://www.merlyn.demon.co.uk/- w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/- see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

[Randy Webb]

Johannes Baagoe said the following on 9/4/2007 9:27 PM:

Dr J R Stockton :

>If you mean by 256 bits what I think you mean : ISO/IEC 16262 permits it
but does not require it.

If anybody Out There has had the same idea of attempting to provide unique
ids for absolutely anything that one might ever want to identify, I would
certainly join efforts rather than reinvent the wheel, but I am not aware
of anybody else being quite that crazy :-)

It happens every day with Bar Codes :)

The only way to ensure that an ID is not duplicated (in your scenario)
is to keep track of the ones assigned and not re-assign them.

>One browser is reliably reported to have given 1.0 about once per 30000
calls to Math.random(). That suggests a 15- or 16-bit implementation,
with a bug.

Ouch! Which browser is that? It would mean that there would be a fair
chance of duplicates with only a few hundred elements.

Opera 6 would return 1.0 occasionally.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Johannes Baagoe]

Randy Webb :

The only way to ensure that an ID is not duplicated (in your scenario)
is to keep track of the ones assigned and not re-assign them.

Of course, but that means a global repository somewhere, with someone to
maintain it, control it and possibly charge outrageous rates once people
get hooked on the scheme. Sufficiently large random numbers mean that
anybody can make her own with a quite negligible probability of anybody
else ever picking the same.

--
Johannes
"Quand on dit c'est un Johannes, cela vaut autant que ce que maintenant
on appelle un pédant" (H. Estienne, cité dans le Littré, art. PÉDANT)

[Randy Webb]

Johannes Baagoe said the following on 9/4/2007 10:01 PM:

Randy Webb :

>The only way to ensure that an ID is not duplicated (in your scenario)
is to keep track of the ones assigned and not re-assign them.

Of course, but that means a global repository somewhere, with someone to
maintain it, control it and possibly charge outrageous rates once people
get hooked on the scheme. Sufficiently large random numbers mean that
anybody can make her own with a quite negligible probability of anybody
else ever picking the same.

Simply generate a 16 digit number by picking 16 random numbers from 0-9
using Math.random() and be done with it. Don't make it any harder or
more difficult than it has to be :)

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Johannes Baagoe]

Randy Webb :

Simply generate a 16 digit number by picking 16 random numbers from 0-9
using Math.random() and be done with it.

Is there a good reason to believe that anybody who does that will always
come up with a different number from anybody else? Or nearly always, the
probability of exceptions being demonstrably so small that you would trust
a system which relies on your solution to operate, e.g., a nuclear plant?

My main contract just now is not quite as critical as that. However, it
concerns a hospital for children with quite severe diseases, and if,
say, a prescription goes to the wrong patient, someone could die.

Don't make it any harder or more difficult than it has to be

I quite agree that solutions should be as simple as possible to do the
job. But no simpler...

--
Johannes
"Quand on dit c'est un Johannes, cela vaut autant que ce que maintenant
on appelle un pédant" (H. Estienne, cité dans le Littré, art. PÉDANT)

[Randy Webb]

Johannes Baagoe said the following on 9/5/2007 12:14 AM:

Randy Webb :

>Simply generate a 16 digit number by picking 16 random numbers from 0-9
using Math.random() and be done with it.

Is there a good reason to believe that anybody who does that will always
come up with a different number from anybody else? Or nearly always, the
probability of exceptions being demonstrably so small that you would trust
a system which relies on your solution to operate, e.g., a nuclear plant?

My main contract just now is not quite as critical as that. However, it
concerns a hospital for children with quite severe diseases, and if,
say, a prescription goes to the wrong patient, someone could die.

If what you are doing is that critical, then you have to do it on the
server and remove any - and all - chance of the possibility of a
duplicate. To not do that introduces the off chance of a duplicate
accourring. For what you are doing you need a serial number(as I
suggested earlier). You could start with patient # 000001 and increment
it each time and have no need at all for a random number. Simply keep
track on the server of the last patient number and increment it.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Erwin Moller]

Johannes Baagoe wrote:

Randy Webb :

>Simply generate a 16 digit number by picking 16 random numbers from 0-9
using Math.random() and be done with it.

Is there a good reason to believe that anybody who does that will always
come up with a different number from anybody else? Or nearly always, the
probability of exceptions being demonstrably so small that you would trust
a system which relies on your solution to operate, e.g., a nuclear plant?

My main contract just now is not quite as critical as that. However, it
concerns a hospital for children with quite severe diseases, and if,
say, a prescription goes to the wrong patient, someone could die.

>Don't make it any harder or more difficult than it has to be

I quite agree that solutions should be as simple as possible to do the
job. But no simpler...

Hi Johannes,

I think that such a applications asks for one central database that is
responsible for giving (generating) unique ids.
Forget Math.random(), and just go serverside to 1 (big) database.
Why work with messy solutions if you can ensure a SERIAL field in the
database will garantuee you unique identifiers?
I expect you'll have to set up a database anyway if you want to keep
track of the prescriptions.

just my 2 cent...

Regards,
Erwin Moller

[Thomas 'PointedEars' Lahn]

T. Postel wrote:

http://en.wikipedia.org/wiki/Uuid
Available in many languages, JavaScript included, and even a mySQL
implementation.

Apart from the fact that they are not providing a class but a prototype,
as the client-side JS that they support has no classes.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Johannes Baagoe]

Randy Webb :

What the OP wants/needs is uniquely identifying numbers to identify
patients.

That is just a special case. What I want is UUIDs, preferably generated
client-side Javascript. Except that I did not know anything about UUIDs
before T. Postel provided a link, so I did not know that that was what I
wanted.

--
Johannes
"Quand on dit c'est un Johannes, cela vaut autant que ce que maintenant
on appelle un pédant" (H. Estienne, in É. Littré, /Dictionnaire de la
langue française/, art. PÉDANT)

[Dr J R Stockton]

In comp.lang.javascript message <0fOdnWo_n92zsEPbnZ2dnUVZ8sXinZ2d@gigane
ws.com>, Tue, 4 Sep 2007 23:14:38, Johannes Baagoe <ba****@baagoe.org>
posted:

>Randy Webb :

>Simply generate a 16 digit number by picking 16 random numbers from 0-9
using Math.random() and be done with it.

Is there a good reason to believe that anybody who does that will always
come up with a different number from anybody else? Or nearly always, the
probability of exceptions being demonstrably so small that you would trust
a system which relies on your solution to operate, e.g., a nuclear plant?

There is good reason to disbelieve it, at least in the case of those
using javascript browsers.

Since MS IE is so common, there's a fair chance that any given pair of
users are both using it, and therefore will traverse the same sequence
from wherever they start. We do not know how it is initialised, but
it's likely to be from the time-of-day or the time-since-boot. The
chances of one pair of the many(?) users getting, once, the same
initialisation are not IMHO negligible. But greater knowledge of the
internals may rule that out.
But here's a thought, not to be taken too seriously - ask the patient to
type in a unique 64-digit number. Ignore the choice of digits, but time
the intervals between them. Each interval, mod 4, should give 2 bits of
near-randomness.
Once Upon A Time, I was friendly with the staff of a computer centre. I
heard that they'd written a business game, to be played each day one
week and scheduled to start at 09:00. I remarked that there was a
chance, with the RNG seeded by the time, that the same random sequence
would be used each day, and seen to be so. While it was agreed that the
chances of that were small, their professionalism caused them to dash
off to exclude the possibility.

--
(c) John Stockton, Surrey, UK. *@merlyn.demon.co.uk / ??*********@physics.org
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SoRFC1036)

[Johannes Baagoe]

Randy Webb :

Makes me glad my hospital and doctors don't identify me by some randomly
generated number.

Well, it is actually a mandatory feature in hospital information systems
in France. The point is that the medical staff must not know whether the
patient is rich or poor, and the accounting staff must not know whether she
or he is going to survive. To sum it up in the most brutal terms.

--
Johannes
"Quand on dit c'est un Johannes, cela vaut autant que ce que maintenant
on appelle un pédant" (H. Estienne, in É. Littré, /Dictionnaire de la
langue française/, art. PÉDANT)

[Randy Webb]

Dr J R Stockton said the following on 9/5/2007 2:36 PM:

In comp.lang.javascript message <0fOdnWo_n92zsEPbnZ2dnUVZ8sXinZ2d@gigane
ws.com>, Tue, 4 Sep 2007 23:14:38, Johannes Baagoe <ba****@baagoe.org>
posted:

>Randy Webb :

>>Simply generate a 16 digit number by picking 16 random numbers from 0-9
using Math.random() and be done with it.

Is there a good reason to believe that anybody who does that will always
come up with a different number from anybody else? Or nearly always, the
probability of exceptions being demonstrably so small that you would trust
a system which relies on your solution to operate, e.g., a nuclear plant?

There is good reason to disbelieve it, at least in the case of those
using javascript browsers.

Since MS IE is so common, there's a fair chance that any given pair of
users are both using it, and therefore will traverse the same sequence
from wherever they start. We do not know how it is initialised, but
it's likely to be from the time-of-day or the time-since-boot. The
chances of one pair of the many(?) users getting, once, the same
initialisation are not IMHO negligible. But greater knowledge of the
internals may rule that out.

And that is precisely why I suggested using a sequential number series.

But here's a thought, not to be taken too seriously - ask the patient to
type in a unique 64-digit number. Ignore the choice of digits, but time
the intervals between them. Each interval, mod 4, should give 2 bits of
near-randomness.

Patient: My head is bleeding profusely.
Admin: Please come type a 64 digit number so I can admit you.

Once Upon A Time, I was friendly with the staff of a computer centre. I
heard that they'd written a business game, to be played each day one
week and scheduled to start at 09:00. I remarked that there was a
chance, with the RNG seeded by the time, that the same random sequence
would be used each day, and seen to be so. While it was agreed that the
chances of that were small, their professionalism caused them to dash
off to exclude the possibility.

Yet you still think a random number poses the best solution versus a
sequential number?

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Johannes Baagoe]

Randy Webb :

Yet you still think a random number poses the best solution versus a
sequential number?

It does. Among other things, sequential numbers are nowhere anonymous
enough. Forget them.

I cannot possibly post all the considerations that are behind my client's
project. The requirements fill hundreds of pages, with references to
thousands of more general pages of laws, regulations and the like. Please
take my word that anything that obvious as sequential numbers has been
duly considered literally years ago, and if it has not been adopted, there
are quite weighty reasons for that.

Or, more simply, the matter is not for you to decide... sorry. I ask
technical questions about Javascript on comp.lang.javascript because I am
no expert in that particular language, but please don't tell me how to do
the more general job in which I happen to be an expert. You would waste
your time as well as mine.

--
Johannes
"Quand on dit c'est un Johannes, cela vaut autant que ce que maintenant
on appelle un pédant" (H. Estienne, in É. Littré, /Dictionnaire de la
langue française/, art. PÉDANT)

[Randy Webb]

Johannes Baagoe said the following on 9/5/2007 8:50 PM:

Randy Webb :

>Yet you still think a random number poses the best solution versus a
sequential number?

It does. Among other things, sequential numbers are nowhere anonymous
enough. Forget them.

Gives me some fair insight into the thought process of the French.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Bart Van der Donck]

Johannes Baagoe wrote:

Randy Webb :

>Simply generate a 16 digit number by picking 16 random numbers from 0-9
using Math.random() and be done with it.

Is there a good reason to believe that anybody who does that will always
come up with a different number from anybody else? Or nearly always, the
probability of exceptions being demonstrably so small that you would trust
a system which relies on your solution to operate, e.g., a nuclear plant?

My main contract just now is not quite as critical as that. However, it
concerns a hospital for children with quite severe diseases, and if,
say, a prescription goes to the wrong patient, someone could die.

I'm aware of Belgian hospital software where vital data must be
entered twice by independent employees. Making sure not to cut off a
wrong leg or so :)

--
Bart

[Erwin Moller]

Johannes Baagoe wrote:

Randy Webb :

>Yet you still think a random number poses the best solution versus a
sequential number?

It does. Among other things, sequential numbers are nowhere anonymous
enough. Forget them.

I cannot possibly post all the considerations that are behind my client's
project. The requirements fill hundreds of pages, with references to
thousands of more general pages of laws, regulations and the like. Please
take my word that anything that obvious as sequential numbers has been
duly considered literally years ago, and if it has not been adopted, there
are quite weighty reasons for that.

Or, more simply, the matter is not for you to decide... sorry. I ask
technical questions about Javascript on comp.lang.javascript because I am
no expert in that particular language, but please don't tell me how to do
the more general job in which I happen to be an expert. You would waste
your time as well as mine.

Hi Johannes,

Maybe this nonsense, since I didn't read those hundred of pages of
course, BUT:

It is easy to have garantueed uniqueness and arbitrary long random
identifiers on the database.
If is a matter of creating a Primary Key on a table you use for
identifying some record.
You can make this PK as long as suits your needs, and as random as suits
your needs. Good thing is you are on the server, so you can use your
favorite randomgenerator without the hassle in javascript.

That sounds so much more logical and robust than letting Javascript do
this (appearantly important) job.

But then again, maybe I am missing something completely.
Just trying to help out. ;-)

Regards,
Erwin Moller

[Dr J R Stockton]

In comp.lang.javascript message <J9qdnZMKPoACbEPbnZ2dneKdnZydnZ2d@gigane
ws.com>, Wed, 5 Sep 2007 13:12:47, Johannes Baagoe <ba****@baagoe.org>
posted:

>
Cryptographic security, which is quite hard to attain let alone to prove,
is not necessarily an issue, AFAICT.

You may not need security against crypto attacks; but you do need
demonstrably good random numbers. Crypto-grade is the best;
javascript/Pascal grade is not, or not demonstrably, good enough; so it
seems worth going for crypto-grade, unless Knuth gives something
adequate in between.

<URL:http://www.merlyn.demon.co.uk/humorous.htm#Randmight amuse you.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Delphi 3? Turnpike 6.05
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htmclpdmFAQ;
<URL:http://www.borland.com/newsgroups/guide.htmlnews:borland.* Guidelines

[Dr J R Stockton]

In comp.lang.javascript message <jI********************@giganews.com>,
Wed, 5 Sep 2007 20:03:49, Randy Webb <Hi************@aol.composted:

>
Yet you still think a random number poses the best solution versus a
sequential number?

If the details, which we do not know in full, preclude a sequential
number, then a random number is undoubtedly best.

The OP is certainly asking, no doubt for good reason, for a non-
sequential solution; his reason might be as simple as having already a
full understanding of the sequential case.

Hospital numbers should certainly not be incremental - too great a
chance of staff relying on memory. And you might not like to be the
lowest number in a ward running short of bed-space. If they are
generated using a count, then that should be scrambled before issue.

It's probably easier to prove that duplication of long randoms has
negligible probability that it is to prove an equally negligible
probability of a sequential scheme being accidentally would back.

--
(c) John Stockton, Surrey, UK. ??*@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.

Food expiry ambiguities: <URL:http://www.merlyn.demon.co.uk/date2k-3.htm#Food>

[Dr J R Stockton]

In comp.lang.javascript message <JN*********************@giganews.com>,
Wed, 5 Sep 2007 21:33:25, Randy Webb <Hi************@aol.composted:

>Johannes Baagoe said the following on 9/5/2007 8:50 PM:

>Randy Webb :

>>Yet you still think a random number poses the best solution versus a
sequential number?

It does. Among other things, sequential numbers are nowhere
anonymous
enough. Forget them.

Gives me some fair insight into the thought process of the French.

Only into their general nature, which means realising that their refined
sublimity is beyond the comprehension of the average foreigner.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[Dr J R Stockton]

In comp.lang.javascript message <mr*********************@giganews.com>,
Wed, 5 Sep 2007 17:51:21, Randy Webb <Hi************@aol.composted:

>Dr J R Stockton wrote the following on 9/5/2007 7:41 AM:

>In comp.lang.javascript message <iN*********************@giganews.com>,
Tue, 4 Sep 2007 18:50:15, Randy Webb <Hi************@aol.composted:

>>Johannes Baagoe said the following on 9/4/2007 1:22 PM:
Erwin Moller:

Personally I WOULD go serverside if the 'quality' of the random
numbers
is important for your current task.
Yes, it does seem to be the only reliable way to go :-(

If all numbers are issued by a single server, the task is trivial,
as
numbers can be issued in sequence. ISTM clear that the OP needs
uniqueness in numbers issued by independent, non-communicating machines;
and AFAICS great randomness is the only possibility for that.

If you want to reply to Johannes you might try replying to his post,
not mine.

My main interest was in pointing out the errors in your thinking, so
that others should not be deceived.

>If you were one of the patients, would you want your life possibly
dependent on the possibility of a random number being generated twice?
I wouldn't.

The chances of your being killed by a small meteor are something like 1
in 10^9. Probably it's not a matter of much concern to you, in
comparison with your national chance of being murdered at 55*10^-6 per
annum. The chance of your personal 32-bit random number matching a
given other person's random number would be about 0.25 in 10^9; and in
this application the number of other persons is probably not much over
1000. So perhaps the total risk is comparable with the risk of a
commercial cross-country flight.

The OP was envisaging using 256 bits, which is about 2^224 times
better.

The *only* way to ensure that is to keep track of what numbers have
been generated. And the simplest way to do that is to sequentially
number patients.

When that solution is possible, it is obviously the best. Therefore
there's no need to suggest it to an intelligent OP.
Using sequential numbers rather than long random ones probably gives a
greater risk of error due to system fault or misuse; though in either
case that's the biggest risk.

... ... ... ...

Please read FAQ 2.3.

--
(c) John Stockton, Surrey, UK. *@merlyn.demon.co.uk / ??*********@physics.org
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Correct <= 4-line sig. separator as above, a line precisely "-- " (SoRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SoRFC1036)

[John G Harris]

On Wed, 5 Sep 2007 at 21:33:25, in comp.lang.javascript, Randy Webb
wrote:

>Johannes Baagoe said the following on 9/5/2007 8:50 PM:

>Randy Webb :

>>Yet you still think a random number poses the best solution versus a
sequential number?

It does. Among other things, sequential numbers are nowhere
anonymous
enough. Forget them.

Gives me some fair insight into the thought process of the French.

Be fair. Random patient IDs make it unlikely that a small typo will
produce a valid ID, and hence the wrong patient. It also makes hash
tables work more reliably.

John
--
John Harris

[John G Harris]

On Tue, 4 Sep 2007 at 23:14:38, in comp.lang.javascript, Johannes Baagoe
wrote:

<snip>

>My main contract just now is not quite as critical as that. However, it
concerns a hospital for children with quite severe diseases, and if,
say, a prescription goes to the wrong patient, someone could die.

<snip>

The idea of doing life critical calculations in javascript is
horrifying. Are you really going to re-certify the application every
time Microsoft issues an IE update?

John
--
John Harris

[Randy Webb]

John G Harris said the following on 9/6/2007 3:46 PM:

On Wed, 5 Sep 2007 at 21:33:25, in comp.lang.javascript, Randy Webb
wrote:

>Johannes Baagoe said the following on 9/5/2007 8:50 PM:

>>Randy Webb :

Yet you still think a random number poses the best solution versus a
sequential number?
It does. Among other things, sequential numbers are nowhere
anonymous
enough. Forget them.

Gives me some fair insight into the thought process of the French.

Be fair.

OK. I just find it odd that a society would think that random numbers,
that have a probability of repeating - no matter how small that chance -
is better than a system where the chance of repeating a number is
impossible.

Random patient IDs make it unlikely that a small typo will
produce a valid ID, and hence the wrong patient.

That is true. And a simple solution exists for that. If you want a 16
digit patient ID, you create a database with those ID'es. You shuffle
that database and then pick random entries from it. As you use an ID,
you remove it from the database.

Either way, it doesn't really matter as the OP has already discounted
that approach.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

Dr J R Stockton said the following on 9/6/2007 10:41 AM:

In comp.lang.javascript message <jI********************@giganews.com>,
Wed, 5 Sep 2007 20:03:49, Randy Webb <Hi************@aol.composted:

>Yet you still think a random number poses the best solution versus a
sequential number?

If the details, which we do not know in full, preclude a sequential
number, then a random number is undoubtedly best.

If you think that a random number - with the possibility of repeating -
is better than a system where the possibility of repeating is impossible
then you are welcome to continue to believe that.

The OP is certainly asking, no doubt for good reason, for a non-
sequential solution; his reason might be as simple as having already a
full understanding of the sequential case.

And it could be nothing more than wanting to make something more
difficult than it has to be.

Hospital numbers should certainly not be incremental - too great a
chance of staff relying on memory. And you might not like to be the
lowest number in a ward running short of bed-space. If they are
generated using a count, then that should be scrambled before issue.

It is trivial to remove the sequentiality of the numbers, you simple
Shuffle them. Then you remove ID'es as they are used. You now have no
problem with sequential numbers but you also have *zero* chance of
repeating an ID. That can not be said for random numbers no matter how
small the chance of repeating is, there is always that chance.

It's probably easier to prove that duplication of long randoms has
negligible probability that it is to prove an equally negligible
probability of a sequential scheme being accidentally would back.

YGCIB as that sentence doesn't make any sense.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

Dr J R Stockton said the following on 9/6/2007 11:27 AM:

In comp.lang.javascript message <JN*********************@giganews.com>,
Wed, 5 Sep 2007 21:33:25, Randy Webb <Hi************@aol.composted:

>Johannes Baagoe said the following on 9/5/2007 8:50 PM:

>>Randy Webb :

Yet you still think a random number poses the best solution versus a
sequential number?
It does. Among other things, sequential numbers are nowhere
anonymous
enough. Forget them.

Gives me some fair insight into the thought process of the French.

Only into their general nature, which means realising that their refined
sublimity is beyond the comprehension of the average foreigner.

YSCIB. If not understanding the idiocy of using a system that is flawed
from the outset is "beyond the comprehension..." then I would prefer not
to comprehend it.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

Dr J R Stockton said the following on 9/6/2007 10:45 AM:

In comp.lang.javascript message <mr*********************@giganews.com>,
Wed, 5 Sep 2007 17:51:21, Randy Webb <Hi************@aol.composted:

>Dr J R Stockton wrote the following on 9/5/2007 7:41 AM:

>>In comp.lang.javascript message <iN*********************@giganews.com>,
Tue, 4 Sep 2007 18:50:15, Randy Webb <Hi************@aol.composted:
Johannes Baagoe said the following on 9/4/2007 1:22 PM:
Erwin Moller:
>
>Personally I WOULD go serverside if the 'quality' of the random
>numbers
>is important for your current task.
Yes, it does seem to be the only reliable way to go :-(
If all numbers are issued by a single server, the task is trivial,
as
numbers can be issued in sequence. ISTM clear that the OP needs
uniqueness in numbers issued by independent, non-communicating machines;
and AFAICS great randomness is the only possibility for that.

If you want to reply to Johannes you might try replying to his post,
not mine.

My main interest was in pointing out the errors in your thinking, so
that others should not be deceived.

Then you do as anybody else with a little bit of thought would do and
reply to the post you wish to comment on.

>If you were one of the patients, would you want your life possibly
dependent on the possibility of a random number being generated twice?
I wouldn't.

The chances of your being killed by a small meteor are something like 1
in 10^9. Probably it's not a matter of much concern to you, in
comparison with your national chance of being murdered at 55*10^-6 per
annum. The chance of your personal 32-bit random number matching a
given other person's random number would be about 0.25 in 10^9; and in
this application the number of other persons is probably not much over
1000. So perhaps the total risk is comparable with the risk of a
commercial cross-country flight.

Compared to the zero chance of that ID being duplicated, it doesn't
matter how small that chance is, nor what you compare it to. A simple
truth remains that one system has a chance to repeat and one doesn't.
And no amount of useless tidbits of trivia will change that.

The OP was envisaging using 256 bits, which is about 2^224 times
better.

And still not as infallible as a system with zero chance of repeating.

>The *only* way to ensure that is to keep track of what numbers have
been generated. And the simplest way to do that is to sequentially
number patients.

When that solution is possible, it is obviously the best. Therefore
there's no need to suggest it to an intelligent OP.

Yet you continue to say that there is nothing wrong with a solution that
isn't as good. Wow.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Johannes Baagoe]

John G Harris :

Random patient IDs make it unlikely that a small typo will
produce a valid ID, and hence the wrong patient. It also makes hash
tables work more reliably.

Quite so. Among other things. There is a lot to be said for random IDs in
general, especially if one does not want to depend on a central repository
at all times. And if they are big enough, collisions will be much rarer
than any freak accident against which there is no remedy anyway.

--
Johannes
"Quand on dit c'est un Johannes, cela vaut autant que ce que maintenant
on appelle un pédant" (H. Estienne, in É. Littré, /Dictionnaire de la
langue française/, art. PÉDANT)

[Johannes Baagoe]

Bart Van der Donck :

I'm aware of Belgian hospital software where vital data must be entered
twice by independent employees.

Seems a sensible precaution to me, if the data is indeed vital.

Making sure not to cut off a wrong leg or so

It actually happens, I'm sorry to say. Hospitals are actually quite
dangerous places, with an unusually high concentration of all kinds of
risks. The sunny side is that treatment is also at hand to a greater
extent than about anywhere else.

--
Johannes
"Quand on dit c'est un Johannes, cela vaut autant que ce que maintenant
on appelle un pédant" (H. Estienne, in É. Littré, /Dictionnaire de la
langue française/, art. PÉDANT)

[Johannes Baagoe]

T. Postel :

http://en.wikipedia.org/wiki/Uuid
Available in many languages, JavaScript included,

But the proposed Javascript solution relies heavily on Math.random()...

--
Johannes
"Quand on dit c'est un Johannes, cela vaut autant que ce que maintenant
on appelle un pédant" (H. Estienne, in É. Littré, /Dictionnaire de la
langue française/, art. PÉDANT)

[Johannes Baagoe]

John G Harris :

The idea of doing life critical calculations in javascript is
horrifying.

Why ? AFAICT, ECMAScript is extremely well defined, and calculations in any
conforming implementation are carried out in accordance with IEEE 754,
which is about as predictable as one can get. Actually, one private
motivation to decide to trust javascript with serious tasks was the
delightful self-ironic pedantry of section 8.6 of ECMA 262 - I felt that I
could work with people who write like that.

Are you really going to re-certify the application every time Microsoft
issues an IE update?

I am not trusting IE with anything I cannot check, or indeed any other
Microsoft product, or more generally any software of which I cannot at
least in principle consult the sources and re-compile myself. In my
hospital project, all client workstations run Firefox 2.* on Ubuntu.

--
Johannes
"Quand on dit c'est un Johannes, cela vaut autant que ce que maintenant
on appelle un pédant" (H. Estienne, in É. Littré, /Dictionnaire de la
langue française/, art. PÉDANT)