An exploration of randomness.
  • 266 posts
  • Page 9 of 18
Matty wrote:
Don't apologise, your question has alot more meaningfull content than the one that interfered :)


Edit: not MY first post as an answer to your question, but Vexer's first post in this topic:
http://www.dominating12.com/forum/?cmd=topic&act=view&id=879&board=19&page=1#post-11971
"Strength doesn't lie in numbers, strength doesn't lie in wealth. Strength lies in nights of peaceful slumbers." ~Maria
scaldwell17 wrote:
I have 4 (somewhat divergent) points:

1. "The plural of anectode is not evidence" - i.e. just because something unusual happened more than once doesn't make it a trend

2. There is no thing called "clumping". The point I brought up is that what we may _think_ random looks like is rarely an accurate representation. Flip a coin 100 times. You'll get 5 heads in a row a lot more often than you'd think. Similarly, losing 15-0 isn't common, but it's a lot more common than you'd expect.

3. Some players don't have those big bad losses quite as much because they stop rolling. If the rolling isn't going in your favour, often it's better to cut your losses and live to fight another day than to keep going, getting more frustrated as you keep losing troops and guaranteeing a loss.

4. Maybe it's worth instating a dice complaint policy - record all dice rolls over ...5?... games, tabulate them, and record 6s, 5s, 4s, 3s, 2s, and 1s - in order to back up the claim that dice are systematically low or high. You could call it the One Million Dollar D12 Challenge:

http://en.wikipedia.org/wiki/One_Million_Dollar_Paranormal_Challenge
aeronautic wrote:
Sorry for length of post again... some topics need good explanations to clearly explain your point!

I fully accept the randomness of 1 number (1 dice) being able to come up 15 times in a row, it happens on roulette tables where a particular colour comes up that many times, regularly!
My point was never this, it was, that the bad luck rolls, (heavy losses) are due to a synchronisation of high and low rolls, so if the attacker gets a high roll so does the defender and vice versa!
This will result in nearly all rolls being a loss to the attacker and because the defender threw a low roll the same time, but beat the attacker, the chances of probability is that they will throw either an average or high roll next, putting the attack dice at a disadvantage.
Is it possible then that the dice program could be feeding off its own results to create more randomness and causing the synchronisation that regularly occurs and causes massive losses to one player?
If so, please indulge me for a few posts and consider, would the program benefit from external independent generators and no recall of the previous results.
Why can't it just generate 1 set of 3 / 2 / 1 dice rolls for attacker and a separate set of 2 / 1 for defender from different programmes or areas of code where the results of both are not seen or read by the other and only placed in a result area for calculation by a different code or program and deleted from the generator's memory i.e. reset before generating the next?
That way it would make it impossible for the computer program to compare its own results and try to create more randomness, i.e influence itself!
If I had spent months working on what I thought was infallible, I would be very subjective and downright defensive of anyone suggesting otherwise, especially if my test models provided the best random data ever seen. However, this is how I am, about almost everything dear to me and it stops me seeing other possibilities.
I don't blame you programmers for getting narked when players constantly call the dice "fixed", "useless" & various other things, which I have not, ever!

I know you have possibly the best virtual dice generator in the world, but I have spotted something I think might be relevant and ask that you have a cup of coffee and ponder it?
I always think of programs as machines and there's always something you can change or add to make it better!
Hyd yn oed er fy mod Cymraeg , dim ond yn siarad Saesneg, felly yr wyf yn gobeithio y bydd y cyfieithu yn gywir.
Cireon wrote:
aeronautic,

It is good to see some actual constructive feedback on the dice and while I am not completely up-to-date on how random number generators actually work, I understand where you're coming from.

Here on Dominating12 we have actually used an external random generator for quite a while. Of course these results were as random as you could get them, but we had to do a lot of calls to an external server, which slowed down the game. This is why it was decided to move to an internal random number generator. Back then, there seemed to be (almost) no difference at all between the two, though I think the tests only considered distribution and average of the rolls.

Going back to an external random dice generator will slow down games a lot again and while dice are important, you don't want to wait a full second for every click you make.

Of course, dice rolls will always be close together because the maximum difference is only five! With so "many" dice and so little possibilities, the chance of double rolls is also high.
What I can do (if I figure out how the testing scripts work) is calculate the average standard deviation. The standard deviation is a measure for how far apart the results are. So 4,2,6,1,3 would get a higher standard deviation than say 2,2,3,2,1. The differences will be minimal, but it is probably possible to calculate the expected standard deviation if we choose the numbers randomly (worst-case we iterate over all possibilities and calculate the standard-deviation). Then we can compare the test results with the algebraically calculated number to see if you're right or not.

Finally, I want to stress out one point. I am interested in testing this, but I am pretty sure it will not result in anything. We have also simulated attacks between defenders and attackers and calculated the win percentages for both parties and those are very close to what is expected, based on the percentages from the Wikipedia page. So for me that is quite enough proof that the dice are not suffering from a problem at all. That's why this will not be prioritized by me, because there are a few other things that are actually broken or just more important.
“This is how humans are: We question all our beliefs, except for the ones that we really believe in, and those we never think to question.”
- Speaker for the Dead, O.S. Card
elysium5 wrote:
I do not know if everyone has bothered to read this entire thread but here is a short summary of conversations on the subject between Cireon and myself on the matter as I believe it may have been my yipping that had this thread title changed from 'The site's dice are accurately random' to 'The site's dice are accurately psuedorandom.'

If anyone wants to know how the dice generators work, please check out 'random.org' for an analysis on the difference between a Pseudo Random Number Generator(PRNG) and a True Random Number Generator(TRNG).

In the opening post Vexer explains that a PHP is used to generate the randomness. This site (random.org) explains why a PHP is a PRNG and not a TRNG.

D12 had used random.org as random generator for a while. The consequence of this, however, is that attacking was incredibly slow all the time. You sometimes had to wait at least a full second for the dice to be rolled and this is of course a big problem when playing live games or having a game where troop numbers have reached hundreds. It was therefore decided to use the PRNG mt_rand.

Using the mt_rand function has hugely sped up the attacking during games. The mt_rand function is indeed not 'Truely' random, but believe me, it is very close and about as close as you are going to get using a computer PRNG. If you are interested, I suggest looking up some information about mt_rand and why it is considered an extemely accurate, if the the best, substitue for a TRNG.

On http://en.wikipedia.org/wiki/Mersenne_twister about Mersenne twister (the algorithm that mt_rand uses), you can find more information if you are interested, but I especially want to point people to the "advantages", where it states that this algorithm passes almost every random test.

On a side note, according to several other sources the PHP used here - mt_rand - is one of the best PRNG's but it is still not a TRNG.
"Bad Deadpool... Good Deadpool!"
Matty wrote:
aeronautic - Nov 28, 05:36 AM
I fully accept the randomness of 1 number (1 dice)

...

Is it possible then that the dice program could be feeding off its own results to create more randomness and causing the synchronisation that regularly occurs and causes massive losses to one player?
You say two things here:
First you say that getting one result is random.
Second you say that the 'dice program' is comparing results, synchronizing them to make things look more random.

You might not realize, but this is a contradiction.
If the 'randomizer' uses the old result to bias the new outcome to make sure it looks spread apart enough, than it is not a good randomizer anymore.

So the answer to your question (a valid question) is simple: no, the 'dice program' does not apply cheap synchronisation tricks to make it's numbers look random - instead it's numbers are random in the way they are supposed to be.



Lets say we roll real dice, in the real world, then what you suggest is this:
The attacker should roll his three dice in one room, and the defender should roll hos two dice in another room, so that they cannot see eachothers results.
Do you see how this does not make things more random?



@Elysium, the thing about TRNG and PRNG is merely a theoreticla one - no one in the world will ever be able to see a difference.
"Strength doesn't lie in numbers, strength doesn't lie in wealth. Strength lies in nights of peaceful slumbers." ~Maria
elysium5 wrote:
@Matty. I agree. That is why I reposted some of those points. There is virtually no difference with the program that is currently being used. It just helps to speed things up.
"Bad Deadpool... Good Deadpool!"
aeronautic wrote:
@Matty you completely missed the point...
"I fully accept the randomness of 1 number (1 dice)", was a referral to the whole Universe where it is possible in randomness for a same number to come up maybe 15 times in a row, same as a colour in roulette!

"Is it possible then that the dice program could be feeding off its own results to create more randomness and causing the synchronisation that regularly occurs and causes massive losses to one player?", was a referral to the final results of sets of numbers generated, calculated, displayed, logged, reset and re-generated for both attack & defence dice and with the question of, "If so, please indulge me for a few posts and consider, would the program benefit from external independent generators and no recall of the previous results?"
Something both Cireon & elysium5 had no problem with how I quoted, explained and asked.
And, I never implied there were any cheap tricks used either, please, reread the lot as you have not comprehended it correctly!
And humans cannot change the outcome of the dice as they are really rolled whereas computer number generation can be chosen... by the computer.
You also had to have read what I had noticed in the dice in the first place on a previous post.
I find this reply very pompous, please rethink it!
Hyd yn oed er fy mod Cymraeg , dim ond yn siarad Saesneg, felly yr wyf yn gobeithio y bydd y cyfieithu yn gywir.
Vexer wrote:
I know why you, aeronautic, are seeing patterns where there are none.

The dice are sorted from high to low before they are displayed.

You see 6-5-4 and 6-5 or 2-1-1 and 2-2
But they were not rolled in that order.
It could have been 5-6-4 or 4-5-6 or 6-4-5 or 5-4-6 or 4-6-5 or 6-5-4
and all would be displayed to you as 6-5-4.

You asked if the offensive dice could be rolled separately from the defensive dice. Each dice roll is rolled by a separate call to the mt_rand function. And players in other games are calling that function in between your calls to that function. So what you want is already happening. They are separate.

But what you have said did give me an idea on how to mix things up just in case what you are saying is true. Right now it rolls 3 offensive dice and then 2 defensive. Instead I could experiment with it rolling all 5 dice and then randomly choosing which ones are offensive and which are defensive. I am 100% sure that we will get the same results in the long term by hitting the 53.96% attackers advantage but it's possible that reprogramming it this way could affect the distribution. It would be ideal to get close to 53.96% after 1000 rolls instead of 10000.
aeronautic wrote:
Sounds good! I didn't mean the pattern you described above though, I meant when attack has a high roll e.g 66 or 65 the defence gets one as well and when low the same, these are where the big losses occur, but it only happens in some games, the rest are truly random, but that aside, you have agreed to try something that may well change any chance of this being a program thing. Thanks!
Hyd yn oed er fy mod Cymraeg , dim ond yn siarad Saesneg, felly yr wyf yn gobeithio y bydd y cyfieithu yn gywir.
Matty wrote:
@Vexer, I can tell you that that won't help, but it won't hurt either (except that it would be one more random call to choose which dice are att and wich are def, but no one will notice that extra time probably), so feel free to program it.
"Strength doesn't lie in numbers, strength doesn't lie in wealth. Strength lies in nights of peaceful slumbers." ~Maria
The_Bishop wrote:
I completely trust in the site dice as they are. No technical explanations are needed nor improvements in my opinion. I mean, guys, even my portable calculator is able to simulate the randomness of a die! Here we are using the most modern random-generator algorithms... Ok, it's fine, surely enough!

Dice complainers sound a bit ridiculous to me. It's like you lose 10 rolls in a row in the board game and then you call the society and say: "I lost 10 rolls in a row, these dice don't work!". Lot Of Laugh would be the probable answer.

To prove they are wrong, tests should be done on "clusters" of rolls. I don't know how to explain. For example one rolls 10 times, the average result is attacker loses 9 and kills 11. Ok, but there are other 20 possible results. I want to know if each result occurs the number of time which is expected by theory. In other words not only the average value should be verified but the entire distribution of a "cluster" of rolls, I supposed with size = 10.

By the way I'm pretty confident that dice are like in reality. The fact is that in reality you play 10 games per year, here you play 10 games per day! Look, more than 200,000 games played here with hundreds or probably thousands of rolls per game... Billions of rolls!! Do you think to be the first which loses 10 in a row? I don't think so.

Dice are unpredictable! It's a skill of a player to understand that. There are sites which use "normalized" dice to avoid the most extreme outcomes. I don't like that. Nor even the solution proposed in the first post of this thread. Dice must remain as they are... Just, random!
«God doesn't play dice with the World» ~ Albert Einstein
aeronautic wrote:
This is what and only what I seek too The_Bishop

aeronautic
I don't blame you programmers for getting narked when players constantly call the dice "fixed", "useless" & various other things, which I have not, ever!

I know you have possibly the best virtual dice generator in the world
I believe though that random is a natural thing not a computer processor/program thing and anything that can be done to make it more so, is a good thing. The programmers have admitted that the code for all the dice value generation and its calculation and distribution, is all within 1 area of code (subroutine I guess).
They have offered to use a new method of distribution which may give anylised results of improved randomness or may worsten, but it will only be to the benefit of the program, should it work!
Hyd yn oed er fy mod Cymraeg , dim ond yn siarad Saesneg, felly yr wyf yn gobeithio y bydd y cyfieithu yn gywir.
elysium5 wrote:
I have have stated many times in the past; please check out random.org if you want to see a better explanation of the difference between TRNG's and PRNG's and Vexer has already said why the site, which used Random.org's TRNG originaly, switched to one of the best PRNG's in the world, mt_rand, so the dice rolls would be faster.

Again, I was the one who pushed so hard to prove that the dice were not true random, BUT, in doing actual research, I also discovered that the program being used is literally one of the best and most acuurate in the world and if it went back to the original TRNG, the dice would slow down the game way to much.

Please read the entire thread about this subject and if you have an issue with the generator, please explain EXACTLY why mt_rand is inferior, which avaliable program is superior other than a TRNG that will slow down the games by a very large margin (not even poker sites use a TRNG because it is too slow), what program should be used in its place and why.

Thank you.
"Bad Deadpool... Good Deadpool!"
aeronautic wrote:
@elysium5
I'm not sure if the last post was for me as it mentions TRNG & PRNG, which I have not talked about, nor disputed?

I am going by my earlier posts and what I noticed, put to the staff and got a variety of responses for, but it got them all thinking and Vexer said this:

Vexer
But what you have said did give me an idea on how to mix things up just in case what you are saying is true. Right now it rolls 3 offensive dice and then 2 defensive. Instead I could experiment with it rolling all 5 dice and then randomly choosing which ones are offensive and which are defensive. I am 100% sure that we will get the same results in the long term by hitting the 53.96% attackers advantage but it's possible that reprogramming it this way could affect the distribution. It would be ideal to get close to 53.96% after 1000 rolls instead of 10000.
I hope this clarifies what I say?
My last post was toward The_Bishop, to clarify that I have not asked for the dice program to be changed in any way from using commands like mt_rand function or anything, only to eliminate things that programmers have no part in causing and that is the computer influencing itself.
Remember, some scientists had to make the binary ability of computers preset to understand mt_rand and lots of other language functions and to carry out the request the way it was preset to do.
Hyd yn oed er fy mod Cymraeg , dim ond yn siarad Saesneg, felly yr wyf yn gobeithio y bydd y cyfieithu yn gywir.