I think the best way to explain this is to imagine characterise the two views as slightly different functions both of which return sets. Of course, the exact type representations isn’t the point. Instead, the types are just there to illustrate the difference between two slightly different concepts.
possible_world_pure() returns {x} where x is either <study & pass> or <beach & fail>, but we don’t know which one it will be
Once we’ve defined possible worlds, it naturally provides us a definition of possible actions and possible outcomes that matches what we expect. So for example:
And if we have a decide function that iterates over all the counterfactuals in the set and returns the highest one, we need to call it on possible_world_augmented() rather than possible_world_pure().
Note that they aren’t always this similar. For example, for Transparent Newcomb they are:
The point is that if we remain conscious of the type differences then we can avoid certain errors.
For example possible_outcome_pure() = {”PASS”}, doesn’t mean that possible_outcome_augmented() = {”PASS”}. It’s that later which would imply it doesn’t matter what the student does, not the former.
Hmm, it sort of makes sense, but possible_world_augmented() returns not just a set of worlds, but a set of pairs, (world, probability). For example for the transparent Newcomb’s you get possible_world_augmented() returns {(<1-box, million>, 1), (<2-box, thousand>, 0)}. And that’s enough to calculate EV, and conclude which “decision” (i.e. possible_world_augmented() given decision X) results in maxEV. Come to think of it, if you tabulate this, you end up with what I talked about in that post.
I think the best way to explain this is to imagine characterise the two views as slightly different functions both of which return sets. Of course, the exact type representations isn’t the point. Instead, the types are just there to illustrate the difference between two slightly different concepts.
possible_world_pure() returns {x} where x is either <study & pass> or <beach & fail>, but we don’t know which one it will be
possible_world_augmented() returns {<study & pass>, <beach & fail>}
Once we’ve defined possible worlds, it naturally provides us a definition of possible actions and possible outcomes that matches what we expect. So for example:
size(possible_world_pure()) = size(possible_action_pure()) = size(possible_outcome_pure()) = 1
size(possible_world_augmented()) = size(possible_action_augmented()) = size(possible_outcome_augmented()) = 2
And if we have a decide function that iterates over all the counterfactuals in the set and returns the highest one, we need to call it on possible_world_augmented() rather than possible_world_pure().
Note that they aren’t always this similar. For example, for Transparent Newcomb they are:
possible_world_pure() returns {<1-box, million>}
possible_world_augmented() returns {<1-box, million>, <2-box, thousand>}
The point is that if we remain conscious of the type differences then we can avoid certain errors.
For example possible_outcome_pure() = {”PASS”}, doesn’t mean that possible_outcome_augmented() = {”PASS”}. It’s that later which would imply it doesn’t matter what the student does, not the former.
Hmm, it sort of makes sense, but possible_world_augmented() returns not just a set of worlds, but a set of pairs, (world, probability). For example for the transparent Newcomb’s you get possible_world_augmented() returns {(<1-box, million>, 1), (<2-box, thousand>, 0)}. And that’s enough to calculate EV, and conclude which “decision” (i.e. possible_world_augmented() given decision X) results in maxEV. Come to think of it, if you tabulate this, you end up with what I talked about in that post.