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.
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.
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.