>>> min(['a', 'b'])
'a'
>>> min(['a'])
'a'
>>> min([])
float('-inf') # ???
An empty list is not a list of numbers. It's not a list of anything.(You can use typing hinting to indicate the type of an empty list, but type hints are ignored by the interpreter.)
But then again, what can you expect from a language that uses "+", the quintessential notation for commutative operations, for the (very non-commutative) operation of concatenation?
Doubly sad when you realize that the language was designed by an actual mathematician.
This is true, but they do not have exactly the same meaning. On a poset you do not speak of "the min", but of "a min". You still have "the least", which is a different notion.
Is this any worse than using `+` for floating-point addition, which isn't even associative?
Even if it wasn't, floating point numbers are very often regarded as approximations of real numbers, where addition is associative. String concatenation cannot be construed to have any resemblance of commutativity.
This is just absolutely not true. It is certainly "min" and "max" for any total order, they definitely don't have to be numbers or even numbers with the usual ordering (as confusing as that would be with a set of numbers but the reverse ordering). "first" and "last"? I've never heard that.
I haven't worked with partial orders so much that I can be as confident about that, perhaps "least" and "greatest" are the correct terms. But "min" and "max" are certainly used sometimes by non-specialists (i.e. professional mathmaticians that don't necessarily spend a lot of time with posets) without any confusion.
'a' < 'b' only by accident of history. It could just as easily have been the reverse.
Tuples have a reasonable natural total order: just compare component wise. And minimum of a list of tuples makes sense.
You could argue that alphabetic ordering is artificial, but it's hard to argue that it ain't well established and non-surprising.
Interestingly, not all numbers have intuitive orders. Eg complex numbers don't really have a good preferred ordering. And the ordering of p-adic numbers is well defined and unique, but really weird.
No they don't. (1, 2) > (2, 1) = ???
To compare tuples you need a generalisation of comparison which includes 'incomparable' as an outcome. See lattices https://en.wikipedia.org/wiki/Lattice_%28order%29
> but it's hard to argue that [alphabetic ordering] ain't well established
it is, agreed...
> and non-surprising
...agreed again, only because it's a convention you know so well (had it been reversed since your birth you'd say exactly the same thing).
I agree with both points but that does not invalidate what I said abour alphabetic ordering being artificial.
I meant that the common ordering on tuples is reasonably natural. Not that it is necessarily the One True Natural Ordering.
About lattices and partial orders: if there's a choice about what to pick as the default ordering for some built-in datatypes for your language and there are multiple reasonable choices, going with the total order seems like a good idea.
To give a counterexample: functions from natural numbers to an orderable set have a well defined, reasonably natural order, just compare them like as if they were a list of elements of the orderable set. But that would be a bad idea in a programming language, and it is indeed better to just treat functions as incomparable by default.
Similarly we could have said b < a is true but then it would always be true and a < b would be false and the world would be exactly the same because this is all a made up convention for the benefit of humans.
Numbers are the underlying conceptual thing.
You could invent a monoid instance of `float` for `<` which includes `inf` as an empty element and, if you ignore NaN, it kinda sorta works in isolation. However, adding infinity breaks a lot of other nice properties to the numbering system.
For example, the following identity of `min` is valid in the finite numbers.
``` n < min A ⟺ (∀ a ∈ A) n < a ```
The right part of the equation is always true if `A = ∅`, and according to our new monoid the left part is true if and only if `n ≠ ∞`.
To get what you want, use min(lst, default=-math.inf) .
In Python 2, you had
float('-inf') < ""
So you could sort of get away with that. But that positive infinity wasn't bigger than any string. And in Python 3 comparing strings and numbers just results in an error.Excellent point, thanks!
(infinity + 1) > infinity
which it isn't. I know about IEEE infs and nans, and neither are numbers, just useful conventions.
Agreed, neet to be precise here, so let's de-abstract away from numbers. Which is greater, 3 apples or 8 apples?
Now give me infinity apples. Finite apples exist, infinite apples don't except as an idea. Personally, infinities make me uncomfortable.
As for mathematical notions of numbers, there are of course mathematics with all kinds of infinite numbers. You have the transfinite ordinal and cardinal numbers, with the famous 2^Aleph0 = Aleph1 value (2^the number of natural numbers = the number of real numbers). You have infinitesimals as well. These are all just as well defined as the naturals and rationals, and exist just as much.
Not to mention that you could say: well sure, I can imagine a trillion trillion apples, but they don't really exist, they're just a fantasy. In reality we only have MAX_REAL_APPLE apples, and damn it, Johnny just ate one so the largest 'really existing' number just went down.
Overall, we can play this game a lot, but the reality is that pi is as real as Aleph0 which is as real as 1 and 2 and 0.0000...1 and +Inf etc.
Sure. So a simplified model is probably the right tradeoff to make. But we should not forget that it is a tradeoff; by working in a simplified world of notation we run the risk of forming constructions that can't actually be carried back to the real world of counting apples or dust mites. The map is not the territory.
> Overall, we can play this game a lot, but the reality is that pi is as real as Aleph0 which is as real as 1 and 2 and 0.0000...1 and +Inf etc.
"All models are wrong, but some are useful" - but not all models are equally wrong, and not all are equally useful. Including pi gives us a model that's easier to work with, but introduces a certain risk of forming a construction that doesn't translate back to reality. Including infinities brings a substantially bigger version of that risk. It may still be the right choice, but it's a choice that should be made carefully and deliberately; blindly assuming that all mathematical models are appropriate to a given situation is quite unwise.
i know this is nitpicking, but i think when you really look at it, "infinity apples" isn't that much more of an "idea" than "3 apples". (even if the latter is more useful in day-to-day life)