Assuming one needs to have a function returning false or true on each

call in pseudo-random order.and using JavaScript native Math.random()

method as the basis of the pseudo-randomness. Say the variants of such

function are:

getAnswer1() {

var n = Math.round(Math.random());

return n ? true : false;

}

getAnswer2() {

var n = Math.floor(Math.random()*2);

return (n==2) ? true : false;

}

Leaving obvious practical testing by platforms aside:

Is there are theoretical considerations that pseudo-randomness

(predictability) of either of above will be better or worse than the

other one? JavaScript Kit site claims that the second bits first:

http://www.yqcomputer.com/

but they don't disclose the underlaying reasoning.

Why not { return Math.random() >= 0.5; } ?

Jorge.

I have no idea. The linked source at

http://www.yqcomputer.com/

claims this: "Some of you may be curious as to why Math.floor(),

instead of Math.round(), is used in the above code. While both

successfully round off its containing parameter to an integer within

the designated range, Math.floor does so more "evenly", so the

resulting integer isn't lopsided towards either end of the number

spectrum. In other words, a more random number is returned using

Math.floor()."

It may be some actual behavior or an author's fantasy - no arguments

are given on the page. From the Math.round and Math.floor methods

descriptions:

https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Objects/Math/Round

Returns the value of a number rounded to the nearest integer.

https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Objects/Math/Floor

Returns the largest integer less than or equal to a number.

I am failing to grasp the exact difference between of them. I only

assume that the only place of rounding inequality results could be in

"border cases" like 0.5xxxxxx etc. so with .5 being the first

fractional digit. Respectively if such inequality really exists then

there must be something with pseudo-random generation in whole or in

how it is implemented in Math.random() that would suggest 0.5xxxxx or

0.5 generation being lesser random than other results. Or it is just

another urban legend.

Another direction to look for is that the computer pseudo-random

generation operates in non-closed properly set [0,1[ with the upper

border not included so the result can be 0 but never 1. That shifts

the predictability pattern down toward 0. This is why actually why

Shannon's Clairvoyant can quickly tell for any sequence is it's truly

random or pseudo-random. btw Wiki's http://www.yqcomputer.com/

claim that "No efficient algorithm can distinguish (with significant

advantage) between a function chosen randomly from the PRF family" is

a complete b.s. but I am too lazy to argue with the entire ACM. Let

them believe what they want to believe.

So it might be that Math.floor somehow "re-balance" the outcome making

it lesser predictable. I just don't see how could it be. I am really

puzzled... Maybe I should get all JavaScript stuff out and post it as

a purely math question to sci.math

<snip>

<snip>

You leave practical testing aside far to often in your posted code. Any

reasonable testing (or your just understanding the methods/operations

employed) would observe that your proposed - getAnswer2 - function only

ever returns false. Thus, it fails to satisfy your "returning false or

true on each call in pseudo-random order".

Yes, but mostly because the obvious bugs in the second prevent it from

doing anything useful at all.

The subject of the comments on that page is the choice of the use of

Math.floor over Math.round (where Math.round is commonly used in example

javascript random number generators found on the Internet).

Math.random returns a (pseudo-random) number that is in the range zero

to less than one (i.e. anything non-negative that is smaller than one).

If you multiply that number by an integer you will get a result that is

in the range from zero to less than that number. If two were taken as an

example of such a number (i.e. - (Math.random * 2) - the result would be

a number in the range zero to less than two.

If you apply - Math.round - to all the numbers in the range zero to less

than two the range zero to <0.5 (a quarter of the total range) would

result in zero, between 0.5 and <1.5 (half the total range) would result

in one, and 1.5 to <2 would result in two. So, using Math.round, a

random number in the 0 to <2 range has a 25% chance of coming our zero,

a 50% chance of coming out one and a 25% chance of coming out 2. This is

not an even distribution. (Extending this to multiplying by any positive

integer; it is the values at the two extremes of output that end up

being half as likely in the output as any numbers in between, however if

that integer were one then there would be no numbers in between the

extremes of the range and so then the distribution between zero and one

would be equal.)

If you apply - Math.floor - to numbers in the range 0 to <2 then the

range 0 to <1 (half the original range) result in 0 and the range 1 to

<2 (the other half of the original range) result in 1; a 50/50

distribution.

Richard.

Given that there has been a prevalence of examples of javascript (so-

called) random number generators posted to the web that did use

Math.round and did then produce a non-even distribution of numbers in

their output, a fair number of readers of that article may well be

curious about its author's choice.

This bit isn't actually true as if you did a direct substitute of -

Math.round - for - Math.floor - then the range of the output would

increase by one.

"Lopsided" is probably inappropriate as well, as the output

distribution following a substitution of - Math.random - for -

Math.floor - is still symmetrical.

Most likely an overlay hurried explanation of a common fault in

javascript authoring, with a couple of mistakes getting in the way of

making the point.

Then you are the author of:-

<URL: http://www.yqcomputer.com/

- so we know the subtleties of rounding in javascript don't have to

get that subtle before you cannot comprehend them.

<snip>

Don't waste you time in assuming. The best you will do is invent an

elaborate fantasy explanation. Just wait for someone to tell you the

answer, and then avoid ever trying to put it into your own words.

Richard.

n May 1, 3:16m, "Richard Cornford" < XXXX@XXXXX.COM >

wrote:

Yeah... My mind was distracted a lot by the binary trees observations,

sorry.

Right. Similar answer from sci.math :

http://groups.google.com/group/sci.math/msg/5a878f7a0aea0b90

<quote>

Reply concerning this page, and not your description.

Let X be uniformly distributed in [0,1). Then floor(X*11) takes

values

0,1,...,10 each with probability 1/11 ... that is what the page means

by "even". However round(X*10) takes value 0 with probability 1/20,

values 1,...,9 each with probability 1/10 and value 10 with

probability

1/20. Not "even" according to the page.

</quote>

So the question is then

a) if it is possible to use Math.floor for a pseudo-random input to

get binary output (1/0, true/false)

b) if so than will it be more even probability for output than for

Math.round(Math.random()) or (Math.random >= 0.5)

.... or Math.floor(Math.random()*N) benefits appear only for ternary

and wider ranges "0 or 1 or 2", "0 or 1 or 2 or 3" etc. ?

wrote:

Yeah... My mind was distracted a lot by the binary trees observations,

sorry.

Right. Similar answer from sci.math :

http://groups.google.com/group/sci.math/msg/5a878f7a0aea0b90

<quote>

Reply concerning this page, and not your description.

Let X be uniformly distributed in [0,1). Then floor(X*11) takes

values

0,1,...,10 each with probability 1/11 ... that is what the page means

by "even". However round(X*10) takes value 0 with probability 1/20,

values 1,...,9 each with probability 1/10 and value 10 with

probability

1/20. Not "even" according to the page.

</quote>

So the question is then

a) if it is possible to use Math.floor for a pseudo-random input to

get binary output (1/0, true/false)

b) if so than will it be more even probability for output than for

Math.round(Math.random()) or (Math.random >= 0.5)

.... or Math.floor(Math.random()*N) benefits appear only for ternary

and wider ranges "0 or 1 or 2", "0 or 1 or 2 or 3" etc. ?

Not so. A probability theory outcome: see my answer to Richard

Cornford

First of all that was about IEEE-754 FP-DP rounding and calculation

vs. top level methods - not about the probability theory and how does

it apply to JavaScript Math methods. And yes, I couldn't grasp how

Math.floor would be more "even probability-friendly" than Math.round

until I got explanations of that. I don't see you grasping it on the

spot as your answer is silent about it. At least your first guess

quoted at the top was wrong.

The thousandth excuse for making the same mistake isn't any more

convincing than the second.

<snip>

<snip>

<snip>

Unsurprisingly.

Strange question; of course it is possible.

Properly implemented, there should be no difference. A bias towards the

numbers that are not at the ends of the range of output does not apply

when all of the possible outputs are at the ends of their range.

The issue only applies to rages with more than two values in them. But

still, Jorge's remains the better implementation for javascript (FPU

handled math operation over a method call), and it uses neither

Math.round nor Math.floor.

Richard.

On May 1, 4:02m, "Richard Cornford" < XXXX@XXXXX.COM >

Then would it be properly to state that in order to have the least

compromised pseudo-random sequence of integers from a set of two

elements one should use

return (Math.random() >= 0.5) ? _this : _that;

and for all sets with more than two elements one should use

return Math.floor( n * Math.random() );

where the range is [0, n-1]

Would it be appropriate to correct this in the FAQ

http://www.yqcomputer.com/ #randomNumber

and maybe add a short math explanation note based on the sci.math post

so not leaving reader to wonder why the hey floor() and what's wrong

with round() ?

Then would it be properly to state that in order to have the least

compromised pseudo-random sequence of integers from a set of two

elements one should use

return (Math.random() >= 0.5) ? _this : _that;

and for all sets with more than two elements one should use

return Math.floor( n * Math.random() );

where the range is [0, n-1]

Would it be appropriate to correct this in the FAQ

http://www.yqcomputer.com/ #randomNumber

and maybe add a short math explanation note based on the sci.math post

so not leaving reader to wonder why the hey floor() and what's wrong

with round() ?

VK < XXXX@XXXXX.COM > writes:

As stated elsewhere, this should read

return (n == 1) ? true : false;

or, preferably,

return n == 1;

No, they are (obviously?) exactly identical. They map exactly the same

results of Math.random() to true and false respectively.

In both cases, a value in the range [0..0.5[ is mapped to false

and a value in the range [0.5..1[ is mapped to true.

I guess their point is that to generate an integer in the range [0..n[,

Math.floor(Math.random() * n)

is better, in general, than

Math.round(Math.random() * (n - 1))

... which is pretty old news (not that people still don't bungle it

regularly, but it's embarrasing every time it happens).

The funny thing is that for n = 2, the unevenness of using the Math.round

doesn't matter, which is the case you are asking about.

--

Lasse Reichstein Holst Nielsen

'Javascript frameworks is a disruptive technology'

As stated elsewhere, this should read

return (n == 1) ? true : false;

or, preferably,

return n == 1;

No, they are (obviously?) exactly identical. They map exactly the same

results of Math.random() to true and false respectively.

In both cases, a value in the range [0..0.5[ is mapped to false

and a value in the range [0.5..1[ is mapped to true.

I guess their point is that to generate an integer in the range [0..n[,

Math.floor(Math.random() * n)

is better, in general, than

Math.round(Math.random() * (n - 1))

... which is pretty old news (not that people still don't bungle it

regularly, but it's embarrasing every time it happens).

The funny thing is that for n = 2, the unevenness of using the Math.round

doesn't matter, which is the case you are asking about.

--

Lasse Reichstein Holst Nielsen

'Javascript frameworks is a disruptive technology'

Lasse Reichstein Nielsen wrote on 01 mei 2010 in comp.lang.javascript:

or:

return !n-1;

--

Evertjan.

The Netherlands.

(Please change the x'es to dots in my emailaddress)

or:

return !n-1;

--

Evertjan.

The Netherlands.

(Please change the x'es to dots in my emailaddress)

> > eturn (n == 1) ? true : false; >>>> or, preferably, >>>> eturn n == 1;> >> > or:> >> > return !n-1;

return !n;

Jorge.

VK :

Of course not. It is quite difficult to define "random" and "pseudo-

random" in a precise and satisfactory way, but an essential part of

any reasonable definition is that there is no quick way to tell the

difference given the sequences. What you call "Shannon's Clairvoyant"

(I don't know it by that name from any other source than you) is a

rather clever illustration of the shortcomings of *humans* as sources

of random or pseudo-random sequences, nothing more. Computers are

much better, and easily defeat your "clairvoyant".

No, it is a sensible definition.

Perhaps some lingering remains of sanity, as well, like when you

chickened out of a bet you proposed yourself on the subject. Some

part of you may dimly realise that some people actually know more

about the subject than you.

Still, I am curious to see your implementation of "Shannon's

Clairvoyant" when you finish it, even if does not allow me to win

$10,000 against the loss of $10 according to the flip of a coin.

--

Johannes

Of course not. It is quite difficult to define "random" and "pseudo-

random" in a precise and satisfactory way, but an essential part of

any reasonable definition is that there is no quick way to tell the

difference given the sequences. What you call "Shannon's Clairvoyant"

(I don't know it by that name from any other source than you) is a

rather clever illustration of the shortcomings of *humans* as sources

of random or pseudo-random sequences, nothing more. Computers are

much better, and easily defeat your "clairvoyant".

No, it is a sensible definition.

Perhaps some lingering remains of sanity, as well, like when you

chickened out of a bet you proposed yourself on the subject. Some

part of you may dimly realise that some people actually know more

about the subject than you.

Still, I am curious to see your implementation of "Shannon's

Clairvoyant" when you finish it, even if does not allow me to win

$10,000 against the loss of $10 according to the flip of a coin.

--

Johannes

1. error with Math.round(Math.random..... code

2. Math::GMP tests and Crypt::Random fail on Compaq (Math::Pari related ??)

4. FA: 1-Day-Left: 6 Math Books - 4 Math CDROMs - Algebra, Discrete Math, Calculus, more...

5. Is there a way to have math that is not "display math" look like display math?

6. Is there a way to have math that is not "display math" look like ?display math?

7. Is there a way to have math that is not "display math" look like display math?

8. math problem will Math.floor help

9. pseudo random / Math.random()

10. Using Math.random to go to random frames

11. Math.round and just plain math

12. math.round and math.ceil etc. do not work in flash 8!

13. random without 0- math.round solution no good

14. matlab math to c++ math conversion

15. symbolic math toolbox 5.4 (matlab 2010a) is too slow compared to math toolbox 3.1