You know, If someone told me they had two children and one of them was a boy and it turned out both of them were boys, I'd consider that lying to. But this is a puzzle. We are trying to figure out the likely hood of the other child is a boy. Therefore common English/courtesy/straightforwardness does not apply. And so I wouldn't assume that the other child couldn't be born on a Tuesday.

If I already have a boy, and I'm having another child which I don't yet know the gender, the chances of it being a boy are 50/50. This is essentially the situation described: guess the gender of one person.

I'm saying that IF you want to consider the order that the children are born in, and that order is unknown, we get the following pattern:

known-gender-male unknown-gender
unknown-gender known-gender-male

Plug your possible values into the above template and you get:

known-gender-male male?
male? known-gender-male
known-gender-male female?
female? known-gender-male

If your going to count the known male twice in one scenario (a know male and a female) why wouldn't you count it twice in the other (a known male and a male).

You really have to be careful to be consistent. Either order matters or it doesn't.

If no order matters, it male-male vs male- female. Other wise it's known-male-female and female-known-male vs known-male-male and male-known-male. You can't half ass it. It's one or the other.

Counting properly is important. We already *know* that one gender is male, and your over counting it when you tally your total. You are considering order when one child is female in 'WHERE gender1 = male OR gender2 = male', but not when both are males.

If you want to make the claim that it's not the birth order that makes it interesting, then don't make it interesting.

We know one child is male. We don't know the others gender. This gives us:

10
11

Query that and you'll get 1/2.

Your query isn't wrong, your data is.

The article first went off the rails when considering the order the children were born in. You can do that, but you have to do it right. They came up with the answer 1/3. I get 2/4. Here's how to do it properly: Label the child we know to be a boy as A. The child without a known gender is B.

Boy-A Boy-B
Boy-A Girl-B
Boy-B Boy-A
Girl-B Boy-A

2/4 = 1/2 as initial intuition expects. Math works as long as you break down the problem correctly, if you don't, you get funny answers like 1/3.

Now let's do the day of the week thing with the boy being born first on Tuesday:

Boy-A Girl-B-S
Boy-A Girl-B-M
Boy-A Girl-B-Tu
Boy-A Girl-B-W
Boy-A Girl-B-Th
Boy-A Girl-B-Fr
Boy-A Girl-B-Sat
Boy-A Boy-B-S
Boy-A Boy-B-M
Boy-A Boy-B-Tu
Boy-A Boy-B-W
Boy-A Boy-B-Th
Boy-A Boy-B-Fr
Boy-A Boy-B-Sat

Chances are 7/14. Filp around who was born first and add it in: 14/28. Even if we're not allowed to use Tuesdays for child B, we get 12/24 which is 1/2 as expected.

Even expert mathematicians slip up some times. You need to count each and every pair, and not exclude any that 'look' like they've already been counted.

Lights Out guerilla radio
turn that shit up

I can't find anything on google news about this besides blogs. Is this a hoax?

Wait? No Condoms?

Protesters will start carrying ear plugs to events.

The application that I'm working on does not lock the records. The business object remembers that initial values it was loaded with. If those have changed, when the user saves, it presents them with a message that someone else has already edited the record. Sure, that may be annoying to the user, but it really doesn't come up all that often.

It's simple SQL:
update client set unique_id = ?, first_name = ?, last_name = ? where unique_id = ? and first_name = ? and last_name = ?; (assuming no nulls allowed)

In the set clause you use the new values, in the where clause you use the old values. If zero records are updated, you have a conflict.