Thanks for your response. I agree, that for AbstractFloat types, the suggested return values (-Inf resp. Inf) seem more reasonable that the typemin resp. typemax outputs for other Real types.
In the meanwhile, I think, the problem is even more general, I restrict to the maximumcase for now. In the minimum case so analogous.
maximum(itr) should IMHO mimic the behavior of reduce(max, v0, itr), where it tries to guess the type and value of v0 depending on eltype(itr) if itr is empty. “v0 must be a neutral element for op that will be returned for empty collections.” according to the documentation of reduce. The neutral element of max is any lower bound on the type on which max operates. Now lower bounds are not implemented for all kinds of types, which implement max or <. So in the moment typemin is the best guess we have in the general case.
We could also introduce a new function like lowerbound or so, which explicitly provide the value per type.
Here a list of lower bounds for some types, not restricted to Real:
| Type | lower bound | upper bound |
|---|---|---|
| Int32 | ? | ? |
| UInt32 | UInt32(0) | ? |
| Float16 | -Inf16 | Inf16 |
| BigInt | no representation of -∞ provided | no representation of ∞ provided |
| BigFloat | typemin(BigFloat) | typemax(BigFloat) |
| Rational{T} | -one(T)//zero(T) | one(T)//zero(T) |
| String | “” | nothing |
| Set{T} | Set(T) | set of all elements of type T |
The ? means: typemax returns a value, which may be considered an implementation artefact but does not represent the bound of a mathematical idealization. BigInt suffers from the missing implementation of infinities in GMP.
The Set example is arguable because <(x::Set,y::Set) implements the usual order relation for sets, but max(x::Set,y::Set}) should not be ifelse( y < x, x, y) but rather union(x,y).