On testing, there's more to it than that. Factorio truncates negative numbers as well. Thus, for an example I hit right now, 323 / 15 = 21, and -323 / 15 = -21.
For finding the minimum of a positive number, this works; the result of the division is guaranteed to be equal to or less than all of the input signals. It fails on negative numbers, because that no longer holds true. For a simple example, -5 / 2 = -2, but the input signals could be -3 and -2.
If the comparator is also flipped to greater-than it will now successfully find a maximum, but that maximum is actually the minimum if you've multiplied the original dataset by -1, which doesn't really advance me any. I think for this to work properly you need to be working strictly in the domain of positive numbers.
That means that to find a maximum you need to take your inputs, multiply them all by -1, and add a large positive constant. Then, out the other end, subtract that positive constant again, and then multiply that by -1. Unless I'm missing something clever, anyway.
Realized a simpler way would be to flip the comparison to greater-than-or-equals, but bias the input with a large negative constant, and then remove it from the output.
It is also important to note that the arithmetic combinator that converts the gated inputs to a single-channel sum for use in the division operation cannot be fed a sum beyond Factorio's bit-range, or this operation will fail. In finding the minimum of positive numbers this won't usually arise unless you're working with very large circuit-driven or combinator-set values, but it meant my initial plan of using MIN_INT for the negative bias in the maximum-finder failed. Wound up choosing -10M, but this imposes bounds on both the number of signals it can process and the maximum range those signals can assume.