4 ms·

I think of it as: the minimum of an empty set is +inf as the min of a union must be the min of the mins. Similarly, the max of empty must be -inf.

thaumasiotes 7y ago
Those will get you the right result if you use them as an initial value in a fold and the set is not empty. They're not correct on their own; an empty set has no minimum or maximum.
- eru 7y ago
  It depends. You _can_ define minimum and maximum over empty sets exactly as described and get a consistent mathematical system. But eg Python's minimum and maximum functions don't do that. They throw an error by default. In mathematical terms, if you have a lattice https://en.wikipedia.org/wiki/Lattice_(order) https://en.wikipedia.org/wiki/Lattice_(order) you can always just arbitrarily introduce a least and greatest element, and all the relevant laws stay valid. Whether that's a good idea for your application or not, is a different question. In programming, types often give you trouble. Eg the integers don't have least or greatest element, but you want your minimum function over list of integers to return an integer. So throwing an error is the only choice, if you can't represent something like minus infinity in your return type.
  - thaumasiotes 7y ago
    > You _can_ define minimum and maximum over empty sets exactly as described and get a consistent mathematical system. You can define infimum and supremum that way. But I was under the impression that wherever the concept of a "minimum element" of a set is used, the minimum element of any set must be an element of that set. So e.g. the positive reals have an infimum, 0, but no minimum. The page you link doesn't do much to dispute this idea; it uses "minimum" and "maximum" to talk about the largest and smallest elements of the lattice, but never to talk about a property that a subset of the lattice might have.
    - eru 7y ago
      I guess you are right. Of course, the Python function named 'min' could very well implement an infimum in this case, and it would be OK. In general, there's some conventions, like using the words 'minimum' vs 'infimum'. Or stressing the property 'result of min should be an element of the input set' vs 'min on lists should behave like repeated application of min on two arguments starting with the neutral element'. The right choice depends on context. In lots of programming context, I find stressing the connection with the minimum monoid was useful.
      - thaumasiotes 7y ago
        > Of course, the Python function named 'min' could very well implement an infimum in this case, and it would be OK. Using min(∅) = +inf and max(∅) = -inf would violate the otherwise valid constraint that min(x) ≤ max(x). I'd be a little uncomfortable with it for that reason. > The right choice depends on context. Definitely.
        eru 7y ago
        > Using min(∅) = +inf and max(∅) = -inf would violate the otherwise valid constraint that min(x) ≤ max(x). I'd be a little uncomfortable with it for that reason. Excellent point! Funny enough, we have the same with 'any' and 'all': For most lists of booleans: all(l) ≤ any(l). Or equivalently all(l) implies any(l). But that property is broken for empty lists. Hmm, I think I might understand the case for `all([]) == False` a bit better now. Though I still disagree with it.

thaumasiotes 7y ago

Those will get you the right result if you use them as an initial value in a fold and the set is not empty. They're not correct on their own; an empty set has no minimum or maximum.

eru 7y ago
It depends. You _can_ define minimum and maximum over empty sets exactly as described and get a consistent mathematical system. But eg Python's minimum and maximum functions don't do that. They throw an error by default. In mathematical terms, if you have a lattice https://en.wikipedia.org/wiki/Lattice_(order) https://en.wikipedia.org/wiki/Lattice_(order) you can always just arbitrarily introduce a least and greatest element, and all the relevant laws stay valid. Whether that's a good idea for your application or not, is a different question. In programming, types often give you trouble. Eg the integers don't have least or greatest element, but you want your minimum function over list of integers to return an integer. So throwing an error is the only choice, if you can't represent something like minus infinity in your return type.
- thaumasiotes 7y ago
  > You _can_ define minimum and maximum over empty sets exactly as described and get a consistent mathematical system. You can define infimum and supremum that way. But I was under the impression that wherever the concept of a "minimum element" of a set is used, the minimum element of any set must be an element of that set. So e.g. the positive reals have an infimum, 0, but no minimum. The page you link doesn't do much to dispute this idea; it uses "minimum" and "maximum" to talk about the largest and smallest elements of the lattice, but never to talk about a property that a subset of the lattice might have.
  - eru 7y ago
    I guess you are right. Of course, the Python function named 'min' could very well implement an infimum in this case, and it would be OK. In general, there's some conventions, like using the words 'minimum' vs 'infimum'. Or stressing the property 'result of min should be an element of the input set' vs 'min on lists should behave like repeated application of min on two arguments starting with the neutral element'. The right choice depends on context. In lots of programming context, I find stressing the connection with the minimum monoid was useful.
    - thaumasiotes 7y ago
      > Of course, the Python function named 'min' could very well implement an infimum in this case, and it would be OK. Using min(∅) = +inf and max(∅) = -inf would violate the otherwise valid constraint that min(x) ≤ max(x). I'd be a little uncomfortable with it for that reason. > The right choice depends on context. Definitely.
      - eru 7y ago
        > Using min(∅) = +inf and max(∅) = -inf would violate the otherwise valid constraint that min(x) ≤ max(x). I'd be a little uncomfortable with it for that reason. Excellent point! Funny enough, we have the same with 'any' and 'all': For most lists of booleans: all(l) ≤ any(l). Or equivalently all(l) implies any(l). But that property is broken for empty lists. Hmm, I think I might understand the case for `all([]) == False` a bit better now. Though I still disagree with it.