The game fixes each player’s utility function, and then we fix all strategies, yes? It doesn’t seem right to bundle one strategy and one utility function, which aren’t fixed at the same time, into one “player”.
I’m not sure what you mean by fixing the utility function occurring before fixing the strategy. In the problem setup of a game, you specify a utility function machine and a strategy machine for everyone, and there isn’t any sort of time or order on this (there’s just a set of pairs of probabilistic oracle machines) and you can freely consider things such as “what happens when we change some player’s strategies/utility function machines”
I expected that we want to ask questions such as which strategy in a game dominates all others, which requires that the utility functions are known but the strategies aren’t.
Should the dependency relation care about oracle queries from strategies? After all, a strategy could preserve its behavior while removing a dependency by simulating what it was going to ask the oracle about, deferring all new queries to the oracle again. Or is this ruled out by interesting query simulations sometimes diverging? Worse, you can make an arbitrary utility function part of the pareto optimization by asking the oracle about the player with particular utility and trivial strategy.
The basic reason for the dependency relation to care about oracle queries from strategies is that, when you have several players all calling the oracle on each other, there’s no good way to swap out the oracle calls with the computation. The trick you describe does indeed work, and is a reason to not call any more turing machines than you need to, but there’s several things it doesn’t solve. For instance, if you are player 1, and your strategy depends on oracle calls to player 2 and 3, and the same applies to the other two players, you may be able to swap out an oracle call to player two with player two’s actual code (which calls players 1 and 3), but you can’t unpack any more oracle calls into their respective computations without hitting an infinite regress.
The game fixes each player’s utility function, and then we fix all strategies, yes? It doesn’t seem right to bundle one strategy and one utility function, which aren’t fixed at the same time, into one “player”.
I’m not sure what you mean by fixing the utility function occurring before fixing the strategy. In the problem setup of a game, you specify a utility function machine and a strategy machine for everyone, and there isn’t any sort of time or order on this (there’s just a set of pairs of probabilistic oracle machines) and you can freely consider things such as “what happens when we change some player’s strategies/utility function machines”
I expected that we want to ask questions such as which strategy in a game dominates all others, which requires that the utility functions are known but the strategies aren’t.
Should the dependency relation care about oracle queries from strategies? After all, a strategy could preserve its behavior while removing a dependency by simulating what it was going to ask the oracle about, deferring all new queries to the oracle again. Or is this ruled out by interesting query simulations sometimes diverging? Worse, you can make an arbitrary utility function part of the pareto optimization by asking the oracle about the player with particular utility and trivial strategy.
The basic reason for the dependency relation to care about oracle queries from strategies is that, when you have several players all calling the oracle on each other, there’s no good way to swap out the oracle calls with the computation. The trick you describe does indeed work, and is a reason to not call any more turing machines than you need to, but there’s several things it doesn’t solve. For instance, if you are player 1, and your strategy depends on oracle calls to player 2 and 3, and the same applies to the other two players, you may be able to swap out an oracle call to player two with player two’s actual code (which calls players 1 and 3), but you can’t unpack any more oracle calls into their respective computations without hitting an infinite regress.