Fascinating—but why is this an objection? Is it just the inelegance of not being able to look at a single time slice and answer the question of whether optimization is happening?
No, the issue is that the usual definition of an optimization problem (e.g. maxxf(x)) has no built-in notion of time, and the intuitive notion of optimization (e.g. “the system makes Y big”) has no built-in notion of time (or at least linear time). It’s this really fundamental thing that isn’t present in the “original problem”, so to speak; it would be very surprising and interesting if time had to be involved when it’s not present from the start.
If I specifically try to brainstorm things-which-look-like-optimization-but-don’t-involve-objective-improvement-over-time, then it’s not hard to come up with examples:
Rather than a function-value “improving” along linear time, I could think about a function value improving along some tree or DAG—e.g. in a heap data structure, we have a tree where the “function value” always “improves” as we move from any leaf toward the root. There, any path from a leaf to the root could be considered “time” (but the whole set of nodes at the “same level” can’t be considered a time-slice, because we don’t have a meaningful way to compare whole sets of values; we could invent one, but it wouldn’t actually reflect the tree structure).
The example from the earlier comment: a one-shot non-iterative optimizer
A distributed optimizer: the system fans out, tests a whole bunch of possible choices in parallel, then selects the best of those.
Various flavors of constraint propagation, e.g. the simplex algorithm (and markets more generally)
I think this is a very important distinction. I prefer to use “maximizer” for “timelessly” finding the highest value of an objective function, and reserve “optimizer” for the kind of stepwise improvement discussed in this post. As I use the terms, to maximize something is to find the state with the highest value, but to optimize it is to take an initial state and find a new state with a higher value. I recognize that “optimize” and “optimizer” are sometimes used the way you’re saying, as basically synonymous with “maximize” / “maximizer”, and I could retreat to calling the inherently temporal thing I’m talking about an “improver” (or an “improvement process” if I don’t want to reify it), but this actually seems less likely to be quickly understood, and I don’t think it’s all that useful for “optimize” and “maximize” to mean exactly the same thing.
(There is a subset of optimizers as I (and this post, although I think the value should be graded rather than binary) use the term that in the limit reach the maximum, and a subset of those that even reach the maximum in a finite number of steps, but optimizers that e.g. get stuck in local maxima aren’t IMO thereby not actually optimizers, even though they aren’t maximizers in any useful sense.)
No, the issue is that the usual definition of an optimization problem (e.g. maxx f(x)) has no built-in notion of time, and the intuitive notion of optimization (e.g. “the system makes Y big”) has no built-in notion of time (or at least linear time). It’s this really fundamental thing that isn’t present in the “original problem”, so to speak; it would be very surprising and interesting if time had to be involved when it’s not present from the start.
If I specifically try to brainstorm things-which-look-like-optimization-but-don’t-involve-objective-improvement-over-time, then it’s not hard to come up with examples:
Rather than a function-value “improving” along linear time, I could think about a function value improving along some tree or DAG—e.g. in a heap data structure, we have a tree where the “function value” always “improves” as we move from any leaf toward the root. There, any path from a leaf to the root could be considered “time” (but the whole set of nodes at the “same level” can’t be considered a time-slice, because we don’t have a meaningful way to compare whole sets of values; we could invent one, but it wouldn’t actually reflect the tree structure).
The example from the earlier comment: a one-shot non-iterative optimizer
A distributed optimizer: the system fans out, tests a whole bunch of possible choices in parallel, then selects the best of those.
Various flavors of constraint propagation, e.g. the simplex algorithm (and markets more generally)
I think this is a very important distinction. I prefer to use “maximizer” for “timelessly” finding the highest value of an objective function, and reserve “optimizer” for the kind of stepwise improvement discussed in this post. As I use the terms, to maximize something is to find the state with the highest value, but to optimize it is to take an initial state and find a new state with a higher value. I recognize that “optimize” and “optimizer” are sometimes used the way you’re saying, as basically synonymous with “maximize” / “maximizer”, and I could retreat to calling the inherently temporal thing I’m talking about an “improver” (or an “improvement process” if I don’t want to reify it), but this actually seems less likely to be quickly understood, and I don’t think it’s all that useful for “optimize” and “maximize” to mean exactly the same thing.
(There is a subset of optimizers as I (and this post, although I think the value should be graded rather than binary) use the term that in the limit reach the maximum, and a subset of those that even reach the maximum in a finite number of steps, but optimizers that e.g. get stuck in local maxima aren’t IMO thereby not actually optimizers, even though they aren’t maximizers in any useful sense.)