Replace v == zero(v) with _iszero

[OlivierHnt]

The purpose of this PR is to not call == directly, and use _iszero instead. This is to help integration with IntervalArithmetic.jl since == for our Interval type does not always return a Boolean.

Closes #609.

I did not change two checks using === since this would break the behaviour for -0.0. If I understood correctly, it should not be an issue with Interval, since it will return false consistently (it may be sub-optimal, but not wrong)
cc @dpsanders, @Kolaru
cc also @kalmarek, since you raised JuliaIntervals/IntervalArithmetic.jl#628 you may have more experience mixing SparseArrays and IntervalArithmetic

I do not know how to the backporting procedure works, but it'd be great to have this for 1.10 and 1.11.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.08%. Comparing base (f3610c0) to head (974a391).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #610   +/-   ##
=======================================
  Coverage   84.08%   84.08%           
=======================================
  Files          12       12           
  Lines        9192     9192           
=======================================
  Hits         7729     7729           
  Misses       1463     1463           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ViralBShah]

@SobhanMP

[LilithHafner]

I did not change two checks using === since this would break the behaviour for -0.0. If I understood correctly, it should not be an issue with Interval, since it will return false consistently (it may be sub-optimal, but not wrong)

You're right not to change those checks and why. They are actually necessary for correctness in the case of Intervals, too! For example, with _iszero, if you set an entry to be an ungarunteed zero interval and then accessed that entry it would have the isgarunteed flag incorrectly set. (Also, the === check will return true sometimes (e.g. on I"0")).

I'm happy to merge this PR but hesitant to mark it for back porting because of how many edge cases sparse arrays tend to have. I'm not opposed to someone else backporting if they are more confidant than I that there won't be unintended consequences.

[OlivierHnt]

@LilithHafner

Thanks for reviewing the PR. Indeed we must be cautious with such changes.
My argument in favour of backporting this PR is that the _iszero and _isnotzero mechanism is already implemented in 1.10 and 1.11. So backporting this PR is really just about merging the same changes in the same functions for 1.10 and 1.11 (if these changes are safe here, they are safe to backport).
See e.g. on 1.11

SparseArrays.jl/src/sparsematrix.jl

Line 2443 in 2420351

(v == zero(T) || nnzA == 0) ? v : v*Base._mapreduce(f, op, nzvalview(A))

I might be overlooking something, but it seems that these 6 instances of using == to check whether the value is zero were unintentionally left out when _iszero and _isnotzero were introduced.

[LilithHafner]

For folks considering backporting, the semantic changes here are, AFAICT:

• Change error to false in the case of non-true result from == zero
• Enable user specialization on iszero (previously we bypassed that by using == zero directly)

The latter could theoretically break things, though that seems implausible. I'm not opposed to another maintainer choosing to backport.

[SobhanMP]

@LilithHafner Thanks for reviewing this!