Opticraft Community

Quote//create a completely random number
        int randomNumber = (int)(Math.random()*(tickets.count()-1));

hate to break it to you chief but that isn't random....

i wont even begin to address the complete loss of precision going on here due to using decimal values....

that whole argument aside think about the concept of multiplying a decimal between 0.0 and 1.0 inclusive times a positive integer.

first argument,
lets say we have 10^1 tickets in the lottery (never gonna happen), if the random decimal is anything equal to/smaller than .111->, (0.0, .111...) then 9*.(0.0-.111...) = 0.something, truncates to = 0
it follows (.111...2, .22...)*9 = 1.something, truncates to 1...etc all the way to (.88...9, .99....)*9 = 8.something, truncates to 8 leaving only 1.0 as the sole possible random number for the person who bought the last ticket to win, whereas the previous 9 tickets all had a seemingly equal chance to be drawn.

this thought process can be applied to larger amounts of tickets, simply move the decimal 1 place to the left for each power of 10

10^4 or 10,000 tickets
9,999*(0.0, .00011..) = 0.something
9,999*(.0001...2, .00022...) = 1.something, truncates to 1
.... etc
9,999*(.00088.....9, .00099...) = 8.something, truncates to 8
9,999*(.001...) = 9 *note only a single way to truncate to 9*

the difference in this situation is the problem repeats for every tenth ticket.

9,999*(.00188...9, .001999...) = 18.something, truncates to 18
9,999*(.002...) = 19.something, truncates to 19 *note only a single way to truncate to 19*
9,999*(.002...3) = (according to windows calc) 22.997 (WTF HAPPEND TO 20-21?!?!?!?!?!?!)

this pattern continues throughout the sequence effectively screwing over every tenth ticket as well as many others.

now if that argument isn't enough of a reason to rethink that way of generating a random number lets take into account a brief example of the "loss of precision" i wanted to avoid discussing.

lets take a simple expression, we have 10,000 tickets in the lottery and the random double is .001111,

do it on paper, 9,999*(.0001111) = .9999, truncates to 0 (perfect)

now plug it into your calculator that come standard with any windows machine

9,999*(.0001111) = 1.110889, truncates to 1 (WTF RAGE LOTTERY IS RIGGED OMFG!)

this isn't a specific situation, it reappears at specific intervals depending on the amount of bits used to store the double variable because in computer world when a decimal doesn't fit in 8 bits, the computer picks the closest number that does.

Now, with my long lecture said and done, i really hate criticizing without contributing....

in an effort to prevent problems such as these from occurring i would suggest using a random integer for your random index generation, then manipulate that number into a usable index because integer values are less prone to loss of precision, or more simply just use the nextint function and bypass it all together.

also i would suggest shuffling the list of names/tickets so that you don't end up with giant chunks of names taking advantage of the better ranges to be in, it would be an overall better mix-up/randomization as both the tickets and the index of winning tickets have been randomized

sincerely,
Tiggy

*Breathes*

Tiggy is right.
But for everyone who did not under stand that i will simplify.  Heres a scenario.  Xeadin purchases 4 tickets.  BigBadHenz purchases 3.  Nick Purchases 2 tickets. And i purchase 1.  So there are a total of 1o tickets.  each ticket is one-tenth of the total pot.  so each ticket has a ten percent chance of being chosen.  So there is a 40% chance that Xeadin will win. and a 60% chance that he wont.  So if we were to draw a ticket and put it back.  and repeat this ten times Xeadin would win 4 times while someone else would win the other 6 times.  This is according to probability. 

Now A new drawing situation.  Lets say we draw three times and each tim the ticket is removed.

wtf i wrote like a whole page and it didnt post it was beast

Alright im going to finish my post now.  So Xeadin has 8 tickets i have 1 and Henz has 1.  First draw Xeadin has an 80% chance of winning.  So When the computer draws Xeadin Will win.  The next Draw there are only nine tickets and Xeadin has 7 of them.  The Chance that xeadin will win is 77.7777777777777777777777777777777777777777777%  So When the computer picks one xeadin will win again. and now for the third draw Xeadin will have a 75% chance of winning. So when the Computer draws Xeadin will win again.  Now Xeadin has won all three picks.  This is because the loto is based on probability and stats.  If it was random it may be different.  But because a computer is based on satats and probability it does not draw randomely.  But this does not mean it is rigged.  So yes the loto is not random but it is not rigged.  so i hope that satisfies both sides.

Hell ya science:)

Quote from: caseyboy123 on July 22, 2012, 01:36:19 AM
Alright im going to finish my post now.  So Xeadin has 8 tickets i have 1 and Henz has 1.  First draw Xeadin has an 80% chance of winning.  So When the computer draws Xeadin Will win.  The next Draw there are only nine tickets and Xeadin has 7 of them.  The Chance that xeadin will win is 77.7777777777777777777777777777777777777777777%  So When the computer picks one xeadin will win again. and now for the third draw Xeadin will have a 75% chance of winning. So when the Computer draws Xeadin will win again.  Now Xeadin has won all three picks.  This is because the loto is based on probability and stats.  If it was random it may be different.  But because a computer is based on satats and probability it does not draw randomely.  But this does not mean it is rigged.  So yes the loto is not random but it is not rigged.  so i hope that satisfies both sides.

Hell ya science:)

well caseyboy, the point i was trying to get at was given that algorithm some numbers actually had a lower probability to be drawn and others were being skipped completely, that means some tickets could never be drawn and others have a lower chance regardless of the amount the person bought

*edit* that means it's rigged.....

Ok, let's set aside the algorithmic discussion for a minute because that's so WAY off from effecting the outcome of the lotto draw that it's not even worth mentioning.  It IS random, and it IS fair, because each consecutive draw doesn't include the winning ticket from the last draw, and a whole new random draw is done.  Plain and simple.

So, those of you who aren't winning, just suck it up and make the odds better in your favor.  Either find a four leaf clover, hang a horseshoe, or do something that'll improve your luck cause the odds of winning are only as good as the number of tickets you buy.

...and if you want to talk about algorithmic randomizations, even Turing had a way to randomize the algorithm that selects the random number for it's random selections, which made it's random selections 100% random.  Do you honestly think Opti wouldn't make the draws random in the same method?

Come on people, get real.

Quote from: ViperZeroOne on July 22, 2012, 01:52:34 AM
Ok, let's set aside the algorithmic discussion for a minute because that's so WAY off from effecting the outcome of the lotto draw that it's not even worth mentioning.  It IS random, and it IS fair, because each consecutive draw doesn't include the winning ticket from the last draw, and a whole new random draw is done.  Plain and simple.

So, those of you who aren't winning, just suck it up and make the odds better in your favor.  Either find a four leaf clover, hang a horseshoe, or do something that'll improve your luck cause the odds of winning are only as good as the number of tickets you buy.

viper it effects the outcome big time if that's the algorithm being used..... it means that you would be paying for a ticket that has a 0% chance to be drawn.... not a .00000001% chance, a 0% chance. it's tossing your money in the trash for false hope.

Quote from: tiggy26668 on July 22, 2012, 01:55:50 AM

Quote from: ViperZeroOne on July 22, 2012, 01:52:34 AM
Ok, let's set aside the algorithmic discussion for a minute because that's so WAY off from effecting the outcome of the lotto draw that it's not even worth mentioning.  It IS random, and it IS fair, because each consecutive draw doesn't include the winning ticket from the last draw, and a whole new random draw is done.  Plain and simple.

So, those of you who aren't winning, just suck it up and make the odds better in your favor.  Either find a four leaf clover, hang a horseshoe, or do something that'll improve your luck cause the odds of winning are only as good as the number of tickets you buy.

viper it effects the outcome big time if that's the algorithm being used..... it means that you would be paying for a ticket that has a 0% chance to be drawn.... not a .00000001% chance, a 0% chance. it's tossing your money in the trash for false hope.

...and has Opti come on here himself and said that's the algorithm being used?  No.  The person who posted the code is Chief149, who has no access to the server back-end and no idea what changes Opti might have made to improve the lottery plugin.  So what's the debate about?!  

Opti has come on and said that my explanation (WAY BACK) is the correct one.  That each draw is completely random, and your odds of winning are based solely on the number of tickets in your hand.  You're throwing around facts and figures that have no basis in this server's reality.  So once again, what's the debate about?

Quote from: ViperZeroOne on July 22, 2012, 01:58:41 AM

Quote from: tiggy26668 on July 22, 2012, 01:55:50 AM

Quote from: ViperZeroOne on July 22, 2012, 01:52:34 AM
Ok, let's set aside the algorithmic discussion for a minute because that's so WAY off from effecting the outcome of the lotto draw that it's not even worth mentioning.  It IS random, and it IS fair, because each consecutive draw doesn't include the winning ticket from the last draw, and a whole new random draw is done.  Plain and simple.

So, those of you who aren't winning, just suck it up and make the odds better in your favor.  Either find a four leaf clover, hang a horseshoe, or do something that'll improve your luck cause the odds of winning are only as good as the number of tickets you buy.

viper it effects the outcome big time if that's the algorithm being used..... it means that you would be paying for a ticket that has a 0% chance to be drawn.... not a .00000001% chance, a 0% chance. it's tossing your money in the trash for false hope.

...and has Opti come on here himself and said that's the algorithm being used?  No.  So what's the debate about?!  He has come on and said that my explanation (WAY BACK) is the correct one.  That each draw is completely random, and your odds of winning are based solely on the number of tickets in your hand.  So once again, what's the debate about?

i suppose i would just love to know the algorithm being used, so that i might test it like i did that one, and ease my conscious knowing that it wont skip numbers randomly, and so that i could assure myself that the chances  of each ticket being drawn really is fair to an acceptable degree.... from what I've experienced since the lotto was implemented it appears to be quite unfair so I apologize for being concerned for myself and everyone else who feels cheated.....

Concern is fine, but when the person who actually modified and implemented the code (Optical) says nothing is wrong with it, then nothing is wrong with it.  With all the coding repairs he's already done on this server, I think we can trust that he's fixed a randomized number.

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)

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)

Indeed, I was about to say that.

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)

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
[spoiler]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.[/spoiler]

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
[spoiler]
http://en.wikipedia.org/wiki/Linear_congruential_generator
"LCGs should not be used for applications where high-quality randomness is critical."
[/spoiler]

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.

Quote from: optical on July 22, 2012, 01:38:43 PM
For this type of number generation it is adequate.

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

Quote from: optical on July 22, 2012, 01:38:43 PM
For this type of number generation it is adequate.

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*