= 27d567bc2d48d9f40e9ccc20ea370b15)
Lumifer comments on Probabilities Small Enough To Ignore: An attack on Pascal's Mugging - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (176)
Not really avoiding -- a bound on your utility in the context of a Pascal's Mugging is basically a bound on what the Mugger can offer you. For any probability of what the Mugger promises there is some non-zero amount that you would be willing to pay and that amount is a function of your bound (and of the probability, of course).
However utility asymptotically approaching a bound is likely to have its own set of problems. Here is a scenario after five seconds of thinking:
That vexatious chap Omega approaches you (again!) and this time instead of boxes offers you two buttons, let's say one of them is teal-coloured and the other is cyan-coloured. He says that if you press the teal button, 1,000,001 people will be cured of terminal cancer. But if you press the cyan button, 1,000,000 people will be cured of terminal cancer plus he'll give you a dollar. You consult your utility function, happily press the cyan button and walk away richer by a dollar. Did something go wrong?
Yes, something went wrong in your analysis.
I suggested mapping an unbounded utility function onto a finite interval. This preserves the order of the preferences in the unbounded utility function.
In my "unbounded" function, I prefer saving 1,000,001 people to saving 1,000,000 and getting a dollar. So I have the same preference with the bounded function, and so I press the teal button.
If you want to do all operations -- notably, adding utility and dollars -- before mapping to the finite interval, you still fall prey to the Pascal's Mugging and I don't see the point of the mapping at all in this case.
The mapping is of utility values, e.g.
In my unbounded function I might have:
Saving 1,000,000 lives = 10,000,000,000,000 utility. Saving 1,000,001 lives = 10,000,010,000,000 utility. Getting a dollar = 1 utility. Saving 1,000,000 lives and getting a dollar = 10,000,000,000,001 utility.
Here we have getting a dollar < saving 1,000,000 lives < saving 1,000,000 lives and getting a dollar < saving 1,000,001 lives.
The mapping is a one-to-one function that maps values between negative and positive infinity to a finite interval, and preserves the order of the values. There are a lot of ways to do this, and it will mean that the utility of saving 1,000,001 lives will remain higher than the utility of saving 1,000,000 lives and getting a dollar.
But it preserves this order, not everything else, and so it can still avoid Pascal's Mugging. Basically the mugging depends on multiplying the utility by a probability. But since the utility has a numerical bound, that means when the probability gets too low, this multiplied value will tend toward zero. This does mean that my system can give different results when betting is involved. But that's what we wanted, anyway.
Oh, I see. So you do all the operations on the unbounded utility, but calculate the expected value of the bounded version.