Allow pointwise equality

[OlivierHnt]

I gained a better feeling of all the changes we made in v0.22 after updating a bunch of code I have.

One recurrent and painful item was dealing with iszero and isone, which both @lbenet and @timholy raised concerns about. For instance, in PR #586, the removal of iszero broke ForwardDiff compatibility. At the time, I felt that this was not so bad since there was a potential hook.

Yet, I also realised that this also breaks SparseArrays which is presumably much more difficult to fix (it does not seem realistic to ask the entire ecosystem to provide us for a hook...). E.g

julia> C = interval(sparse(rand(2, 2)))
2×2 SparseMatrixCSC{Interval{Float64}, Int64} with 4 stored entries:
 [0.440162, 0.440163]_com  [0.886892, 0.886893]_com
 [0.127834, 0.127836]_com  [0.372157, 0.372158]_com

julia> C .+= C
ERROR: ArgumentError: `==` is purposely not supported for intervals. See instead `isequal_interval`
...

Additionally, because iszero and isone are pointwise by nature, they can not yield ambiguous answers: the interval is, or not, a zero/one singleton.
This is in stark contrast with other boolean operations which are rightfully disallowed; to illustrate:

• < also implies some ordering, which may lead to ambiguous answers
• isfinite may be ambiguous depending on the flavour (but could be brought back by using @Kolaru's flavour mechanism...)
• isnan conflicts with isnai

Therefore, I am proposing to bring back iszero and isone. Moreover, our function isthin(::Interval, ::Number) is by definition just a generalisation of isthinzero and isthinone for any Number. Thus, ==(::Interval, ::Number) is safe if iszero and isone are considered safe.
Lastly, I think that isinteger is also safe since integers are necessarily finite.

Note

I think this is not a breaking PR as isthinzero/isthinone/isthin/isthininteger would still be defined and exported.
However, if we do end up liking these changes by the end of 0.22; I think we ought to remove isthinzero/isthinone/isthin/isthininteger for the 1.0 release as we should not have distinct functions do the same operation.

[codecov-commenter]

Codecov Report

Attention: 18 lines in your changes are missing coverage. Please review.

Comparison is base (a105724) 84.72% compared to head (a60d608) 84.30%.

Files	Patch %	Lines
src/intervals/interval_operations/boolean.jl	17.64%	14 Missing ⚠️
src/intervals/real_interface.jl	80.00%	4 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #604      +/-   ##
==========================================
- Coverage   84.72%   84.30%   -0.42%     
==========================================
  Files          23       23              
  Lines        2049     2077      +28     
==========================================
+ Hits         1736     1751      +15     
- Misses        313      326      +13     

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

[Kolaru]

That's painful.

I guess however that this is mostly vocabulary. I assume iszero is used to mean "the additive neutral element", which is indeed true for (0..0).

And iszero(x) should be equivalent to x == 0, so I think we have no choice to define ==.

I think our version of == need a docstring to clarify what we are doing. Except for that, I'm fine with the change.

[OlivierHnt]

Good point. I added a docstring with a "note admonition" to highlight the fact that we handle equality between two intervals differently.