even random number, javascript

[Debbie Lucier]

How would I generate a even random number each time? I can generate a
random number each time but not an even one? Here is the code I use for
the random number from 1-100.

<script type="text/javascript">
no=math.random()*100
document.write (math.round(no))
</script>
Thanks,
Deb

*** Sent via Developersdex http://www.developersdex.com ***

[rf]

Debbie Lucier

How would I generate a even random number each time? I can generate a
random number each time but not an even one? Here is the code I use for
the random number from 1-100.

Er, generate a random one from 1-50 and multiply it by 2.

Cheers
Richard.

[RobG]

Debbie Lucier wrote:

How would I generate a even random number each time? I can generate a
random number each time but not an even one? Here is the code I use for
the random number from 1-100.

<script type="text/javascript">
no=math.random()*100
document.write (math.round(no))
</script>

rf's answer should do the trick, but what about zero? Should it be
included, or is your range 2-100?
--
Rob

[Zif]

Debbie Lucier wrote:

How would I generate a even random number each time? I can generate a
random number each time but not an even one? Here is the code I use for
the random number from 1-100.

<script type="text/javascript">
no=math.random()*100
document.write (math.round(no))
</script>
Thanks,
Deb

*** Sent via Developersdex http://www.developersdex.com ***

Math.round() has a bias toward the higher numbers (4.5 goes to 5
always and never to 4), so the starting number has a lower chance of
occurring that all the others.

A better distribution is from truncating the decimal part of numbers
in a range between min and max plus one :
<script type="text/javascript">

function genRandom( min, max ) {
return min + (max-min+1)*Math.random() | 0;
}

document.write( genRandom( 0, 50 )*2 );

</script>

--
Zif

[Evertjan.]

Zif wrote on 30 aug 2005 in comp.lang.javascript:

Math.round() has a bias toward the higher numbers (4.5 goes to 5
always and never to 4),
Unimportant bias, because the chance of a pseudo random number being
exactly 4.5 should be very very small.

Other deviances between real random and pseudo random will have a much
higher effect, though also unimportant in most script applications.
so the starting number has a lower chance of
occurring that all the others.

what do you mean by "starting number"?

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

[Stephen Chalmers]

Debbie Lucier <no****@glorybound.net> wrote in message news:Qi*****************@news.uswest.net...

How would I generate a even random number each time? I can generate a
random number each time but not an even one? Here is the code I use for
the random number from 1-100.

<script type="text/javascript">
no=math.random()*100
document.write (math.round(no))
</script>

n = (Math.random()*98 +2) & 0xFE ; // 2 - 98 inclusive

n = (Math.random()*100 +2) & 0xFE ; // 2 - 100 inclusive

n = (Math.random()*100) & 0xFE ; // 0 - 98 inclusive

n = (Math.random()*101) & 0xFE ; // 0 - 100 inclusive

--
S.C.

[Lasse Reichstein Nielsen]

Zif <Zi***@hotmail.com> writes:

Debbie Lucier wrote:

no=math.random()*100
document.write (math.round(no))

Math.round() has a bias toward the higher numbers (4.5 goes to 5
always and never to 4), so the starting number has a lower chance of
occurring that all the others.

That's not the problem with using Math.round and Math.random together.
Since the range [3.5-4.5[ has the same length as [2.5-3.5[, the chance
of hitting either is close to the same.

A more serious problem is that Math.round(Math.random()*100) has 101
different possible outcomes, with 0 and 100 having only half the
chance of the others.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Evertjan.]

Lasse Reichstein Nielsen wrote on 30 aug 2005 in comp.lang.javascript:

A more serious problem is that Math.round(Math.random()*100) has 101
different possible outcomes, with 0 and 100 having only half the
chance of the others.

You are so right, Lasse.

Let's try:

Math.floor(Math.random()*100)

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

[Richard Cornford]

Evertjan. wrote:

Lasse Reichstein Nielsen wrote:

A more serious problem is that Math.round(Math.random()*100)
has 101 different possible outcomes, with 0 and 100 having
only half the chance of the others.

You are so right, Lasse.

Let's try:

Math.floor(Math.random()*100)

While we are at it, this seems like a good opportunity to use the
truncating side-effect of bitwise operations as the OP wants only even
numbers. Multiplying by two produces even numbers, but so does shifting
left by one bit:-

((Math.random() * 51) << 1) // even integers 0 to 100 (assuming
// a correct random implementation
// with results 0 to <1)

Richard.

[Evertjan.]

Richard Cornford wrote on 31 aug 2005 in comp.lang.javascript:

While we are at it, this seems like a good opportunity to use the
truncating side-effect of bitwise operations as the OP wants only even
numbers. Multiplying by two produces even numbers, but so does shifting
left by one bit:-

((Math.random() * 51) << 1) // even integers 0 to 100 (assuming
// a correct random implementation
// with results 0 to <1)

x = 1.234
alert(x) // 1.234
x = x << 1
alert(x) // 2

Why is the truncation as it is?

x = 0.234
alert(x) // 0.234
x = x << 1
alert(x) // 0 !!!!

Wrong, in the sense of your application!

btw:

x = -1.234
alert(x) // -1.234
x = x << 1
alert(x) // -2

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

[Evertjan.]

Evertjan. wrote on 31 aug 2005 in comp.lang.javascript:

x = 0.234
alert(x) // 0.234
x = x << 1
alert(x) // 0 !!!!

Wrong, in the sense of your application!

I seem not to be awake yet.

It is correct as it should be!

--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

[Richard Cornford]

Evertjan. wrote:

Richard Cornford wrote:

While we are at it, this seems like a good opportunity to use
the truncating side-effect of bitwise operations as the OP wants
only even numbers. Multiplying by two produces even numbers,
but so does shifting left by one bit:-

((Math.random() * 51) << 1) // even integers 0 to 100 (assuming
// a correct random implementation
// with results 0 to <1)

x = 1.234
alert(x) // 1.234
x = x << 1
alert(x) // 2

Why is the truncation as it is?

The floating point number is internally converted into a signed 32 bit
integer prior to the actual shift (this happens with all bitwise
operations except - >>> -, which uses an unsigned 32 bit integer). It is
this conversion that has the truncating (towards zero) side-effect, so
the operand for the actual shift is the number one.

Richard.

[Evertjan.]

Richard Cornford wrote on 31 aug 2005 in comp.lang.javascript:

x = 1.234
alert(x) // 1.234
x = x << 1
alert(x) // 2

Why is the truncation as it is?

The floating point number is internally converted into a signed 32 bit
integer prior to the actual shift (this happens with all bitwise
operations except - >>> -, which uses an unsigned 32 bit integer). It is
this conversion that has the truncating (towards zero) side-effect, so
the operand for the actual shift is the number one.

So this is a legal Math.floor equivalent for positive numbers?

x = x << 0

=========

different when negative:

x = -71.234
x = x << 0
alert(x) // -71
x = -71.234
x = Math.floor(x)
alert(x) // -72
--
Evertjan.
The Netherlands.
(Replace all crosses with dots in my emailaddress)

[Richard Cornford]

Evertjan. wrote:

Richard Cornford wrote:

x = 1.234
alert(x) // 1.234
x = x << 1
alert(x) // 2

Why is the truncation as it is?
The floating point number is internally converted into a signed 32
bit integer prior to the actual shift (this happens with all bitwise
operations except - >>> -, which uses an unsigned 32 bit integer).
It is this conversion that has the truncating (towards zero)
side-effect, so the operand for the actual shift is the number one.

So this is a legal Math.floor equivalent for positive numbers?

If the positive number can be accommodated in a 32 bit signed integer.
x = x << 0
or:-

x = x | 0;

- or any other bitwise operation that will not alter its operand. Though
OR zero and shift zero have proved the (approximately equal) fastest of
the possibilities (at between 4 and 14 times faster than Math.floor).
=========

different when negative:

x = -71.234
x = x << 0
alert(x) // -71
x = -71.234
x = Math.floor(x)
alert(x) // -72

Yes, the truncating is always towards zero with bitwise operators. But
they are still a good option when you want to quickly acquire integer
values that will be non-negative and restricted in range, such as for
pixel positioning in animation.

Richard.

[Dr John Stockton]

JRS: In article <df*******************@news.demon.co.uk>, dated Wed, 31
Aug 2005 11:39:54, seen in news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted :

The floating point number is internally converted into a signed 32 bit
integer prior to the actual shift (this happens with all bitwise
operations except - >>> -, which uses an unsigned 32 bit integer). It is
this conversion that has the truncating (towards zero) side-effect, so
the operand for the actual shift is the number one.

The result of X << Y (etc.) where Y is not a small non-negative integer
look interesting, but one should check that actual results and ECMA
agree (for which it is too late tonight) before contemplating actual
use.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.