Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Nah, there's a lot of space between "this should be the favored interpretation" and "this is strictly implied" - especially in the context of a math puzzle!


I don't think there is. This is a simple brain teaser. It's fun because the right answer is counterintuitive, that's all.

It's not at all about "rules lawyering" the premise of the puzzle.


But this makes no sense. You're proving the "counterintuitive answer" with the probability theory but when confronted with the fact that your proof is not mathematically correct you say "this is a simple brain teaser". I don't see how it changes anything. If you rely on the probability theory then you have to do it correctly, there's no special brain teaser version of math.

It's like going around saying that "counterintuitive answer to equation x/x=1 is 17" and then "prove it" by dividing 17 by 17 . When confronted with the fact that in math to solve an equation is to find ALL solutions and not just one, you say "It's not at all about rules lawyering the premise of the puzzle". Well avoid dealing with the math then because the math in fact is all about the rules.


> But this makes no sense. You're proving the "counterintuitive answer" with the probability theory but when confronted with the fact that your proof is not mathematically correct you say "this is a simple brain teaser"

The answer IS mathematically correct. It's just counterintuitive and it made some PhDs trip.

Nobody here -- not even you, before -- was arguing it's mathematically incorrect. Some people, when told the right answer, claimed the problem is underspecified and admits more than one context that may change the answer, which is not at all the same as saying the answer is mathematically incorrect! Not even Diaconis, the person some of you are so eager to defend (for some bizarre reason) claims it's "mathematically incorrect"!

It seems you're grasping at straws now.


I do argue that. In probability theory you can't assume independence of two random variables unless it's a part of the problem statement because this assumption changes everything. Where I got my degree this would be considered an error and an incorrect solution to the problem.

It's not different from how in middle school you can incorrectly assume that "x is positive" when solving x^2=4 in R. An answer "x=2" is mathematically incorrect.


> I do argue that

Well, you're wrong. What's worse, the followup by vos Savant clarified this.

> In probability theory you can't assume independence of two random variables unless it's a part of the problem statement

In most logic puzzles you can safely assume an interpretation of the problem that makes sense and which doesn't go into extraneous tangents. Going "well, akshually, if we assume a spherical goat..." is usually a bad sign.

Frankly, all of this still reads as an a posteriori rationalization for finding the solution to the straightforward formulation of the puzzle counterintuitive.


> Frankly, all of this still reads as an a posteriori rationalization for finding the solution to the straightforward formulation of the puzzle counterintuitive

Luckily, when I was introduced to that problem many years ago it was presented correctly and the answer albeit counterintuitive was perfectly clear. Developing an intuition for it was also rather easy (what is the chance I guessed incorrectly at a first try? it's the answer).

What's above is my reaction to the incomplete formulation of the problem and an incorrect answer that follows.

The reason I'm so annoyed by this is because probability theory is very fragile and only works when applied with absolute precision. If you follow your approach with the Two Envelopes Problem and make some "reasonable assumptions", you get a crazy answer (always switch). And people who are in the business of logic puzzles rather than probability theory wouldn't even know the difference.

Therefore I would rather discourage people from working on logic puzzles and suggest doing the actual math instead.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: