Prev: Emulating the <Tab> Key operation ?
Next: Online survey jobs & data entry jobs
From: VK on 1 May 2010 03:54
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.javascriptkit.com/javatutors/randomnum.shtml
but they don't disclose the underlaying reasoning.
From: Ry Nohryb on 1 May 2010 05:30
On May 1, 9:54 am, VK <schools_r...(a)yahoo.com> 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;
>
> }
>
> 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.javascriptkit.com/javatutors/randomnum.shtml
> but they don't disclose the underlaying reasoning.

Why not { return Math.random() >= 0.5; } ?
--
Jorge.
From: VK on 1 May 2010 05:49
On May 1, 1:30 pm, Ry Nohryb <jo...(a)jorgechamorro.com> wrote:
> On May 1, 9:54 am, VK <schools_r...(a)yahoo.com> 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;
>
> > }
>
> > 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.javascriptkit.com/javatutors/randomnum.shtml
> > but they don't disclose the underlaying reasoning.
>
> 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(), 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.

From: VK on 1 May 2010 06:20
On May 1, 1:49 pm, VK <schools_r...(a)yahoo.com> wrote:
>  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. 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://en.wikipedia.org/wiki/Pseudorandom_function_family
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

From: VK on 1 May 2010 06:50
On May 1, 2:20 pm, VK <schools_r...(a)yahoo.com> wrote:
> 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

Posted at sci.math as a mathematical problem:
http://groups.google.com/group/sci.math/browse_frm/thread/5846c8a74170acfd
 |  Next  |  Last
Pages: 1 2 3 4
Prev: Emulating the <Tab> Key operation ?
Next: Online survey jobs & data entry jobs