specialize argmin/argmax on ranges

[jw3126]

before:

julia> using BenchmarkTools; @btime argmin(1:1000)
  1.054 μs (0 allocations: 0 bytes)

after:

julia> using BenchmarkTools; @btime argmin(1:1000)
  1.901 ns (0 allocations: 0 bytes)

[jw3126]

merge?

[TotalVerb]

This is not something to care about (will not break any actual code), but it may be worth mentioning that argmax currently will return the first of all maximal elements, and elements in Float ranges need not be unique. For example,

julia> argmax(9.999999999e15:1e16)
1000000

julia> lastindex(9.999999999e15:1e16)
1000001

Nevertheless I think this specialization makes sense. It might be worth documenting that the "If there are multiple maximal elements, then the first one will be returned." does not necessarily apply to certain pathological ranges, but then again, perhaps this case is so rare that it's unimportant. (Or, maybe revise the current argmax documentation to say "For Arrays, if there are multiple [...]", which gives implementors of custom types freedom to choose a different extremum if simpler.)

[jw3126]

Urgs, I think it is nice that argmax returns the first maximum in general. Another way out would be to add a slow branch that does binary search on ranges in case that e.g. the previous element of the last one is as big.

[jw3126]

Here is an example of a degenerate range, that I can imagine happening in real code:

julia> r = map(Float32, 1:10^8)
1.0f0:1.0f0:1.0f8

julia> collect(r[end-10:end])
11-element Array{Float32,1}:
 9.999999e7
 9.999999e7
 9.999999e7
 9.999999e7
 9.999999e7
 1.0e8     
 1.0e8     
 1.0e8     
 1.0e8     
 1.0e8     
 1.0e8     

[jw3126]

Here is a related bug:

julia> searchsorted(1f0:1f8, 1f8)
100000000:100000000
julia> (1f0:1f8)[end-1]
1.0f8

[jw3126]

function argmin(r::AbstractRange)
    if isempty(r)
        throw(ArgumentError("range must be non-empty"))
    elseif step(r) > 0
        firstindex(r)
    else
        first(searchsorted(r, last(r)))
    end
end

This should be the solution if there was not #34408 . I don't feel like fixing #34408 however, at least not any time soon. So I documented, that a non first index may be returned.

[jw3126]

I think CI fail is unrelated to the PR.

[StefanKarpinski]

Can you rebase on a newer master? That's a lot of test failures, which makes me nervous.

[jw3126]

Can somebody rerun the failing CI?

[StefanKarpinski]

That particular CI failure has been happening lately and is unrelated. Very unlikely that this is failing only on FreeBSD, so I just merged since there were no other failures there or elsewhere.