No, it does not exclude that possibility (print the final list of pairs if you want to check). The calculation is correct. The result is counter-intuitive to almost everyone, which is why I made the program, so you can convince yourself.
Your program counts possibility # 2 and 16 only once, because at first glance they are identical. But they are not, because each child has independent probability. This is why models that graph this information on a grid also fail to get the right answer. The above probability table gives you the proper result of 14/28, or 1/2.
Try something easier, for example two dice. The probability to roll 1 1 is less than to roll 1 2, because 1 2 can be rolled either by first rolling a 1 or a 2, while 1 1 can be rolled only by first rolling a 1. That information is used often in dice games like backgammon.
Same with children: BT BT can only be "rolled" if your first child is BT, whil BT BW can be "rolled" if your first child is either BT or BW.
The probability that you will roll 1 1 is indeed less then rolling 1 2 or 2 1, but that's only because you are allowing for twice as many acceptable outcomes.
The Wiki article you reference in your own code explains it well. The problem is in the assumptions made by the person answering a riddle. Just because you have a child, and it's a boy, and he is born on Tuesday, it does not mean that your next child is more likely to be a girl. If you agree with that statement, then the original answer must be false.
The wiki article is not valid, since it considers a subtly different problem than the one I do. If you read the comment at the top of the code, you will see that I changed the question to be less ambiguous.
In the problem I pose, the person does not randomly come forward and tell me "I have a boy born on a tuesday". In my problem I ask random people who I know have two children if they have "at least on boy born on a tuesday" until someone says yes.
Wow, works good. I should learn python :) But yeah, you were absolutely right! It was hard for me to figure out because I was trying to find a mathematical reason for this, and I was wrong. I finally figured it out mathematically. The way you posit the problem the probability that the asked parents have another boy is (1/2)-(1/7/2).
This is really counter intuitive, the open vs. closed probability set through me off. Hey, thanks for putting up with my stubbornness!
I have a fundamental issue with bitcoins that I have not seen anyone address. Sooner or later a better bitcoin will be invented. One that can perform transactions faster, or is more anonymous or where mining for the coin helps some nice project (SETI@home, math proofs, protein folding, etc), or something completely different. When an alternative better currency catches on, at some point it will become obvious that bitcoins will be obsolete and the value should suddenly be 0 again.
It is the nature of technology that bitcoins will someday become MySpace.
I am open to be convinced otherwise by someone knowledgeable.
Not always the best technology is the one which success. If that better bitcoin is invented too late, bitcoin can have a large infrastructure and accepted by a large proportion of merchant to be switched. Just think about VHS and Beta or OS/2
I plan to sneak in something similar with a capable type system and contracts for stuff that you can't express in the types. That way you could "one day" use a solver like Z3 and start proving or disproving some of the tractable contracts, without having to even change the programs. A bit like LiquidHaskell.
Not exactly dependent types, but practical, I think.
I do like an expressive high-level encoding like that, but 1) I just needed a silly example to show what pipes are. In practice you would probably use higher-order library functions (or components) like group for the same thing. 2) In my experience, very compressed expressions can be hard to modify in certain directions. Practical stuff like printing, logging or storing progress every X seconds, which is a small modification in a for-loop, can be a hassle.