What about minimum() and maximum() with empty floating-point arrays? Would it make sense for those to return -Inf and +Inf by default?
I get: *julia> **a = Array(Float64,(0,))* *0-element Array{Float64,1}* *julia> **minimum(a)* *ERROR: ArgumentError: reducing over an empty collection is not allowed* * in _mapreduce at reduce.jl:139* * in minimum at reduce.jl:325* Niclas Den onsdag 13 april 2016 kl. 09:03:57 UTC+2 skrev Milan Bouchet-Valat: > > Le mardi 12 avril 2016 à 20:21 -0700, Anonymous a écrit : > > Those are good points, although I always kind of wondered why Float > > gets Inf while Int doesn't, I guess there's no way to have Inf belong > > to 2 distinct concrete types. > The problem is that native integers have no way of representing > infinite values, contrary to floating point. They can only store actual > values. (But you can use floating point formats to store integer data > if you need Inf.) > > > Regards > > > > > > > > Have the Julia developers considered the effects of setting > > > > Base.min()=Inf and Base.max()=-Inf. This is common in real > > > > analysis since it plays nice with set theory, i.e. > > > > > > > It only plays nicely with sets of real numbers. What about sets of > > > other types that have a total ordering? e.g. strings? > > > > > > Also, one of the general principles guiding the design of the Julia > > > standard library is to provide idioms that don't cause types to > > > change arbitrarily underneath the user; this principle is critical > > > to being able to use the standard library in high-performance code > > > (since type stability is critical to compiler optimization). For > > > example min(1,2) == 1 (an Int), min(1) == 1 (an Int), but then > > > min() = Inf (floating-point)? > > > >