Mithrilpoint
Joined: Mar 16, 2004
|
 Posted:
Jun 01, 2005 - 15:34 |
 
|
You might wanna edit out your post Shepherd. What you wrote is below you.
M |
|
|
sk8bcn
Joined: Apr 13, 2004
|
| Posted:
Jun 01, 2005 - 15:50 |
|
I've heard the same than Rinkky but I am a mathematician, no computer specialist so I'll follow the discuss(rumble) between Rinkky and BBM with interest.
I had cool jokes about a new dice generator thread, but it's dead. Better read something real interesting. |
|
|
CircularLogic
Joined: Aug 22, 2003
|
| Posted:
Jun 01, 2005 - 16:17 |
|
| Rynkky wrote: | | SubSonic wrote: | | trouble wrote: |
So if you rolled 111111 the odds of the next dice being a 1 are less because six ones have already been used. Its not much less, but it is less. |
it just doesnt work that way... |
Explain me why? I'll explain you why I think you're wrong.
Lets assume that random number generator uses 32-bit seed. If that is the case, then the random number series will be 2^32 (4294967296) numbers long. Now, if you take those six ones out of those 4294967296, doesn't it mean that you'll have six ones less in the rest 4294967290 rolls? For me it does because random number generator can be perceived as a LIMITED pool of random numbers, from which you just pick the next available. With same seed the numbers and the order will always be same. |
Thx Rynkky, you have successfully argued against your own statement.
Some basic mathematics show, that 2^32 has no prime factor 3 in it, hence it´s not possible to divide it by 6 without fractions. This shows us, that there is NOT an equal amount of every number from 1-6 possible. As the numberstring according to you contains 2^X (with X= bits of seed) values, it doesn´t matter what seed is taken.
That´s what I expected, because the string of numbers should be random enough for our purpose, meaning with no discernable pattern within a sample size of less then 1k rolls (which is a BB-game). Sure, you have a gigantic sample size, so the average of all rolls will be damn close to 3.5, but that´s what the "Law of great number" (or what the "Gesetz der großen Zahlen" is called in english) postulates. The average is only near 3.5 because of the huge amount of rolls and there is no "evening out" enforced, meaning, that in every 600 rolls, some king of alorithm checks, that there are 100 1s and 100 6s. If you generate string long enough, you will get a string with ONLY 6s in it (though you have to bring up some patience  )
The major fact derived from this is:
The chance for rolling a 1 after 10 1s is as high as rolling ANY other number (OK... 7 isn´t really as likely, but you know what I mean).
So you can talk about a random enough generator, even if it may seem otherwise. I can show you a replay, where my elves have failed every single 2+ roll not backed up by a reroll for a whole half.
btw:
I tend to believe Rynkky, how the numbers are generated, instead of the quote of BMM, but Rynkky is wrong on the math behind it IMO. That´s simply because of the fact, that BMM´s way would make the sync of rolls impossible.
The program Rynkky talks about must be a crack of the JBB-tool, as there is no way of recalculating the seed within the first 100 rolls, if JBB-tool starts on a random position in the string. To predict the dice rolls, you will have to know to variables (seed and position), which I can´t believe to be derived with only 100 rolls given. To make a prediction, you have to get those 2 variables (which are shared by host&client to get rolls in sync), which only works in form of a hack.
A last point:
I´m don´t know much about proggin/Java, I just know about math. |
Last edited by CircularLogic on %b %01, %2005 - %16:%Jun; edited 1 time in total |
|
LordSnotball
Joined: Nov 05, 2004
|
| Posted:
Jun 01, 2005 - 16:19 |
|
ok, this is my comparison between RL and computer based Nuffle:
Necromunda: i actually managed to roll the 111111 combo on turn 1, alternating dice to remove the jinx. needless to say i completely ran out of ammo...
BB here: http://fumbbl.com/FUMBBL.php?page=match&op=view&id=721311
watch my first 3 turns as the dark elf player... pity u can't see the rerolls, managed to reach 11111 i think. end of turn 3, i had luck 1% still...
my 'trick' for changing a bad dice day, is to alternate between hosting the game. if u host and the dice are bad, next match get ur opponent to host. that way its his computer's fault, not yours! of course, after a few bad matches, u expect a few good matches, so u are letting someone else host during ur good matches! *snicker*
and, if i'm not mistaken, the dice rolls for your skills are done by the java client, not by the website. can't hear many ppl complain coz they rolled double 1s for skills now, can you... aging? well, depends... |
_________________
-Snottie
The Congregation - Always Recruiting
[url=http://igolocal.net/badge.php?user_id=1949] [/url] |
|
Rynkky
Joined: Aug 03, 2004
|
 Posted:
Jun 01, 2005 - 17:04 |
|
| Shepherd wrote: | | { edit: nasty things. } |
{ edit: nasty things in return. }
I DO admit that my posts are getting more and more grim but that is because everyone starts copy pasting things to this thread which are either total bullshit or only partly true. These posts keep me repeating myself over and over again. This leads to certain anger and makes my posts grim. I am sorry about that.
{ edit: Ok, can we now stop with the insults, guys? I entirely understand the last sentence here... in fact, I do it all the time. It's a simple miscommunication, however. No need to keep it rolling along. - BMM } |
|
|
CircularLogic
Joined: Aug 22, 2003
|
| Posted:
Jun 01, 2005 - 17:22 |
|
Usually Shepard is a cool guy, but as I see it, he likes BB more as a beer-and-pretzels-game and less as a science. You were the most scientific and you formulations contained lot´s of stuff not understandable for the most (e.g. the code with the comments). Some people get the feeling, that you regard them as idiots, when you talk like that -> thus the reaction.
The amount of writing you did to your defense shows me, that he scored some kind of hit... |
|
|
Shepherd
Joined: Oct 28, 2004
|
| Posted:
Jun 01, 2005 - 17:22 |
|
| Mithrilpoint wrote: | You might wanna edit out your post Shepherd. What you wrote is below you.
M |
Garr, too late. Rynkky quoted me. I'm a little sensitive today, I guess.
I stand by the idea that if you're going to disagree with somebody, mocking them is not the appropriate way to go about it, but you're right, that was pretty uncivilized. If a mod wants to scrub it, that's their perogative and I won't object.
Edit: thanks, BMM. I might have substituted the libretto from A Shoggoth On The Roof, but that wouldn't have been very productive either. |
_________________
A super-hero that always fails his Bonehead roll: MAN-MAN, the averagest hero alive!
Buy Dead Eyes Open, starting July 2005 from Slave Labor Graphics!
Last edited by Shepherd on %b %01, %2005 - %18:%Jun; edited 1 time in total |
|
Azurus
Joined: Aug 02, 2003
|
| Posted:
Jun 01, 2005 - 17:36 |
|
Rynkky is actually right, you know. Using a seperate seed for each player would be better than using the same for both, but only infinitessimaly (spelling?) so.
It certainly would have exactly NO difference on a single match though, let alone consecutive turns. If you take out 6 '1's from the string, then there will be six less available, making the probability one will come up less. Given the size of the pool though (Rynkky used power 32 in his exaple, was it?), this difference is negligible enough to be effectively zero.
So, while he's right, making statements along the lines of *one player rolling 5 6's and ending a turn means the other player will probably roll a 1* (excuse me for paraphrasing, I couldn't be bothered to find the quote again) doesn't help his case since it isn't true to any detectable extent. The theory is correct, just not over a sample of the size provided by consecutive turns, or even one game.
So yes, it is flawed, but certainly no more than real dice are, and niether one is flawed to an extent measurable in a sample as small as a single BB game. One players good luck DOES NOT lead to the other's bad luck in such a small sample.
Right, that's my post for the week done. /me wanders off again... |
_________________
*This is a public safety announcement. Azurus is a cynical, sarcastic idiot. Please ignore any and everything he may say. Thank you for your attention.* |
|
Rynkky
Joined: Aug 03, 2004
|
| Posted:
Jun 01, 2005 - 17:43 |
|
| CircularLogic wrote: |
Thx Rynkky, you have successfully argued against your own statement.
|
Great! Lets see your argument.
| CircularLogic wrote: |
Some basic mathematics show, that 2^32 has no prime factor 3 in it, hence it´s not possible to divide it by 6 without fractions. This shows us, that there is NOT an equal amount of every number from 1-6 possible. As the numberstring according to you contains 2^X (with X= bits of seed) values, it doesn´t matter what seed is taken.
|
Yes? Where exactly did I claim so? What I have been trying to say is that total number of possible numbers is fixed. I also claimed that calculating average on those numbers will go towards 3.5. The bigger the sample is more close to 3.5 it will be. I also claimed that if you roll six ones there will be six ones less in the possible results (i.e. the whole set has less number ones left). I said nothing about even amount of each numbers, did I?
| CircularLogic wrote: |
That´s what I expected, because the string of numbers should be random enough for our purpose, meaning with no discernable pattern within a sample size of less then 1k rolls (which is a BB-game). Sure, you have a gigantic sample size, so the average of all rolls will be damn close to 3.5, but that´s what the "Law of great number" (or what the "Gesetz der großen Zahlen" is called in english) postulates. The average is only near 3.5 because of the huge amount of rolls and there is no "evening out" enforced, meaning, that in every 600 rolls, some king of alorithm checks, that there are 100 1s and 100 6s. If you generate string long enough, you will get a string with ONLY 6s in it (though you have to bring up some patience )
The major fact derived from this is:
The chance for rolling a 1 after 10 1s is as high as rolling ANY other number (OK... 7 isn´t really as likely, but you know what I mean).
|
In theory this is true. But still I claim that both players using same random number generator instance will share the number pool as well. Thus if other player has a peak of good rolls that usually (I never claimed that it always) means that the other player will have peak of bad rolls. My experiments with Java random number generator have shown me that even on 100 rolls distribution is pretty even. Of course there is peaks when distribution is not in balance but that is result of sample size.
| CircularLogic wrote: |
So you can talk about a random enough generator, even if it may seem otherwise. I can show you a replay, where my elves have failed every single 2+ roll not backed up by a reroll for a whole half.
|
Nothing new here. You are sharing number pool with your opponent. So you had bad luck getting the low numbers while your opponent took the good numbers.
| CircularLogic wrote: |
btw:
I tend to believe Rynkky, how the numbers are generated, instead of the quote of BMM, but Rynkky is wrong on the math behind it IMO. That´s simply because of the fact, that BMM´s way would make the sync of rolls impossible.
|
What you say here is true. It would be impossible indeed.
| CircularLogic wrote: |
The program Rynkky talks about must be a crack of the JBB-tool, as there is no way of recalculating the seed within the first 100 rolls, if JBB-tool starts on a random position in the string. To predict the dice rolls, you will have to know to variables (seed and position), which I can´t believe to be derived with only 100 rolls given. To make a prediction, you have to get those 2 variables (which are shared by host&client to get rolls in sync), which only works in form of a hack.
A last point:
I´m don´t know much about proggin/Java, I just know about math. |
No hack needed. You do not even have to modify JBB client in anyway. Java gives us many other possibilities which I will not describe in detail here. |
Last edited by Rynkky on %b %01, %2005 - %17:%Jun; edited 1 time in total |
|
Mezir
Joined: Aug 02, 2003
|
| Posted:
Jun 01, 2005 - 17:46 |
|
Code words are still "large" and "enough", used in that order. |
_________________
Build a man a fire and he's warm for a day; set a man on fire and he's warm for the rest of his life. |
|
CircularLogic
Joined: Aug 22, 2003
|
| Posted:
Jun 01, 2005 - 18:02 |
|
| Rynkky wrote: | | CircularLogic wrote: |
Some basic mathematics show, that 2^32 has no prime factor 3 in it, hence it´s not possible to divide it by 6 without fractions. This shows us, that there is NOT an equal amount of every number from 1-6 possible. As the numberstring according to you contains 2^X (with X= bits of seed) values, it doesn´t matter what seed is taken.
|
Yes? Where exactly did I claim so? What I have been trying to say is that total number of possible numbers is fixed. I also claimed that calculating average on those numbers will go towards 3.5. The bigger the sample is more close to 3.5 it will be.
|
You claimed, that the string generated from a seed with X bit in sizes has 2^X digits. Basing on this assumption I proved with math, that the amount of each number can´t be equal, thus the amount of 1s is not the same in each string. In fact the amount varies according to the standard deviation.
| Rynkky wrote: |
I also claimed that if you roll six ones there will be six ones less in the possible results (i.e. the whole set has less number ones left). I said nothing about even amount of each numbers, did I? |
You claim about the probability changing because of the results rolled before is only valid, if you assume a complete even amount of each number as a SURE FACT. If you say that Java generates a string of 6000 numbers and each string contains each number exactly 1000 times, then your claim would be correct. But as the the amount of every single number is random (it varies from 0 to 2^X with an expectation-value of (2^X)/6 and a standard-deviation I´m too lazy to calculate), having a string of 6 1s doesn´t influence the possibility for the next digit if there is no algorithm in the generator adjusting the probabilities for each event according to the last events, which I highly doubt (as it wouldn´t be a random anymore and worth shit for alot of other applications).
Regarding the programm:
Math tells me, that you can´t derive the needed variables (seed and position in the string) for dice-prediction from the results you can see on the interface, especially as you don´t know, if a push-block-die is a 3 or a 4. Thus you must use ways to gather more information, that the tool usually gives to you, thus you must use some kind of hack (either against the tool or against Java or against the communication between host&client). |
|
|
Rynkky
Joined: Aug 03, 2004
|
| Posted:
Jun 01, 2005 - 18:21 |
|
| CircularLogic wrote: | | Rynkky wrote: | | CircularLogic wrote: |
Some basic mathematics show, that 2^32 has no prime factor 3 in it, hence it´s not possible to divide it by 6 without fractions. This shows us, that there is NOT an equal amount of every number from 1-6 possible. As the numberstring according to you contains 2^X (with X= bits of seed) values, it doesn´t matter what seed is taken.
|
Yes? Where exactly did I claim so? What I have been trying to say is that total number of possible numbers is fixed. I also claimed that calculating average on those numbers will go towards 3.5. The bigger the sample is more close to 3.5 it will be.
|
You claimed, that the string generated from a seed with X bit in sizes has 2^X digits. Basing on this assumption I proved with math, that the amount of each number can´t be equal, thus the amount of 1s is not the same in each string. In fact the amount varies according to the standard deviation.
|
Ok. We have misunderstanding here. What I meant by saying that when using 32-bit numbers with an optimal randomizing algorithm it is possible to get string that is 2^32 numbers long. What I failed to add to this is that after this algorithm starts creating same series again. Thus the seed is depleted and it comes back to original value, thus starting the same series again. Non-optimal algorithms deplete their seed even earlier thus giving shorter strings. I did not say that distribution is even in this string. I only said that the average is very close if not even to 3.5. But because of the numbers "randomness" the distribution is quite even as well. Not optimal but very close to that.
| CircularLogic wrote: | | Rynkky wrote: |
I also claimed that if you roll six ones there will be six ones less in the possible results (i.e. the whole set has less number ones left). I said nothing about even amount of each numbers, did I? |
You claim about the probability changing because of the results rolled before is only valid, if you assume a complete even as a SURE FACT. If you say that Java generates a string of 6000 numbers and each string contains each number exactly 1000 times, then your claim would be correct. But as the the amount of every single number is random (it varies from 0 to 2^X with an expectation-value of (2^X)/6 and a standard-deviation I´m too lazy to calculate), having a string of 6 1s doesn´t influence the possibility for the next digit if there is no algorithm in the generator adjusting the probabilities for each event according to the last events, which I highly doubt (as it wouldn´t be a random anymore and worth shit for alot of other applications).
|
I do get your point. And you're right here. But as I said in my previous post distribution is pretty even for 100 rolls in Java random generator. Thus in one BB game (1000 rolls you said?) the distribution is close to even as well in most cases (please note I did not say every). Thus making my original claim valid.
| CircularLogic wrote: |
Regarding the programm:
Math tells me, that you can´t derive the needed variables (seed and position in the string) for dice-prediction from the results you can see on the interface, especially as you don´t know, if a push-block-die is a 3 or a 4. Thus you must use ways to gather more information, that the tool usually gives to you, thus you must use some kind of hack (either against the tool or against Java or against the communication between host&client). |
If I am using something that Java offers for us developer, which also is complete legal, I do not see it as a hack. You propably did know that you can listen packets in TCP/IP network using proper software? Even packets that are not yours. Even that is not hacking, because this information is public to all who are connected to same cell. |
|
|
Penix
Joined: May 25, 2005
|
| Posted:
Jun 01, 2005 - 18:44 |
|
...
I'm close to get mad with this....
I'm probably the one with less idea, but the Rynkky 's theory (let me call it this way;)) matches with my short experience here.
An my question is: can someone (Rynkky o whoever) fix it putting those separated generators? |
_________________
Why do I foul?
'cause I can |
|
BadMrMojo
Joined: Aug 02, 2003
|
| Posted:
Jun 01, 2005 - 18:44 |
|
Re: the smackdown people were waiting for as a followup to a very old forum post, it's on the page 4. I think you'll be disappointed, however, as I'm entirely willing to concede points in order to form an actual resolution.
Re: personal attacks: I hope nobody minds that I went back and did a wee bit of editing. It just wasn't getting any of us anywhere and detracting from an otherwise interesting discussion. I hope I successfully managed to defuse things rather than exacerbate them by doing so. If not, then go ahead and say nasty things about me. I'm a big boy. I can take it. 
Re: 32-bit seeds: If I remember correctly, Ski has noted in an older post that it is actually a 48-bit seed. I could be wrong on that but it's a relatively minor point.
Re: theory versus practice (the on-topic stuff):
Circular brought up a very good point about the synchronization of die rolls. Given that, I'm entirely willing to say that my clock cycle beliefs were wrong. If anyone feels as though they have been deeply traumatized by my mistake, then please accept my sincere apologies for my failings.
I must point out that Rynkky knows entirely more about Java than I. Look at his excellent replayer, for example. I've actually been convinced that Rynkky is right in theory. I think that simple math, however points towards CircularLogic's argument as being correct in practice.
Let's look at a purely hypothetical, extreme, will never happen, worst case scenario. Your opponent rolled nothing but sixes all match long. Impossible? Not with truly random numbers... just infinitessimally unlikely. Anyway, let's say that your opponent rolled 1,000 sixes and you haven't rolled a single six all game (you've rolled 999 non-sixes, just for the sake of argument). Now, finally, on the very last roll of the game, you need to get a six. How much has your opponent's luck affected your rolls?
We have 2^48 possible rolls, roughly distributed between 1 and 6 (note that this is not 100% accurate, but just an estimation. The margin of error is small enough with this large of numbers that we really don't have to worry about it too much). That means ( 2^48 )/6 possible sixes, right? Of those, your opponent has used up 1,000.
2^48 = 281,474,976,710,656
281,474,976,710,656/6 = 46,912,496,118,442.66
(Assume that the distribution is not 100% accurate, so we'll round that down, saying that there are infinitessimally less than normal chances of getting a 6 (I have no clue if this is true, but I'm giving the benefit of the doubt). Let's say that instead of 46,912,496,118,442.66 possible sixes, a mere 46,912,496,118,000 are sixes.)
46,912,496,118,000 (possible sixes) - 1,000 (sixes used up by your opponent) = 46,912,496,117,000 (sixes remaining)
Your chances or rolling a six are (the number of sixes remaining) divided by (the total "pool" of dice minus the number of dice rolled). Right?
46,912,496,117,000 / (281,474,976,710,656 - 2,000) = 0.1666666666663
Now, that would mean the the difference between the actual result and the hypothetical, perfect 1/6 is....
0.1666666666663 / (1/6) = 99.9999999998%
In the absolute worst possible case, you've got a margin of error of 2 / 10,000,000,000 of a percent.
Why on earth are we actually arguing over this again?
*** disclaimer ***
I am neither a java developer, a mathematician, a logician, an alchemist nor a moose. I am not a grad student or an educator. I have never been awarded a major prize for science, mathematics, baking or dog-walking. I could very likely be wrong on one of these points and I would be thrilled to find out if this was the case. The point of all these numbers was not to overwhelm people or make them afraid to question the logic behind them. It was simply an attempt to put things into perspective and back up my beliefs with actual data. If there is any flaw in the numbers or the methodology, please let me know. |
_________________
Ta-Ouch! of BloodBowl
Condensed Guide for Newbies |
|
CircularLogic
Joined: Aug 22, 2003
|
| Posted:
Jun 01, 2005 - 18:52 |
|
| Rynkky wrote: | | I do get your point. And you're right here. But as I said in my previous post distribution is pretty even for 100 rolls in Java random generator. Thus in one BB game (1000 rolls you said?) the distribution is close to even as well in most cases (please note I did not say every). Thus making my original claim valid. |
To make your claim valid, the amount of each number must be exactly the same for each number in EVERY string. This is a prerequisite for the claim, that past results affect the next events.
Fact is:
You don´t know, how many 1s are up the next twenty rolls. How do you want to argue, that rolling 10 1s changes the probability of having a 1 next roll? There could be 20 1s coming up, there could be only the 10 1s, you just rolled - you just don´t know.
And when you look at a random string, the probability for having 6 1s in a row is exactly 5 times as high as having 7+ 1s in a row.
Regarding the hack/no-hack discussion:
Decryting packages not intended for me and using the information, isn´t this part of the thing called hacking?
From a gamer´s point of view you are clearly using a hack -> gathering information you should not have according to the game. |
|
|
|
|
| |
NBFL Season 32: The ...
Search
