Moderated Coin Flipper

[psionl0]

How so... the running averages are flipping over all the time and in one shot the running average is higher for heads and in another for tails and then again.

You're right. The flipper is not as conclusive as I originally thought. A run of 10,000 is apparently not sufficient for any bias to show up through the noise.

I might have to run some numbers on what sorts of results you should expect.

 

[Leumas]

You're right. The flipper is not as conclusive as I originally thought. A run of 10,000 is apparently not sufficient for any bias to show up through the noise.

I might have to run some numbers on what sorts of results you should expect.

Please do...

Let me again thank you for all your mazing and clever suggestions and for your informed inputs.

Certainly Coin Flipper 4 would have never been made had it not been for your Sterling Fellowship.

 

[jt512]

Yes...

Whether random data is biased or not is part and parcel of the randomness.

The randomness is achieved by

• random byte values
• shuffling before each run
• random offset within the random bytes for random chunk of these bytes
• repeating this before each run

The randomness is also PROVEN by actually RUNING THE APP... and seeing the results.... all they have to do is RUN THE APP.

The issue isn't randomness; it's bias. Yes, your app produces random draws. However, it produces them from a biased dataset. Hence, each run of your app (the TRNG version) is biased.

There is nothing to address... the original red herring of bias was debunked here in this post...

No, the issue of bias was not "debunked" there. That sample size is way too small to detect a bias of 0.0006.

Moreover... not a single one of those concerned guys ran the app even once... had they run the app they would see that their concerns are baseless.

Actually, I ran your TRNG app for a total of 1002 runs of 10,000 flips each (and set for no edge-landings). The outcome was a proportion of tails of 0.5003. That's exactly half-way between an unbiased value of 0.5 and the value of 0.5006 that would be expected from your script. So, the test was, unfortunately, inclusively either way.

Strange that you haven't attempted to explain why my analysis of your code is wrong.

 

[jt512]

Have you ever heard of software testing...

Yeah. It's what you should have done more of.

 

[Leumas]

I assume you mean 127. Indeed, such a set of such randomly generated would be unlikely. But, in this case we know that the set is unbalanced: it contains 8182 elements > 127 (ie, "heads," as defined by Leumas' script) and 8202 elements ≤ 127 (ie, "tails"). Hence, any random draw from it is biased in favor of tails.

Thanks for that amazing fine toothcomb nitpicking of the random data file.

Amazing interest in an app you already decreed for all (including me) useless and of no interest.

... The fact is your app is trivial. Not only does it do nothing more than illustrate a statisitical fact that has been well understood for hundreds of years, it merely implements a rudimentary random number function, which in R (the programming language I know best) requires exactly one line of code.

Your app contributes exactly nothing to our knowledge of anything. And everybody here—including you—knows it.

Nevertheless... since you already were also so CONCERNED to sift through the code with a micron sieve... let me ask you a question.

Do you now fathom why I

• shuffled (randomly) the bytes
• and offset (randomly) the chunk to be used for the one run
• and use only 10 to 10,000 maximum of all of the bytes in one run
• and repeat that for different runs

Do you understand what RANDOM means?

Note: lest you start another red herring about the PRNG used to shuffle and offset the chunk used... it has already been tried by another of the CONCERNED "we"....and all I have to say to this is... Red Herrings circular rings.

 

[Leumas]

Actually, I ran your TRNG app for a total of 1002 runs of 10,000 flips...

No you did not... prove it.

Also... do you know what RANDOM means?

And thanks for all that amazing INTEREST and CONCERN about my app which you decreed for all (including me) as worthless.

Yeah. It's what you should have done more of.

More baseless ASSUMPTIONS without a shred of ability to verify.... amazing!!!

 

[JimOfAllTrades]

I assume you mean 127. Indeed, such a set of such randomly generated would be unlikely. But, in this case we know that the set is unbalanced: it contains 8182 elements > 127 (ie, "heads," as defined by Leumas' script) and 8202 elements ≤ 127 (ie, "tails"). Hence, any random draw from it is biased in favor of tails.

I agree it looks like there will be a slight bias in the results toward tails (although I'd bet it's going to be pretty dang small). When using a random set of numbers, you're just not going to get a perfectly evenly distributed set of numbers in any subsection of the set.

Using the same set of numbers over and over (just ordered differently) means the natural unevenness of the random set doesn't average out as it would with a new set of random numbers each time. But that isn't really practical here as it would require paying for using the random number generator.

I'm no expert on generating random numbers, but what would you think of this: Make the initial string of numbers 64 zeros, then 64 ones, then 64 twos, etc. up to 64 255s. Then run the shuffle function two or more times, whatever you think was needed. I realize this wouldn't be truly random set but it would be evenly distributed. Or maybe in the end that's no different than just running the pseudo RNG.

I will say I like the Shuffle function, if only because I would have done it exactly the same way.

 

[jt512]

Thanks for that amazing fine toothcomb nitpicking of the random data file.

A responsible programmer would have said "Thank you for finding the bug in my code, so that I can fix it."

Do you now fathom why I

• shuffled (randomly) the bytes

• 
  
  Yes.
  
  

  [*]and offset (randomly) the chunk to be used for the one run

  
  No, as jsfisher and I have both already mentioned, that step seemed redundant, since the shuffle already randomly the starting point.
  
  

  [*]and use only 10 to 10,000 maximum of all of the bytes in one run
  [*] and repeat that for different runs

  
  Well, I know why you didn't use the entire dataset for each run.
  
  

  Do you understand what RANDOM means?

  
  As a biostatistician, I'm pretty sure I understand the concept as well as anyone here, probably better than most.
  
  The thing is, none of the above has any relevance as to whether the draws are biased. A sequence with a random starting point drawn from a randomly permuted dataset is still biased if that dataset is biased. Your dataset is biased. Therefore, every random sequence you draw form it is biased.
  
  Your incessant verbose, bolded, highlighted, and arbitrarily capitalized attempts to deflect the conversation away from the bias issue isn't helping you in the least. Indeed, you are just digging yourself an ever-deeper grave.

 

[Leumas]

<snip>

Wrong!!

You clearly do not know what random means.

 

[psionl0]

Please do...

Some Binomial Distribution theory:

If a Bernoulli trial with a probability of an indivdual success (heads) of 0.4994 is run 10,000 times then the mean number of heads would be 10,000 * 0.4994 = 499 and the standard deviation would be sqrt(10,000 x 0.4994 x 0.5006) = 50.

If we take the 95% confidence interval as being within 2 standard deviations of the mean then that means that we would expect 95% of all trials to have a head count of between 399 and 599 heads.

Incidentally, if the individual probability of getting a heads is 0.4994 then the probability of getting more than 5,000 heads out of 10,000 tosses is 0.44 (0.488 if the coin is fair).

So there is no way that you will detect a bias with only 10,000 tosses.

 

[jt512]

No you did not... prove it.

[imgw=800]http://jt512.dyndns.org/documents/leumas/runs1002.png[/imgw]

Maybe next time you should ask for the evidence before you accusing me of lying.

 

[jt512]

Wrong!!

You clearly do not know what random means.

Do you seriously not understand that given your track record in this thread you cannot just make assertions like that and be believed...by anybody?

 

[Leumas]

I agree it looks like there will be a slight bias in the results toward tails (although I'd bet it's going to be pretty dang small). When using a random set of numbers, you're just not going to get a perfectly evenly distributed set of numbers in any subsection of the set.

Not to mention all the shifting of the goal posts of concerns...

Using the same set of numbers over and over (just ordered differently)

I don't do that... I use a random chunk selected randomly... so it is not the same set of the numbers ordered differently.

It is a randomly selected SUBSET of the numbers ordered differently.

Besides... even if I were to download a different set of numbers for each run... there is no guarantees that the numbers will be perfectly spread.

THIS IS WHAT RANDOM means.

And all this new concern for the TRNG is just yet another red herring.

But that isn't really practical here as it would require paying for using the random number generator.

Not to mention that the new file will not have a bias either... and if one then claims that at least a new file is not the same... then they are just not able to understand what randomness means.

I'm no expert on generating random numbers, but what would you think of this: ... I realize this wouldn't be truly random set but it would be evenly distributed.

Yup... then the red herrings ring of concerns makes a full circle yet again

I will say I like the Shuffle function, if only because I would have done it exactly the same way.

I don't just shuffle... I also select a SUBSET randomly.

Claiming that there is a bias in the data can be easily verified

By....

USING THE APP and testing extensively with it.

And those tests (look up post for all the samples) PROVE that the new red herring concern about bias is utterly baseless.

But...

RUN THE APP... all those CONCERNS are done without even one run of the app.... which just proves that it is all a red herring in the first place.

 

[Leumas]

Do you seriously not understand that given your track record in this thread you cannot just make assertions like that and be believed...by anybody?

Ah... sextupling on your slander now... amazing...

The record of making assumptions and baseless slander is on your side... as proven by reading the thread.

And yet again speaking for "everybody"... I am at least glad you did not include me this time too.

 

[Leumas]

Maybe next time you should ask for the evidence before you accusing me of lying.

Thanks for proving your claim... and I stand corrected.

And... WOW... I stand in awe at your dedication to this app that you decreed as worthless to you and all and even myself too.

Apparently you are not at all thinking it is worthless.

Thanks so much for all this interest in my app... glad to have added to your knowledge.



I am not as dedicated as you... so I only had patience and finger stamina to do 502 runs.

But it is enough to demonstrate YOUR ERROR and obvious lack of understanding of the principles of randomness.

[IMGW=500]http://godisadeadbeatdad.com/CoinFlipperImages/TRNGNoBias4.png[/IMGW]​

 

[jt512]

Besides... even if I were to download a different set of numbers for each run... there is no guarantees that the numbers will be perfectly spread.

THIS IS WHAT RANDOM means.

Although you are either incapable or unwilling to understand this, the issue with making repeated draws from a fixed, finite dataset is not randomness, it's bias. Each set of integers from the online TRNG you used to get your sample is unbiased because each integer is a random draw (with replacement) from a uniform distribution on {0,1,...,253}. Therefore, if your app used a new draw from that website for each set of flips, those flips would be unbiased, because each flip would be a draw from Uniform{0,1,...,253}.

But when you hard code a single sample S of integers, and repeatedly draw from that sample, then your sample space is no longer {0,1,...,253}. It's that one finite sample S, and that sample will almost surely not be uniformly distributed. In particular, it will likely not have exactly half its values > 127. So any random sample you draw from it will be biased (in terms of heads and tails defined based on the value 127).

RUN THE APP... all those CONCERNS are done without even one run of the app.... which just proves that it is all a red herring in the first place.

So that actually is a lie. It has already been explained to you mathematically and with an actual sample of over 10 million runs that a single run of the app cannot show whether the app is biased or not

 

[Leumas]

No, as jsfisher and I have both already mentioned, that step seemed redundant, since the shuffle already randomly the starting point.

Yup proof that you do not understand the code or randomness either.

 

[jt512]

Thanks for proving your claim... and I stand corrected.

Thank you for admitting that.

And... WOW... I stand in awe at your dedication to this app that you decreed as worthless to you and all and even myself too.

I think if you were to amend your code, so that you can run, say, a billion flips with one click, reshuffling automatically every 10,000 or so, you would be able to see whether the app produces biased results or not.

But I think you can determine that just by analyzing your code.

 

[Leumas]

...
So that actually is a lie....

Thanks... for yet more false slander... your emotions and patience to repeatedly diss on the app... is all I need for a QED!!!

 

[jt512]

Yup proof that you do not understand the code or randomness either.

Yeah, for sure, among psion0, jsfisher, me, and you, it is you who has the superior understanding of randomness. But again, randomness is a red herring. It's not the issue; bias is.