Consider how? If you treat a UnitRange like a collection, it will behave like a collection. That’s true throughout Julia, consider minimum(3, 4) and minimum(3, [4]).
Yes but it is o(n) instead of o(1) according to length(range)
deserve a lot of likes . may be (certainly) more than what minimum and maximum merits nowaday
julia lacks a good statically dispatchable interface on iterable
one should think about data shaping and mapping and not collapse them inadvertently. these should be treat like data invariants and preserve like beloved physical constant
1 Like
But maximum and minimum are optimized:
minimum(r::AbstractUnitRange) = isempty(r) ? throw(ArgumentError("range must be non-empty")) : first(r)
maximum(r::AbstractUnitRange) = isempty(r) ? throw(ArgumentError("range must be non-empty")) : last(r)
I would say that scalar < minimum(vector) is better code than all(<(scalar), vector), many Vectors take advantage of the opportunity to give O(log(n)) or O(1) results for minimum and maximum.
1 Like
Currently, < is defined on AbstractVectors by lexicographic ordering. As such, you can already compare UnitRanges with each other. Your proposed ordering breaks transitivity, e.g. (1:5) < (2:3) && (2:3) < 4 but !((1:5) < 4).
2 Likes
If both order variant and type lifting are implicit, that will be a mess like your describe