|
Post by tsh73 on Dec 2, 2019 11:03:59 GMT
'always bet tails 'if t$="H" then s2=s2+1 else s2=s2-1 'obviously should be if t$="T" then s2=s2+1 else s2=s2-1
Also "'bet the opposite" looks like "'bet just like previous" to me.
|
|
|
Post by Rod on Dec 2, 2019 16:43:01 GMT
Corrected, but there still must be something wrong as bet the same is still winning?
bias=.002976 for n= 1 to 100000 if (rnd(0)+bias>.5) then t$="H" else t$="T" if t$="H" then heads=heads+1 else tails=tails+1 seq$=right$(seq$,2)+t$ 'print t$,seq$
'always bet heads if t$="H" then s1=s1+1 else s1=s1-1
'always bet tails if t$="T" then s2=s2+1 else s2=s2-1
'bet the same as last thrown if mid$(seq$,2,1)=t$ then s3=s3+1 else s3=s3-1
'bet the opposite of last thrown if mid$(seq$,2,1)<>t$ then s4=s4+1 else s4=s4-1
next print "Heads thrown ";heads print "Tails thrown ";tails print "Always bet heads ";s1 print "Always bet tails ";s2 print "Bet the same ";s3 print "Bet the opposite ";s4
|
|
|
Post by tenochtitlanuk on Dec 3, 2019 20:55:20 GMT
Perhaps off-topic. LB5 ( 350, latest alpha of the new LB) gave me
0.50004 were singlets, 0.49996 were repeats of two or more, in 100000000 throws
single =0 ntuple =0 prev =int( 2 *rnd( 1)) for i =1 to 1e8 b =int( 2 *rnd( 1)) if b =prev then ntuple =ntuple +1 else single =single +1 end if prev =b
if i mod 1e6 =0 then print using( "#.#####", single /i), using( "#.#####", ntuple /i), i
scan
next i
end
|
|
|
Post by B+ on Dec 4, 2019 17:38:53 GMT
Here is another fix for RND(0) Rod's test ain't so boringly predictable any more!
'counting 01s from perm n = 10 B+ 2019-12-04 or flipping coins 10 at a time
dim perm10$(1023) ' there are 1024 perms of 10 coin flips 'load perm10$ for perm = 0 to 1023 scan 'systematically create a sequence of 0s, 1sn of nlength perm10$(perm) = right$(string$("0", 10); base2$(perm), 10) next
while 1 scan ' string together 10,000 rnd picks of perms10$ for i = 1 to 10000 r = int(1024 * rnd(0)) if i mod 2 then r = 1023 - r ' in case lower numbers favored by rnd(0) ht$ = ht$ + perm10$(r) next 'print len(ht$), mid$(ht$, 100000, 1) 'looks OK
'run Rod's test on ht$ the long string of 01's for n= 1 to 100000 scan t$ = mid$(ht$, n, 1) if t$="1" then heads=heads+1 else tails=tails+1 seq$=right$(seq$,2)+t$ 'print t$,seq$
'always bet heads if t$="1" then s1=s1+1 else s1=s1-1
'always bet tails if t$="0" then s2=s2+1 else s2=s2-1
'bet the same as last thrown if mid$(seq$,2,1)=t$ then s3=s3+1 else s3=s3-1
'bet the opposite of last thrown if mid$(seq$,2,1)<>t$ then s4=s4+1 else s4=s4-1 next print "Heads thrown ";heads print "Tails thrown ";tails print "Always bet heads ";s1 print "Always bet tails ";s2 print "Bet the same ";s3 print "Bet the opposite ";s4 print heads = 0: tails = 0: s1 = 0: s2 = 0: s3 = 0: s4 = 0: ht$ = "" wend
'this one does not do set limit function base2$(integer) while 2 ^ j <= integer if (integer and 2^j) > 0 then b$ = "1" + b$ else b$ = "0" + b$ j = j + 1 wend base2$ = b$ end function
function string$(char$, ntimes) while n <= ntimes string$ = string$ + char$ n = n + 1 wend end function
|
|
|
Post by B+ on Dec 5, 2019 15:58:56 GMT
Oops! I was calling all the possible arrangements of 10 Heads or Tails, 0's or 1's, "permutations" sorry wrong word.
|
|
|
Post by B+ on Dec 7, 2019 17:13:32 GMT
This method appears to completely fix Davey's original post problem and overcome JB's bias rnd(0):
'Revisit Davey's original code post with "fixed" random generation ' using B+ flipping coins 10 at a time 2019-12-07
dim s10$(1023) ' there are 1024 outcomes of equal probability of 10 coin flips 'load s10$ for i = 0 to 1023 scan 'systematically create a sequence of 0s, 1sn of nlength s10$(i) = right$(string$("0", 10); base2$(i), 10) next
'OK let's try Davey's original post code, and see if total continues to increase ' or specially if B = ... makes such a difference anymore???
'test top in multiples of 10, min of 10, so try top at: 10, 100, 1000, 10000, 100000... top = 10000 'top = 10000 is Davey's original test DIM N(top) FOR A = 1 TO 20 '<<<<<<<<<<<< 20 test samples >>>>>>>>>>>> this is really too tiny sample 'create string of 0's and 1's of length 10,000 ht$ = "" for i = 1 to top/10 scan r = int(rnd(0) * 1024) 'B = rnd(0) '<<<<<<<<<<<<<<<< this should be the equivalent of throwing out every other rnd ' Does it make a difference? I can't tell? which is the right answer!!! =fixed! ht$ = ht$ + s10$(r) next
FOR X=1 TO top scan N(X) = val(mid$(ht$, X, 1)) 'B = INT(RND(1)*2) '<<<<<<<<<<<< does this line still make such a difference???? of course not! NEXT X FOR X= 2 TO top -1 scan IF N(X-1)<>N(X) AND N(X)=N(X+1) THEN TOTAL=TOTAL+1 IF N(X-1)<>N(X) AND N(X)<>N(X+1) THEN TOTAL=TOTAL-1 REM LOOK FOR THE START OF A SERIES, THEN COUNT HOW MANY MORE SERIES >1 THERE ARE. NEXT X PRINT TOTAL NEXT A print "Test is done."
'this one does not do set limit function base2$(integer) while 2 ^ j <= integer if (integer and 2^j) > 0 then b$ = "1" + b$ else b$ = "0" + b$ j = j + 1 wend base2$ = b$ end function
function string$(char$, ntimes) while n <= ntimes string$ = string$ + char$ n = n + 1 wend end function
|
|
|
Post by daveylibra on Dec 12, 2019 13:16:36 GMT
Hi B+ !
I am just trying to analyse the above program, which as you say seems to fix a bias rnd. But I don't mind admitting it is quite difficult for me to see how you did this, without calling a different random generator. I am not sure why there was a bias in the first place, or why the extra rnd made a difference, and as I think I said before, adding the extra rnd seems like an economical way to "randomize" the results.
More interesting to me is WHY S1 > ( S2+S3+S4+...) as a mathematical fact. Is it because the beginning and end of the "series" are more likely to be S1? To my mind, without being able to find proof, they are equally likely to be S2 or more.
|
|
|
Post by B+ on Dec 12, 2019 14:46:25 GMT
Hi Davey,
Let's see if I can describe what I did without code: I created a listing of all the outcomes possible of tossing a coin ten times in a row, each of equal probability. That is 2 ^ 10 possible states of HT sequences or 0's and 1's. Then I used rnd(0) to select one of those outcomes and added the sequence of 10 to build a sequence of 100 or 1000 or 10,000... so even if rnd(0) is off the sequence of HT or 01s will remain 'balanced' choice within the 10 in the sequence.
I am seeing the advantage of S1 > than sum of all the others as very, very small and as you say, diminishing as the length of sequence increases, to such a point that I think learning math and coding a much better investment of your time than betting on S1 even if you can find any takers! Vegas would never get built with such a tiny advantage. ;-))
|
|
|
Post by tenochtitlanuk on Dec 12, 2019 17:36:07 GMT
For me, the flawed JB/LB4rnd() is useable for 99.99% of cases. I'm a scientist- most everyday measurements are less than 4 significant figures. And a huge bugbear for scientists is a 'fudge factor' added to a calculation so the expected result is obtained. Don't add a fudge- find why the results are not what you expected! Almost ANY algorithm for a Programmable Random Number Generator ( PRNG) has flaws. The flaws can include - uneven frequency of values called ( eg our LB/JB gives slightly too many low values). Shows in histogram plots and chi-squared analysis and counting, but becomes complicated to pin down. Humans are distracted by the pattern they recognise and draw unwarranted conclusions. "ABCDEFGHI....WXYZ" is as likely as "ABCDEFGHI....WXYZ" or "AKGYIHN....UBF" or "AAABBB.....ZZZ" , - equal frequency of results, but coming in a predictable order. IF I simply select over,and over, in turn, the letters of the alphabet,the histogram is spot on- and in some circumstances such a biassed generator is still useful. - next number is related to the present one- or even longer correlations. This results in interesting diagonal lines appearing if you plot successive numbers paired wth the previous one. I you look at my relevant programs you'll see two very bad PRNGs doing exactly that. Metods of massaging existing RND() by shufflig the order you use terms, or discarding a dummy value between each call are angling to improve such cases. If you want to get further into randoms, you could move to LB5 ( the rnd() there is MUCH faster and much less biassed. You could move to LB4 and call the excellent Mersenne Twister. Both moves would cost you nothing, 'though I'd encourage you to pay for the licence. Then you could concentrate on statistically checking very long runs, too. You can also download from online web random generators, and save and use as a text file. The RAND corporation created such a paper table in the earliest computer days.( In LB you could do this within the program). These are usually TRUE RNGs, ie they gather randomness/entropy from physical things like random radio background of the universe. Or you can buy or make an electronic device. I made 'switchtail shift registers" back in the earliest transistor days. Other devices use shot noise in a silicon diode, or random wifi signals at your workstation. The graphic shows LB/JB's present rnd being called repeatedly. Each pixel increments if the new and previous rnds are taken as its x,y coordinates. Pixels start black. First hit makes them dark blue. Successive hits move them from blue towards red. Once one pixel has reached 255 it goes white and I stop. Of course this is an animated GIF of the results.
|
|
|
Post by daveylibra on Dec 13, 2019 22:49:23 GMT
Ran runs of one million productions of 0/1, and checked for what I think of as 1-tuples ( ie changes on next char), 2-tuples, 3-tuples, etc. Get close to expected ratios etc- but even one million is still fluctuating, of course. Screen grabs show the JB one calling rnd(), and the LB one calling the Mersenne Twister dll. By rem/unremming you can run either version. The dll is on my site- and elsewhere. Hi, visited your website - diga.me.uk - but cannot find the relevant dll or figure out how to use it to run your program? The Mersenne Twister is interesting though - it gives the results I expected for S1. ( To me, testing for randomness seems counter-intuitive, as random can produce anything, so sequences that do not pass tests would not qualify even though random could throw them up.) But more to the point of my whole reason for starting this : The equation S1 > ( S2 +S3 + S4 +... ) will give only a very small bias to S1, and when testing, may not even show up. But, is it a valid statement to say - "given any sequence of coin flips, there is a greater likelihood of S1 outnumbering any other sequence." We need not worry about tests, just actual mathematical proof. If so, our sequence could start at any point. We could therefore wait for the first S2 or more and then bet after every "switch." I hope this is explained clearly!
|
|
|
Post by daveylibra on Dec 13, 2019 23:18:30 GMT
Hi Davey, I am seeing the advantage of S1 > than sum of all the others as very, very small and as you say, diminishing as the length of sequence increases, to such a point that I think learning math and coding a much better investment of your time than betting on S1 even if you can find any takers! Vegas would never get built with such a tiny advantage. ;-)) Hi, I found something relevant in a book called "Innumeracy" by John Allen Paulos. In a section where he discussed coin flips, he points out that as the number of flips increases, the ratio H to T becomes closer to 50/50. BUT, it terms of absolute numbers, the difference between H and T tends to get bigger as n increases. And the changes in lead from H to T and vice versa tend to become increasingly rare. I think this also applies to our sequences. He also describes a computer printout of Xs and Os, each probability 1/2. He says "note the number of runs and the way there seems to be clumps and patterns. If we felt compelled to account for these, we would have to invent explanations that would of necessity be inherently false. Studies have been done in which experts in a given field have analysed such random phenomena and come up with cogent 'explanations' for the patterns." But I think it is explained by simple probability - there are more ways for these type of sequences to form than more uniform ones. Anyway, as you say the advantage of S1 is always very small and this is only theoretical! May I repeat what I said in my previous post? - The equation S1 > ( S2 +S3 + S4 +... ) will give only a very small bias to S1, and when testing, may not even show up. But, is it a valid statement to say - "given any sequence of coin flips, there is a greater likelihood of S1 outnumbering any other sequence." We need not worry about tests, just actual mathematical proof. If so, our sequence could start at any point. We could therefore wait for the first S2 or more and then bet after every "switch." ie wait for at least HH or TT then bet after any HT or TH. I am looking to find some way of mathematically proving this rather than going to Vegas!
|
|
|
Post by B+ on Dec 14, 2019 0:27:28 GMT
Talk about patterns arising out of random clusters, I see the devils face in John's gif as the blue dots turn to red. ;-))
John Allen Paulos did a chapter on how order can arise out of chaos. He showed how this could happen with cards that would be nice to see programmed in JB. I don't know if it was in his book Innumeracy or another but that demo really stood out in my past readings.
|
|
|
Post by tenochtitlanuk on Dec 14, 2019 12:08:16 GMT
Using dll's is so easy in LB- see the Help file entry. We were lucky Chris Iverson wrote the Mersenne Twister dll for us. See Alyce's Restaurant alycesrestaurant.com/lbpe/rndrandomize.htmlOn my site www.diga.me.uk/MarsTwistLB.dllJust download/extract to the same directory as your JB/LB program is in. Un-rem the lines in my code that were remmed out for use in LB. Oh, and, B+, I've always been able to imagine things that are not really there. Rorshasch pictures, etc- and of course Magic Eye 3D pictures, as coded on my site!
|
|
casco
New Member
Posts: 16
|
Post by casco on Jan 23, 2020 9:47:27 GMT
We were lucky Chris Iverson wrote the Mersenne Twister dll for us. There is no need for Mersenne Twister. I bemuse myself with various random models and was very unhappy to find out years ago that JB RNG had a noticeable bias. So I looked into the behavior of the problem and found out that the RND function preferred larger values. Whenever I generated set of integers from 0 to 9, the result flunked every chi-square tests I put on it, but that was always due to the fact that the distribution of the integers was repeatedly skewed toward higher values being less frequent in the statistically significant manner. Seeing that, I applied simple remedy of taking the first digit after the decimal point out of the picture. For example, if RND(1) returns 0.628251, then you purge 6 to get 0.28251. Here is the short adjustment function I have been using ever since: function rand() r=10*rnd(1) rand=r-int(r) end function I ran lots of different tests, but the adjustment effect proved invincible. Try it for yourself to see...
|
|
|
Post by Rod on Jan 23, 2020 12:15:24 GMT
Now thats pretty cool, a remarkably easy fix. Thanks for sharing. I still value Chris though!
|
|