459,654 Members | 1,599 Online Need help? Post your question and get tips & solutions from a community of 459,654 IT Pros & Developers. It's quick & easy.

# even random number, javascript

 P: n/a 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. Thanks, Deb *** Sent via Developersdex http://www.developersdex.com *** Aug 30 '05 #1
14 Replies

 P: n/a 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. Aug 30 '05 #2

 P: n/a 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. rf's answer should do the trick, but what about zero? Should it be included, or is your range 2-100? -- Rob Aug 30 '05 #3

 P: n/a 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. 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 : -- Zif Aug 30 '05 #4

 P: n/a 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) Aug 30 '05 #5

 P: n/a Debbie Lucier 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. 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. Aug 30 '05 #6

 P: n/a Zif 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: 'Faith without judgement merely degrades the spirit divine.' Aug 30 '05 #7

 P: n/a 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) Aug 30 '05 #8

 P: n/a 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. Aug 31 '05 #9

 P: n/a 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) Aug 31 '05 #10

 P: n/a 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) Aug 31 '05 #11

 P: n/a 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. Aug 31 '05 #12

 P: n/a 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) Aug 31 '05 #13

 P: n/a 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. Aug 31 '05 #14

 P: n/a JRS: In article , dated Wed, 31 Aug 2005 11:39:54, seen in news:comp.lang.javascript, Richard Cornford posted :The floating point number is internally converted into a signed 32 bitinteger prior to the actual shift (this happens with all bitwiseoperations except - >>> -, which uses an unsigned 32 bit integer). It isthis conversion that has the truncating (towards zero) side-effect, sothe 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 © JL/RC: FAQ of news:comp.lang.javascript jscr maths, dates, sources. TP/BP/Delphi/jscr/&c, FAQ items, links. Aug 31 '05 #15

### This discussion thread is closed

Replies have been disabled for this discussion. 