findprev: use zero(eltype(A)) instead of 0

[Keno]

No description provided.

[StefanKarpinski]

What was the issue here?

[Keno]

Some types don't implement comparison/promotion with Int64, or if they do, it's not what you want, e.g.

using SIUnits
julia> findlast([0m, 1m, 0m])
3

because

julia> 0m == 0
**false**

(arguable that should have been an error instead)

[andreasnoack]

Might be worth making this zero(A[i]) in case eltype(A)=Any

[Keno]

Fair point.

[Keno]

Not sure what happened here. I neither merged nor closed this.

[tkelman]

needs a genstdlib run

[simonbyrne]

If we're going to try to support these sort of things it would be good to make a formal specification of the interfaces that need to be supported. As part of my current work I've been creating yet another unitful computation package, and so I've hit a few of these issues as well.

The current pattern is used in quite a few places throughout Base, as there are some cases where it is more efficient (e.g. BigFloat vs Int has an inequality comparison method which doesn't require allocating a new BigFloat)

[tkelman]

x-ref #15755

[stevengj]

Seems like we should define an iszero(x) = x == zero(x) function, with specialized versions for bignums and arrays that avoids allocations.

[nalimilan]

Are we sure we want 0m != 0 and yet iszero(0m) == true? That sounds potentially confusing to me. Types should either compare with other numbers the standard way, or not compare with them at all. Maybe only the definition of find should be changed?

[stevengj]

@nalimilan. Yes. zero(x) is the additive identity for x. It is not (necessarily) 0. iszero should check whether something is the additive identity. zeros(5,5) == 0 is false, too.

[ararslan]

Out of curiosity, why change findprev and not the other find* functions?

[Keno]

Superseded by the find rework stuff.