• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

Moderated Coin Flipper

...
Why did you model the "edge case" as having ....


Your above post proves that you knew that the Edge landing is accounted for all along and so you knew that this is a slander...

...
So, your claim to have implemented code to model the possibility of a coin landing on its edge was a lie.

In case it isn't clear to anyone by this point, Leumas's version 2 does not allow for the possibility of an edge-landing, as he claimed.


And therefore so is this

...
You were asked a simple question. You need not answer it, of course, but then we may interpret your silence in a light that you may find unfavorable.

(I know I have.)

...
As for the claim that you were a liar, that is a conclusion derived from seeing the actual code.


And this is doubling down on your error..

No. It was not slander, nor was the statement baseless..
....
Certainly neither jt512 nor I owe you any sort of apology. On the other hand, an apology from you would be appropriate but, as history has demonstrated, unlikely.


So you admitted that you knew all along that the above is slander...

Accordingly... when you apologize for calling me a liar and slandering me I might accept your apology which you denied is even needed when you have just proven that it is most RATIONALLY and ethically necessary.


Moreover... when you say

You are belaboring the obvious. Many of us can read the Javascript just fine and understand what the instructions do.


Who is this US that you are appointed as a spokesman for?

And it is very clear that this US does not include the poster of these admissions of not being able to read and understand the code...

..
Leumas, if your version 2 app allows for an edge-landing, then your version 1 app is, incorrectly, counting edge-landings as heads. Alternatively, neither version allows for an edge-landing. Which is it?

...
If you don't answer the question I just posed, here, I'll take your silence to mean you don't know the answer. But that, itself, doesn't matter, because either way, one of your two versions is not doing what you claim.

...
Sorry, Leumas, but all you've done is write 199 lines of literal window dressing to implement a one-line program that does nothing more than illustrate the consequences of an elementary probability theorem that was proved over 300 years ago.


Nor these guys

Could you please just answer the question: how did you program the possibility of an edge-landing?

...
(But no, I don't see this has anything to do with your app.)
...

I got you Chanakya. The OP is four short paragraphs. Here's the synopsis:
...
Now tell me, what the **** are we supposed to get from that disjointed mess?
...

The only honest way to address the edge case would be insanely complicated, involving friction and wind and vibration and the plethora of other physical variables. That's the whole problem with any simulator that purports to mimic the natural world. It can't be anything more than a limited artificial approximation.

I told him as much on the first page. Got a perseveration of pusillanimous piffle for my trouble.

Thanks Olmstead. I have no idea what this topic is about.
 
Last edited:
When I did V3 having done the test I talk about in this post... I decided to do more research on the edge landing claptrap... and I found that it says that the edge landings apparently have a probability of 1 in 6000 (see here)... which I have a hard time to believe.

But also notice in that article it does say that edge landings are redone... i.e. edge landings absolutely do not need to be accounted for whatsoever.

Anyways... still wanting to carry on experimenting... in version 3, which you inspired and using the TRNs from the website you gave me, I allowed for that 1/6000 thing and I found out that there were WAYYYY TOO MANY occurrences and so I adjusted it.

Guess what... funny enough it is in fact almost what you suggested in your last post.

Now... earlier after I did V3 already... you gave an interesting suggestion (in this post) which I looked at and considered and even tried out... but it ended up giving NO edge cases at all so I examined the raw TRN given by the website and from that concluded that the possibility is indeed nil that this method would occur.

So I kept my original method which is more like the one you did in this post... so evidently educated minds think alike.

Code:
      if (Math.floor(Math.random() * 60000) == 3500 && Math.random() * 6000 == 3000.01) {
         resultE++;
      } else if (randomData[i] > 127) resultH++;
      else resultT++;


So I am using the 1/6000 but multiplying it by the probability of getting exactly 3000.01 which is offset from the middle of the random() spread... this will give a very much lower than 1/6000 which alone gives way too many edge cases which I find not credible.

Since the output of Math.random is uniform on [0,1), any subinterval thereof is a probability. So, if you want the probability of an edge landing to be p, why not just use a subinterval of [0,1) with width p to represent an edge landing, and then divide the remaining density equally to represent H and T?
 
So I am using the 1/6000 but multiplying it by the probability of getting exactly 3000.01 which is offset from the middle of the random() spread... this will give very much lower than 1/6000 which alone gives way too many edge cases which I find not credible.
One problem you have with this approach is that your edge case probability is not programmable. That is why I use
Code:
if (Math.random() < edge_probability) {}
.
 
One problem you have with this approach is that your edge case probability is not programmable. That is why I use
Code:
if (Math.random() < edge_probability) {}
.


Yes... edge landings depend on so many variables and conditions that PROGRAMMING it in would not be realistic... it is better to leave it up to RANDOM CHANCE in the app so as to better reflect the randomness of it in reality.

If I just let it be DETERMINED in the program at a set probability then I am determining it... I want it to be truly indeterministic.

;):p
 
Last edited:
Yes... edge landings depend on so many variables and conditions that PROGRAMMING it in would not be realistic... it is better to leave it up to RANDOM CHANCE in the app so as to better reflect the randomness of it in reality.

If I just let it be DETERMINED in the program at a set probability then I am determining it... I want it to be truly indeterministic.

;):p

You are giving an edge-landing a probability, namely the probability of four uniformly distributed random 32-bit signed integers summing to 0. You just have no idea what that probability is.

Not that you care about my opinion, but if for some reason I wanted to allow for an edge-landing, I would allow the user to specify its probability. But what do I, a mere statistician, know about simulating random events?

Getting back to jsfisher's question, which you conveniently ignored, why did you sum 4 random numbers in the first place? That seemed like such a bizarre thing to do that I assumed I misunderstood the `reduce` function (or method, or whatever they're called in javascript) you used to do it.
 
Last edited:


So no apology is ever forthcoming from you despite the clearly proven slander???

Ah well...

In any case... yes I do not know what I am talking about... never heard of it.

You never mentioned it... you just falsely claimed you did an amazing app that does what my app does but in one line of code although it is an INPUT into an app just like any one would input a formula into an Excel spreadsheet and does nothing even approaching what my app does.

You only started mentioning it after I researched your false claim.

And here is some information from your link above

The language took heavy inspiration from the S programming language with most S programs able to run unaltered in R[5] as well as from Scheme's lexical scoping allowing for local variables.[1] The name of the language comes from being an S language successor...


And here from the Manual For R... which says that R is an app written in S.

R can be regarded as an implementation of the S language which was developed at Bell Laboratories by Rick Becker, John Chambers and Allan Wilks, and also forms the basis of the S-Plus systems.

The evolution of the S language is characterized by four books by John Chambers and coauthors. For R, the basic reference is The New S Language: A Programming Environment for Data Analysis and Graphics by Richard A. Becker, John M. Chambers and Allan R. Wilks. The new features of the 1991 release of S are covered in Statistical Models in S edited by John M. Chambers and Trevor J. Hastie. The formal methods and classes of the methods package are based on those described in Programming with Data by John M. Chambers. See Appendix F [References], page 99, for precise references.

There are now a number of books which describe how to use R for data analysis and statistics, and documentation for S/S-Plus can typically be used with R, keeping the differences between
the S implementations in mind. See Section “What documentation exists for R?” in The R statistical system FAQ.
 
Last edited:
You are giving an edge-landing a probability, namely the probability of four uniformly distributed random 32-bit signed integers summing to 0. You just have no idea what that probability is.

Not that you care about my opinion, but if for some reason I wanted to allow for an edge-landing, I would allow the user to specify its probability. But what do I, a mere statistician, know about simulating random events?

Getting back to jsfisher's question, which you conveniently ignored, why did you sum 4 random numbers in the first place? That seemed like such a bizarre thing to do that I assumed I misunderstood the `reduce` function (or method, or whatever they're called in javascript) you used to do it.


Why are you still CONCERNED so much about my worthless useless app that contributed nothing to your knowledge or any of the US you and jsfisher keep talking about?

You go ahead and write another line of INPUT in your R/S app and see if you can make V2 of your amazing app of now 2 lines of code as opposed to my worthless useless meaningless 200 lines of literal window dressing... and see if you can allow for edge cases... and then let the US play with it since they clearly as you stated did not learn anything from my worthless useless meaningless window dressing bloated app.
 
Last edited:
So no apology is ever forthcoming from you despite the clearly proven slander???

Ah well...

In any case... yes I do not know what I am talking about... never heard of it.

You never mentioned it... you just falsely claimed you did an amazing app that does what my app does but in one line of code although it is an INPUT into an app just like any one would input a formula into an Excel spreadsheet and does nothing even approaching what my app does.

You only started mentioning it after I researched your false claim.

And here is some information from your link above

And here from the Manual For R... which says that R is an app written in S.

No, that says neither that R is an "app" nor that R is written in S. R is written primarily in C. The R language was based on the S language; it was basically an open source fork of S. S, however, is now essentially a defunct language, but S codes survive, and R tries to be compatible with S so that those codes will still run.
 
No, that says neither that R is an "app" nor that R is written in S. R is written primarily in C. The R language was based on the S language; it was basically an open source fork of S. S, however, is now essentially a defunct language, but S codes survive, and R tries to be compatible with S so that those codes will still run.


Wonderful... now go make your one line of code account for Edge landing... just like you kept commanding that my worthless useless window dressing app do... and also to have a GOOD PRNG instead of as you falsely claimed my app does not....

Therefore, I am going to assume, as I suspected, that your version 2 app does not allow for an edge landing; rather, it, like your version 1 app, just uses a canned bernoulli (pseudo) random number generator. Worse yet, I don't think you actually understand that your own app can't simulate an edge-landing, which is, actually, pretty sad.


Although you said you had my code with a click and you could have found out that all what you said above was false and slander.

Nevertheless... your 1 line of input into R/S is in fact "just uses a canned bernoulli (pseudo) random number generator" and does not even begin to account for an Edge case.... but you still think it is better than my worthless app.

And now you are so CONCERNED to give me "suggestions" for the worthless app that contributed nothing to your knowledge... why?

Why don't you apply those "suggestions" to your amazing "app".
 
Why are you still CONCERNED so much about my worthless useless app that contributed nothing to your knowledge or any of the US you and jsfisher keep talking about?

As usual, you dodge simple questions. Besides the two you previously dodged, you now have twice dodged the simple question, "Why did you sum 4 perfectly good uniformly distributed random variables?" What's the matter, can't you defend your programming choices?

You go ahead and write another line of INPUT in your R/S app and see if you can make V2 of your amazing app of now 2 lines of code as opposed to my worthless useless meaningless 200 lines of literal window dressing... and see if you can allow for edge cases... and then let the US play with it since they clearly as you stated did not learn anything from my worthless useless meaningless window dressing bloated app.

Although I have only a vague idea of what the above word salad is supposed to mean, I gather you are wondering if I can write coin-flipping code in R that would allow for edge cases. If that is, indeed, what you are asking, the answer is yes: I can write such a code, and, in fact, do it in one line in R, although to be honest, it would better coding style to use about 4 lines to do it.

Here it is in one line:

Code:
rowSums(rmultinom(n=1e6, 1, c(p.edge=1e-5, p.head <- (1-p.edge)/2, p.head)))

That is valid R code, but it's not exactly self-documenting. Better to do it like this:

Code:
p.edge <- 1e-5
p.head <- (1 - p.edge) / 2
p.tail <- p.head
rowSums(rmultinom(n=1e6, 1, c(p.edge, p.head, p.tail)))

Example output:
Code:
 8 499407 500585
 
Yes... edge landings depend on so many variables and conditions that PROGRAMMING it in would not be realistic... it is better to leave it up to RANDOM CHANCE in the app so as to better reflect the randomness of it in reality.

If I just let it be DETERMINED in the program at a set probability then I am determining it... I want it to be truly indeterministic.

;):p
The process doesn't become indeterministic just because you haven't calculated the probability of an event occurring. There is still a fixed probability of an edge landing even if you haven't calculated it.

I still believe it is better to have a programmable edge probability so that your app can meet anybody's edge probability preference.
 
The process doesn't become indeterministic just because you haven't calculated the probability of an event occurring. There is still a fixed probability of an edge landing even if you haven't calculated it.

I still believe it is better to have a programmable edge probability so that your app can meet anybody's edge probability preference.

You put that so much more calmly than I did:

You are giving an edge-landing a probability, namely the probability of four uniformly distributed random 32-bit signed integers summing to 0. You just have no idea what that probability is.

Not that you care about my opinion, but if for some reason I wanted to allow for an edge-landing, I would allow the user to specify its probability. But what do I, a mere statistician, know about simulating random events?

I must learn from your zen.
 
Although I have only a vague idea of what the above word salad is supposed to mean, I gather you are wondering if I can write coin-flipping code in R that would allow for edge cases. If that is, indeed, what you are asking, the answer is yes: I can write such a code, and, in fact, do it in one line in R, although to be honest, it would better coding style to use about 4 lines to do it.

Here it is in one line:



Nope... you are still not doing the dynamics of a physical coin...

The only honest way to address the edge case would be insanely complicated, involving friction and wind and vibration and the plethora of other physical variables. That's the whole problem with any simulator that purports to mimic the natural world. It can't be anything more than a limited artificial approximation.

... insomuch as it eschews simulating a physical coin entirely.

...trials speak to the quality of the generator he is using and nothing at all to how coins behave.

... we shouldn't be fooled into thinking it's an accurate description of the underlying physics that produce probabilistic binary results in some natural system.



Nor are you using a good PRNG let alone a TRNG...

...
The quality of those simulations are intimately tied to the quality of the underlying model and also the pseudorandom number generator function upon which it relies.

Are you trying to say anything other than, anything more than that?

... if you are not using the built in a cryptographically secure Javascript [R/S] random number generator or you are not an expert on random number generation algorithms, there are almost certainly biases in you coin flipping method.




Unless you give me the code of the R/S app ...

...
...without seeing the generator, you could have made an app that outputs percentages that are closer to 50/50 as trial sizes are increased, and has nothing whatsoever to do with actual coin flipping odds. It may simply be a program which will never read 50%, but always a small percentage off.

Well, that is a bit of an overstatement (multiple in fact).

... The question was about logic and reasoning that went into your model. Someone's code is usually an awful way to derive someone's logic and reasoning going into model construction....

... I am interested in the "why" not the "how".


Why did you model the "edge case" as having a probability of something like 1 in 4 billion 10,000? That looks like just a wild-ass guess with no basis whatsoever.

What insight do you believe your application provides that wasn't already provided and predicted by simple statistics?



And since no one can even run it

....
it is more excruciatingly boring than watching paint dry and gives no new information nor provides any interesting results.

...implement a one-line program that does nothing more than illustrate the consequences of an elementary probability theorem that was proved over 300 years ago.

... 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.
 
Last edited:
The process doesn't become indeterministic just because you haven't calculated the probability of an event occurring. There is still a fixed probability of an edge landing even if you haven't calculated it.

I still believe it is better to have a programmable edge probability so that your app can meet anybody's edge probability preference.


Ok... but why would this be of any value at all.... I think the best thing is to do what casinos do... eliminate the edge landing altogether.

No??

I think I will just nip this red herring in the gills and remove it altogether.

Thanks for the suggestion.
:thumbsup:

ETA: Done!! No more Edge mephitic red herrings wafting about.
 
Last edited:
Please stop the bickering and return to the topic of the thread.
Replying to this modbox in thread will be off topic  Posted By: zooterkin
 
The process doesn't become indeterministic just because you haven't calculated the probability of an event occurring. There is still a fixed probability of an edge landing even if you haven't calculated it.

I still believe it is better to have a programmable edge probability so that your app can meet anybody's edge probability preference.


Actually... on second thought... I am wrong.... I will do exactly what you suggested... it will make my "worthless useless" app even better.

Thanks yet again for a GREAT FEEDBACK... you are proven yet again to be a STERLING FELLOW.
:th:

I will do the new version V4 asap...

ETA: I think I will make V4 also allow the user to choose between the normal PRNG or the Crypto one or the TRNG as well as allow for input as to what probability for an edge landing they want just like you said.

ETAA: But I am not happy... I was going to play a few hours of Sniper Elite 4... now I have to work on this red herring to make it a Red Cardinal instead (not the Vatican kind).
 
Last edited:
Why are you using a pseudorandom (i.e. deterministic) model to make a claim that you cannot accurately predict the outcome of at least some random processes if they are not nonlinear and with sufficiently large numbers of events?

You are using a computer where every bit involves an nMOS and a pMOS FET switching in opposite directions. Every electron that is carryingcurrent in the microprocessor is doing so because of a truly random quantum event. In addition there are Alpha particles and cosmic rays that can flip individual transistors and cause so-called "soft errors". Thermal noise is also truly random.


And the actual semiconductor p and n regions that make up the p-n junctions that a make up the transistors in the microprocessor are also manufactured by processes that are again perturbed by random events, and in fact with small gate lengths, these are getting to be important for the functioning of the transistors as they contain so few doping atoms.

Yet, despite this, the inherent[ETA designed-in] error correction means that we know that what we type is what we see on the screen.

Also, we can have very sensitive pressure gauges but, Brownian motion is not just unpredictable but also truly random.


Now, there are systems where this predictability does not apply, and I would argue that the course of evolution is indeed one, where the entire fitness landscape can be significantly altered by truly random events and it is only predictable in a stable fitness landscape.

But that's not the discussion here.
 
Last edited:
After I got finished wiping away the tears after reading the recent mod box and it's meta riddle of the sphinx Sisyphusean sick joke instruction, it occurs to me:

Leumas, you are complaining across two threads about your perceived mistreatment. But you seem happy as a pig in **** to discuss simple coding. After all these pages, is that what you actually wanted to talk about? If so,why all the bobbing and weaving and an OP that didn't mention coding at all?
 
...
I still believe it is better to have a programmable edge probability so that your app can meet anybody's edge probability preference.


Ok... your wishes have been fulfilled.

Coin Flipper V4
  • allows choosing the RNG
  • allows setting the Edge probability 1= no Edge case to 1/10,000,000,000... defaults to 1/6,000
  • from 10 to 10,000,000 coin flips can be done in one go... to do more just go again
  • Except on the TRNG only 10 to 10,000 flips at a time.


[IMGW=400]http://GodIsADeadbeatDad.com/CoinFlipper4/images/pseudo.png[/IMGW] [IMGW=406]http://GodIsADeadbeatDad.com/CoinFlipper4/images/crypto.png[/IMGW]

[IMGW=400]http://GodIsADeadbeatDad.com/CoinFlipper4/images/true.png[/IMGW]
 

Back
Top Bottom