Wonderful post! I hope to dig deeper into it when I have more time.
In problems where the agent faces only one real choice, SCP demands that planning and doing agree: if it is rational to decide in advance “should I reach this point, do X,” then on reaching that point, X must be what it is rational to do. The motivation is a Ramsey-style test, which treats two questions as one — “what should I do if p turns out to be true?” and “p is true; what should I do?”
This loosening of the planning-doing identification assumption mirrors radical probabilism’s rejection of rigidity, i.e., of the requirement that upon learning about an event A, probabilities update according to .
Quoting Abram (with a nice example):
A non-rigid update, on the other hand, means you don’t know how you’d react: “If I saw a convincing proof of P=NP, I wouldn’t know what to think. I’d have to consider it carefully.” I’ll call non-rigid updates fluid updates.
I would find Section 2 easier to parse if you explicitly stated the type signatures of all the components. My understanding is that and (or some total order other than ?), but IDK about and .
On; , yes, though landing in is a substantive assumption. The general form is a preorder on .
, model and observation in, updated model out.
doesn’t have that shape, and I think that’s the content rather than a gap. It isn’t a map between the spaces the others live in. It takes the rest of the specification plus a tree and returns which complete plans are admissible, like:
Naive, sophisticated, resolute and updateless differ in *where the is taken, over what domain, and and (if two of that disagree) which one the agent actually acts on.
Wonderful post! I hope to dig deeper into it when I have more time.
This loosening of the planning-doing identification assumption mirrors radical probabilism’s rejection of rigidity, i.e., of the requirement that upon learning about an event A, probabilities update according to
Quoting Abram (with a nice example):
I would find Section 2 easier to parse if you explicitly stated the type signatures of all the components. My understanding is that
Thanks!
You are correct about the signatures.
On;
Naive, sophisticated, resolute and updateless differ in *where the