Manfred comments on A simple counterexample to deBlanc 2007? - Less Wrong

3 Post author: PhilGoetz 30 May 2011 05:09AM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Comments (40)

You are viewing a single comment's thread.

Comment author: Manfred 30 May 2011 06:39:18AM *  0 points [-]

Are you sure you get to choose a specific normalized probability function? Because then you can just number your possible outcomes by integers n and set p(n) to 1/U(n) * 1/2^n, which seems too easy to have been missed.

It might be slightly more complicated in practice, since S doesn't have to be countable if the uncountable parts can be integrated over. This doesn't violate the linked theorem because each item in the "sum" is not greater than zero, it's infinitesimal. But you could do pretty much the same thing to the probability densities inside any integrals.

So I suspect that the result is only proved for when you don't get to choose your own probability function, and that that comes up in the paper. But I agree that due to some effects you can end up with probability and utility functions that naturally are biased against high-utility situations, and this would be a counterexample to the result's applicability in those special cases.

Comment author: PhilGoetz 30 May 2011 03:08:23PM 0 points [-]

The probability function I chose meets the requirements in the paper; therefore it is a case that the theorem should apply to.

Trying to set p(n) to 1/U(n) * 1/2^n is clever; but it doesn't work, because that probability distribution is not known to sum to 1. (It would sum to 1 if U(n) = 1 for all n.)

Comment author: AlephNeil 30 May 2011 08:04:46AM *  0 points [-]

Because then you can just number your possible outcomes by integers n and set p(n) to 1/U(n) * 1/2^n, which seems too easy to have been missed.

The reason why this wouldn't work is that sometimes what you're calling "U(n)" would fail to be well defined (because some computation doesn't halt) whereas p(n) must always return something.

Comment author: PhilGoetz 30 May 2011 03:05:25PM *  0 points [-]

The reason why this wouldn't work is that sometimes what you're calling "U(n)" would fail to be well defined (because some computation doesn't halt)

No; the utility function is stipulated to be computable.

Comment author: AlephNeil 30 May 2011 03:09:52PM *  0 points [-]

No; the utility function is stipulated to be computable.

What Manfred is calling U(n) here corresponds to what the paper would call U(phi_n(k)).

Comment author: PhilGoetz 30 May 2011 06:12:14PM 0 points [-]

The utility function is defined as being computable over all possible input.

Comment author: AlephNeil 31 May 2011 11:44:54AM 0 points [-]

phi_n(k) may not halt.