Maximum Deck Size

[Greg the Yeti]

Hi,
It's a long time since I've contributed here but I've been happily using Orphalese and recommending it to friends!

I have found out that Orphalese will not shuffle beyond 256 cards in a deck.

I have been using a Deck with 256 cards for some time to simulate as closely as possible the I Ching "Yarrow Stalk" Odds. As far as I can see it IS correctly shuffling a Deck of this size - but no further!

I have checked the Odds that Books on the subject gave for the Yarrow Stalk method and found that they had got it wrong. I did do an A level in Maths and am very familiar with Spreadsheets (among other things) so I used one to plot every single possible move in the Yarrow Stalk method of choosing a Hexagram. The odds came out quite different to what the books said. They may be historians and Linguists but it seems they aren't very good at either Maths or Logic!

I wanted to model these new more correct Odds within Orphalese so I decided to double up the size of my Deck to allow more precision. In particular I wanted to have more than 6 sixes, since it should be possible to have a Hexagram with 6x sixes! With only 6 x sixes in the Deack it does warp the Odds for this very unusual Draw. So I created the Deck with 512 cards.

When I shuffled it in Orphalese I could see that something was not working correctly and checked. It was only shuffling up to about half way into the Deck. On counting the unshuffled cards at the end of the Deck (using F4) it seemed that the division is exactly at half way 256 - a power of 2 and therefore a likely division in a computer program.

If it is possible in a future version it would be nice if this shuffling limit could be extended either to 512 or even better to 1024.

Yes with 256 cards it does slow down shuffling, bacause some of the cards are displayed during the shuffle as a kind of "progress bar". The file size of my cards is small at 3.54 kb but it does take 15 or 20 seconds. I would be willing to double this or even quadruple this to have a better modelling of the Yarrow Stalk Odds.

I have another suggestion to speed up Shuffling for any Deck with either a lot of cards or highly detailed cards for better viewing when the picture is important. Since you shouldn't really be able to see the shuffled cards anyway, and this is really only a glorified "progress bar", why not just select any two early cards in the Deck (at random - although it would be faster if this were fixed) then simply alternate them to give the "progress bar"

I have now gone back to a 256 sized Deck, reflecting the correct Odds (and with only 6 x sixes!)
My first reading with it seemed stunningly accurate! Wow!

Thanks for a great program!
Regards Greg the Yeti

------------------------------------------------------------------------

If anyone is interested the Odds I calculated, here they are.
6:- 0.0232863
7:- 0.2733648
8:- 0.4813379
9:- 0.222011

8+6 = 0.5046242
7+9 = 0.4953758
So it ISN'T equally likely to get a Yin or a Yang!

My statistics do NOT include the human operator influence:- When I do Yarrow Stalks for real I have a tendency to divide the piles about 1/3 - 2/3. For me I would need to program in a typical Bell Shaped probability distribution curve, centering around that 1/3 division. Other "operators" would behave differently and require a different probability distribution curve. The Odds above assume equal probability for each way of dividing the piles of sticks.

[Greg the Yeti]

Sorry Folks I have found a small error in my spreadsheet. Correcting this does bring me closer to the traditionally touted odds by all the books on the subject, but not quite. Everybody can make mistakes, but they (the one's with a name to loose) are very unlikely to admit a mistake!

My adjusted Odds for the Yarrow Stalk Method are now
0.04776 for a 6
0.27831 for a 7
0.45191 for an 8
0.22201 for a 9

as opposed to the Odds stated by all the books
0.0625 for a 6 ie 1/16
0.3125 for a 7 ie 5/16
0.4375 for an 8 ie 7/16
0.1875 for a 9 ie 3/16

I still haven't done the additional work to include the User preferences. I'll save that one for when I'm feeling particularly analy retentive! - It's going to be a lot of work.

I looked at why my odds differ from theirs and there IS a significant reason. Their Odds are based upon a hidden assumption that they only bother to include the center of the range of possibilities.

(There is no rule about what constitutes a "Pile" in any account of the method that I have seen! I used the all inclusive "A Pile must have at least one Stalk in it" so as not to be warping the Stats in any way. It IS possible in dividing a group of Stalks to end up with only one in one hand. If you exclude this possibility then you may be "Not Listening" to the Oracle!)

However in order not to be fiddling the Stats they must remove an equal number from both ends of the spectrum of possibilities.

They must logically exclude either right or left hand including so many Yarrow Stalks. They cannot say "The left hand must have at least two but the right hand has to have three".

BUT they must also leave an even number of possibilities - to get their Odds.

The number of Yarrow Sticks used in stages 2 and 3 of the Yarrow Stalk Method leaves an Odd number of Yarrow Stalks in both hands and therefore it is a mathematical impossibility for their Odds to be correct. Check it and see!

They made an Invalid assumption!

I believe that their Odds may actually be a 'Target' towards which my Odds will tend to get closer when I do do those Anally Retentive statistics about how an individual manipulates the Stalks. But I am now certain that however close is not precise enough for me. They "approximated" based on assumptions which were not valid. I'm not prepared to base anything upon such a shady basis!

Accuracy and Honesty is all! And that's why I have owned up to my smaller typographical mistake in a spreadsheet.

Regards Greg the Yeti

[Programmer]

Hi Greg,

Thanks for sharing this. I don't know anything at all about the I Ching but I know that other users have discussed it at various times.

I was a bit surprised about the shuffling, but I took a look at the code and I can see you are right. Actuallly the program used to shuffle any number of cards more or less well (the smaller the deck the more thorough the shuffling), but a few years ago there was quite a long discussion in here about the quality of the random numbers that the program was using and after that I switched from using the normal Rand function to using a Cryptographic class. But now I realise I only provided this class with a single byte to work from, so I effectively limited the cards that could get swapped to the first 256 in a deck.

So well spotted, and you will be pleased to know that I have fixed it now by randomising two bytes and then using their product, so it should work fine (until someone comes up with a deck containing more than 65536 cards anyway). I am not sure when the next update to the program will be, but when it does it will include this fix which is already coded.

Cheers,
Richard