Discussion forum > Suggestions
Fix the Lottery
optical:
I hate to crush such a long winded post, but tiggy is completely wrong. Thats not how things work in computers - its stored in binary - not base 10.
See: http://en.wikipedia.org/wiki/Floating_point#Floating-point_arithmetic_operations
It's complicated stuff, don't worry too much about it.
The numbers are generated using a linear congruential generator - java.Random. For this type of number generation it is adequate. see http://en.wikipedia.org/wiki/Linear_congruential_generator
http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Random.html#nextInt(int)
DeeKay:
--- Quote from: optical on July 22, 2012, 01:38:43 pm ---I hate to crush such a long winded post, but tiggy is completely wrong. Thats not how things work in computers - its stored in binary - not base 10.
See: http://en.wikipedia.org/wiki/Floating_point#Floating-point_arithmetic_operations
It's complicated stuff, don't worry too much about it.
The numbers are generated using a linear congruential generator - java.Random. For this type of number generation it is adequate. see http://en.wikipedia.org/wiki/Linear_congruential_generator
http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Random.html#nextInt(int)
--- End quote ---
Indeed, I was about to say that.
tiggy26668:
--- Quote from: optical on July 22, 2012, 01:38:43 pm ---I hate to crush such a long winded post, but tiggy is completely wrong. Thats not how things work in computers - its stored in binary - not base 10.
See: http://en.wikipedia.org/wiki/Floating_point#Floating-point_arithmetic_operations
It's complicated stuff, don't worry too much about it.
The numbers are generated using a linear congruential generator - java.Random. For this type of number generation it is adequate. see http://en.wikipedia.org/wiki/Linear_congruential_generator
http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Random.html#nextInt(int)
--- End quote ---
Opti... it really goes against my better judgement to argue with you... and since i don't know the algorithm being used to generate the random numbers i can't actually disprove its reliability mathematically. However i can confidently say that i was not wrong in my earlier post, this algorithm "int randomNumber = (int)(Math.random()*(tickets.count()-1));" was rigged, and while i explained it in base 10, the principles of math don't actually change and it would've been much more confusing to try and explain it in base 2, because to do the math in base 2 would mean an even longer winded post that dives into the explanations of why a computer can't represent repeating decimals in 64bits regardless of how they're generated
and that, given the algorithm i was addressing at the time, would mean constricting the ability of the ranges (ie:0.0, .1111) to truncate to a ticket index even further as decimals such as .11111-> can't be represented accurately. this in turn gives an unfair advantage to certain ranges as repeating decimals were not created equally and can appear in different concentrations for different ranges.
However that algorithm isn't necessarily the one being used, unless of course you would like to say otherwise.
Unfortunately given the documentation you were so kind as to post one can only assuming you're using a floating point decimal to create random numbers, and of course java's lovely math.random class to generate said floating point decimal
Now, if you would be so kind as to go back to the documentation you linked and scroll down the page slightly.... you'd see what i was talking about...
http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
furthermore the link to java's random class doesn't really prove anything.... as we can only assume you're using floating point numbers and there's really no explanation of how they work there.... however if we were to go to the documentation on java's math class (the class from which random inherits) http://docs.oracle.com/javase/6/docs/api/java/lang/Math.html
you would be be aware of this
(click to show/hide)The quality of implementation specifications concern two properties, accuracy of the returned result and monotonicity of the method. Accuracy of the floating-point Math methods is measured in terms of ulps, units in the last place. For a given floating-point format, an ulp of a specific real number value is the distance between the two floating-point values bracketing that numerical value. When discussing the accuracy of a method as a whole rather than at a specific argument, the number of ulps cited is for the worst-case error at any argument. If a method always has an error less than 0.5 ulps, the method always returns the floating-point number nearest the exact result; such a method is correctly rounded. A correctly rounded method is generally the best a floating-point approximation can be; however, it is impractical for many floating-point methods to be correctly rounded. Instead, for the Math class, a larger error bound of 1 or 2 ulps is allowed for certain methods. Informally, with a 1 ulp error bound, when the exact result is a representable number, the exact result should be returned as the computed result; otherwise, either of the two floating-point values which bracket the exact result may be returned. For exact results large in magnitude, one of the endpoints of the bracket may be infinite. Besides accuracy at individual arguments, maintaining proper relations between the method at different arguments is also important. Therefore, most methods with more than 0.5 ulp errors are required to be semi-monotonic: whenever the mathematical function is non-decreasing, so is the floating-point approximation, likewise, whenever the mathematical function is non-increasing, so is the floating-point approximation. Not all approximations that have 1 ulp accuracy will automatically meet the monotonicity requirements.
which basically states that when a number doesn't fit in the amount of space provided (64bits) it rounds up or down
Furthermore, you've stated you're using a linear congruential generator, which leaving this little tidbit aside
(click to show/hide)http://en.wikipedia.org/wiki/Linear_congruential_generator
"LCGs should not be used for applications where high-quality randomness is critical."
think about this, java is capable of generating 2^48 possible random floating point numbers - http://en.wikipedia.org/wiki/Linear_congruential_generator
"As shown above, LCG's do not always use all of the bits in the values they produce. The Java implementation produces 48 bits with each iteration but only returns the 32 most significant bits from these values. This is because the higher-order bits have longer periods than the lower order bits" - http://en.wikipedia.org/wiki/Linear_congruential_generator
however in actual practice java creates only 2^24 possible random float values - http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Random.html#nextFloat()
this is in direct correlation with the fact that some numbers can't be represented in 64bit binary such as .111->, .222->,
.525252525252->
what this all boils down to is the misrepresentation of decimals in base 2, which leads to erroneous calculations and inaccurate results, on the surface it seems insignificant, but when u do out the math u realize probability wise some numbers have an unfair advantage while others don't show up at all, and that equates to tickets that can never be drawn and ones that don't have the correct chance to be drawn. That in fact would be the definition of rigged.
Sincerely,
Tiggy
P.S. opti, i don't mean to question your intelligence, clearly you're capable to have made it this far, however i really like randomness, and you questioned mine.
☣2crzy4uall☣:
--- Quote from: optical on July 22, 2012, 01:38:43 pm ---For this type of number generation it is adequate.
--- End quote ---
Really this is where it should end, its an in game lottery for fake money, we don't need a top notch number generator.
Edit: Great minds Viper. lol
ViperZeroOne:
--- Quote from: optical on July 22, 2012, 01:38:43 pm ---For this type of number generation it is adequate.
--- End quote ---
I think this is the statement that Tiggy missed here... For the purposes of THIS lottery you don't have to be random down to the 50th decimal point, it's not that critical, and EVERY number has an equal chance to be selected.
If you don't think it's random enough, don't use it. Plain and simple.
EDIT: Ninja'd by 2crzy4uall... *LOL*
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version