Sure-thing principle | Hacker News Reader

Sure-thing principle

en.wikipedia.org

31 pointstchalla29 comments

"the sure-thing principle states that a decision maker who would take a certain action if he knew that event E obtained, and also if he knew that the negation of E obtained, should also take that same action if he knows nothing about E."

using "obtain" in it's archaic, old-french, meaning of roughly "succeed". Wikipedia math pages are generally useless for non-experts, but this is a new one!

Appears to be updated to more natural language now; I guess a Wikipedia editor saw your comment!

It now says occurred instead of obtained.

No set of pages in Wikipedia imply “we hate everybody else” quite like the math pages. It’s like the math folks have either forgotten that Wikipedia is for communicating with people, they just don’t care, or they don’t know how.

Every time I read a math page on Wikipedia I want to go watch a Feynman lecture as eye bleach.

I'm very thankful for Simple English Wikipedia for this reason. Compare the vanilla Set page https://en.wikipedia.org/wiki/Set_(mathematics) with https://simple.wikipedia.org/wiki/Set.

It's too bad there aren't more of these pages, as they are honestly excellent quick resources.

Hahaha, yeah. Imo best math lecturers actually do provide a lot of intuition behind the discussed material. Otherwise I feel like they don't understand the topic themselves that well. (Exceptions are rare, but possible tho.)

Other resources like http://mathworld.wolfram.com/ (and I think, there is also a proof wiki, or math wiki?). Such resources can be more useful, even if they are not as extensive as Wikipedia, they win in consistency between the articles and better at providing intuition and background information.

When E is true and stative, the state of E obtains.

The meaning is current and has absolutely nothing to do with "succeeding": http://wordnetweb.princeton.edu/perl/webwn?s=obtain&sub=Sear...

> (v) prevail, hold, obtain (be valid, applicable, or true) "This theory still holds."

The mistake in the section you quote is labeling E an "event" rather than a state.

Is this trivial, or am I missing something?

I guess I'm missing it too.

action(x) = a if x

        = a if not x

Does action(x) not just equal a?

It depends on whether evaluating x leads to non-termination. In that case, action(x) should also not terminate.

Yeah, I would be curious of a different scenario when:

  - If E then I would take action A
  - If not E then I would take A also
  - However when the outcome of (E vs not E) is undetermined, hesitate from action A.

Does anyone know a real world example of such a situation?

Scientists say that there's a considerable but not overwhelming chance that the volcano on my island might erupt in the next few days.

If I knew that the volcano is going to erupt, then I would drive to the airport (with all my belongings, and leave).

If I knew that the volcano on my island is not going to erupt this month, then I would drive to the airport (to go on a package holiday that I had planned).

However, if the outcome is undetermined, I might prefer to cancel my holiday (I would not enjoy it while worrying about all my stuff potentially being destroyed in a fiery inferno) and wait to see what happens. So I should hesitate from driving to the airport.

In this example the two "drive to airport" actions are different.

    If (volcano_status == GONNA_BLOW)
        pack_everything_and_run();
    else if (volcano_status == NO_WORRIES)
        pack_suitcase_and_leave_for_holiday();
    else if (volcano_status == UNKNOWN)
        cancel_holiday();

It depends on what you treat as a complete action. One could equally well decompose it as two actions and two conditionals:

if (volcano_status == GONNA_BLOW) refuel_car(); else if (volcano_status == NO_WORRIES) refuel_car(); else if (volcano_status == UNKNONW) nop();

then later

if (volcano_status == GONNA_BLOW) pack_everything_and_run(); else if (volcano_status == NO_WORRIES) pack_suitcase_and_leave_for_holiday(); else if (volcano_status == UNKNONW) call_to_cancel_holiday();

Then refueling the car is definitely the same action, even if it's followed by different actions later on.

I don't think things in real life lead to non-termination, because humans are flexible and get bored. (In fact I'm pretty sure this is the evolutionary advantage behind boredom - it's a mechanism for breaking out of loops.)

It's fairly trivial, but related to Simpson's paradox, which isn't. There is a hidden assumption that's worth pointing out.

It was probably posted due to recent discussion of casual inference. Judea Pearl talks about it in The Book of Why.

you mean causal? though I'm intrigued about casual inference now that you mention it. would this be a branch of behavioral economics where actors investing only a little effort come to a different conclusion than those looking at it formally? Could this explain the wealth gap?

Yes, causal. :)

The sure things principle comes from decision theory and economics. It's obvious in the sense that it constitutes one of the axioms that define rational behavior.

In decision theory, we try to define behavioral axioms in a way that choices under uncertainty can be encoded in mathematical functions (utility functions or reward functions as Machine Learning has renamed/rediscovered these things). Connecting properties of these "preference orders" with utility functions and probabilities is the basis of a lot (but not all!) of modern economics.

Check for example Savage's proof of the existence of a subjective probability measure and a utility function based on only handful of "trivial" axioms. If these axioms hold, we can do meaningful mathematical social science.

The issue is of course that people don't actually behave rationally. The examples (or paradoxes) by Ellsberg and Allais show that most people violate the sure things principle.

If you are interested to learn more, here are some excellent notes by Gilboa http://www.econ.hit-u.ac.jp/~makoto/education/Gilboa_Lecture...

I can answer questions as well.

It's supposed to be trivial; it's one of the axioms of decision theory from which other (less obvious) things are derived. For example the vNM Theorem (that every rational agent acts as though it were maximising some utility function) follows from a set of assumptions including the sure thing principle.

lousy wikipedia math culture aside, this is critical bit of logic for Sudoku players :)

Sounds like dilemma: https://en.wikipedia.org/wiki/Dilemma#Use_in_logic

Disjunction elimination rule of inference: https://en.wikipedia.org/wiki/Disjunction_elimination (plus, the law of excluded middle that either E or not E holds)

Wow, that rule is stated horribly.

You'd get much more value from phrasing it as

    ((p implies r) and (q implies r)) iff ((p or q) implies r).

No need to have a special rule stating that when you also have (p or q), you can resolve all three to just "r" in one step instead of two steps.

I really really wish math jargon and symbols could be replaced with code. I feel like I could have done a lot better in math if it had been taught in python.

Programming languages generally capture only some specific logic (or some specific kind of math) in their semantics.

Certain concepts like the law of excluded middle (either A or not A must hold), and proofs by contradiction that are common in math, simply don't exist in programming. That's because programming is based on constructive logic / constructive math foundation.

Learning the basics of logic can be beneficial for a programmer tho, and the connection with functional programming is especially high.

Well, then it would be a different rule. The one I referred to, eliminates disjunction, and so that's where its name is coming from.

No, it would be the same rule, just phrased better. The rule works by introducing a disjunction (to match the one you already have), not by eliminating one.

Given

    a implies p
    b implies p
    a or b

you can conclude ((a or b) implies p) from my statement of the rule, and then conclude "p" from modus ponens. And if you're feeling really obscurist, you can rename modus ponens to "proposition elimination".

But notice that if you have

    a implies p
    b implies p
    c implies p
    a or b or c

then my statement of the rule will still allow you to conclude "p", whereas the statement on wikipedia won't.

You misunderstand my comment. I'm not saying that your interpretation is wrong. I'm fine with it. Better or not, either result can be used in the right context. I'm saying that your interpretation does not eliminate disjunction, so it should be called differently. It's a different rule, that's all I want to say.

> Better or not, either result can be used in the right context.

This is most of the point I'm making -- there is no context where the brittle, overspecified version is useful but the more general version isn't. But there are lots of contexts where the overspecified version is useless.

And again, it's not a different rule. Brittle "disjunction elimination" is a special case of the rule I state. Similarly, the Pythagorean Theorem is a special case of the Law of Cosines, not a different rule.

It gets worse, though, because where the Pythagorean Theorem is simpler to state than the Law of Cosines, brittle disjunction elimination is more complex to state than the more general result is.

Think about exportation. We say:

    (a implies (b implies p)) iff ((a and b) implies p)

We don't say:

    ((a implies (b implies p)) and (a and b)) implies p

That second version, which is the equivalent of brittle disjunction elimination for and instead of or, is harder to state, is less informative, and doesn't generalize.

Reply on news.ycombinator.com