Prev: Emulating the <Tab> Key operation ?
Next: Online survey jobs & data entry jobs
From: Richard Cornford on 1 May 2010 07:16
VK" wrote:
> Assuming one needs to have a function returning false or true
> on each call in pseudo-random order. ...
<snip>
> 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:
<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".

> Is there are theoretical considerations that pseudo-randomness
> (predictability) of either of above will be better or worse than
> the other one?

Yes, but mostly because the obvious bugs in the second prevent it from
doing anything useful at all.

> JavaScript Kit site claims that the second bits first:
> http://www.javascriptkit.com/javatutors/randomnum.shtml
> but they don't disclose the underlaying reasoning.

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.

From: Henry on 1 May 2010 07:37
VK wrote:
>On May 1, 1:30 pm, Ry Nohryb wrote:
>> On May 1, 9:54 am, VK wrote:
>>> 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;
><snip>
>> Why not { return Math.random() >= 0.5; } ?
>
> I have no idea. The linked source at
> http://www.javascriptkit.com/javatutors/randomnum.shtml
> claims this: "Some of you may be curious as to why Math.floor(),
> instead of Math.round(),

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.

> is used in the above code. While both successfully round off
> its containing parameter to an integer within the designated
> range,

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.

> Math.floor does so more "evenly", so the resulting integer
> isn't lopsided towards either end of the number spectrum.

"Lopsided" is probably inappropriate as well, as the output
distribution following a substitution of - Math.random - for -
Math.floor - is still symmetrical.

> In other words, a more random number is returned using
> Math.floor()."
>
> It may be some actual behavior or an author's fantasy

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.

> - 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.

Then you are the author of:-

<URL: http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/b495b4898808fde0/63c2ad2bdbdf0b40
>

- so we know the subtleties of rounding in javascript don't have to
get that subtle before you cannot comprehend them.

> I only assume ...
<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.
From: VK on 1 May 2010 07:38
On May 1, 3:16 pm, "Richard Cornford" <Rich...(a)litotes.demon.co.uk>
wrote:
> 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".

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

> > Is there are theoretical considerations that pseudo-randomness
> > (predictability) of either of above will be better or worse than
> > the other one?
>
> Yes, but mostly because the obvious bugs in the second prevent it from
> doing anything useful at all.
>
> > JavaScript Kit site claims that the second bits first:
> >http://www.javascriptkit.com/javatutors/randomnum.shtml
> > but they don't disclose the underlaying reasoning.
>
> 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.

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. ?
From: VK on 1 May 2010 07:54
On May 1, 3:37 pm, Henry <rcornf...(a)raindrop.co.uk> wrote:
> > It may be some actual behavior or an author's fantasy
>
> 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.

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

> >https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Object...
> > Returns the value of a number rounded to the nearest integer.
>
> >https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Object...
> > Returns the largest integer less than or equal to a number.
>
> > I am failing to grasp the exact difference between of them.
>
> Then you are the author of:-
>
> <URL:http://groups.google.com/group/comp.lang.javascript/browse_frm/thread...
>
>
>
> - so we know the subtleties of rounding in javascript don't have to
> get that subtle before you cannot comprehend them.

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.
From: Richard Cornford on 1 May 2010 08:02
VK wrote:
>On May 1, 3:16 pm, Richard Cornford wrote:
>> 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".
>
> Yeah... My mind was distracted a lot by the binary trees
> observations, sorry.

The thousandth excuse for making the same mistake isn't any more
convincing than the second.

<snip>
>> ... , 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.)
<snip>
>Right. Similar answer from sci.math :
> http://groups.google.com/group/sci.math/msg/5a878f7a0aea0b90
<snip>

Unsurprisingly.

> 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)

Strange question; of course it is possible.

> b) if so than will it be more even probability for output than for
> Math.round(Math.random()) or (Math.random >= 0.5)

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.

>... 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. ?

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.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Emulating the <Tab> Key operation ?
Next: Online survey jobs & data entry jobs