Replace with internal `_iszero` for checks that drop trivial zero, so that `IntervalArithmetic` can extend it.

[hsuknowledge]

The package IntervalArithmetic intentionally raises error for comparisons between an interval enclosing multiple floating-point values and an interval with a single value, so-called thin interval, when the two sets overlap. Base.iszero(x) dispatchs to x == 0 so this is a comparison with a thin interval and will throw if x is an interval covering a zero.

> using IntervalArithmetic
> a = interval(-1, 1) ## spans across zero
> iszero(a)
ERROR: ArgumentError: `==` is purposely not supported for
overlapping non-thin intervals. See instead `isequal_interval`

On the other hand, IntervalArithmetic has a new function that serves the purpose, isthinzero, which allows this comparison to move on and only emit true if x does not enclose any other value.

> isthinzero(interval(-0,0)) ## true
> isthinzero(interval(-0.0,0.0)) ## true
> isthinzero(interval(prevfloat(-0.0),0.0)) ## false
> isthinzero(interval(0.0,nextfloat(0.0))) ## false

This is likely the behavior Polynomials authors want. Please consider adding this support to this package, otherwise end users like me are going to patch it with type piracy and mess up with other dependent packages.

Quoting a maintainer at IntervalArithmetic, a "safe iszero" (inside Polynomials module) approach is suggested.

The recommended approach (followed, e.g., by SparseArrays) is to define your own method defaulting to iszero unless the input is an interval. This allows you to not break IntervalArithmetic (which would occur by directly overloading Base.iszero), preserving reliability, and you get a finer control on the behaviour. E.g.,

module MyModule
# ... some code...
_safe_iszero(x) = iszero(x)
_safe_iszero(x::Interval) = isthinzero(x)
end

[hsuknowledge]

According to how it's been done in SparseArrays, it is suggested that in Polynomials we replace with an internal function _iszero whenever the intention is to test for trivial zeros that can be dropped or trimmed if it occurs as the highest order coefficient. Then, people there can safely extend your _iszero function to apply custom dispatch in their package, without polluting Base.iszero.

[hsuknowledge]

Probably because interval-valued coefficients don't make practical sense, that's why this wouldn't be considered. I can alternatively use simple vectors to store coefficients if all I want is a simplified syntax for adding polynomial functions.

Practically such would not be easily solvable by solving at just the bounds of interval coefficients. I still need to iterate through all possible combinations from those intervals to determine the root bounds. Therefore this has a low priority to be changed.

[hsuknowledge]

Update: well, it seems to me that sampling from 5 equidistant points at each coefficient, turns out to produce results very close to that from calling IntervalRootFinding.roots with interval-valued polynomials, with expected tighter bounds than the latter method. I think this can be a valid use case, then.

results

julia> f ## a custom type that only supports basic arithmetics
IntervalPolynomial{Float64, 6}((
(-0.0850491 ± 1.23016e-7)_com_NG,
(0.00834128 ± 5.41385e-9)_com_NG,
(4.41546e-5 ± 3.6891e-10)_com_NG,
(2.26688e-7 ± 1.91075e-11)_com_NG,
(2.54417e-9 ± 1.13642e-12)_com_NG,
(7.31321e-11 ± 7.75418e-14)_com_NG))

julia> IntervalRootFinding.roots(f, interval(-100, 100))
1-element Vector{IntervalRootFinding.Root{Interval{Float64}}}:
 Root((9.672871588_1 ± 2.6285_7134974e-5)_com_NG, :unique)
9.672845302385344 ## inf
9.672897873812339 ## sup

### sampled from 5^6 = 15625 combinations, then simply hull(roots...; dec=:auto)
julia> sampled_rootregion(f, interval(-100, 100))
(9.672871588_17 ± 2.6285_6336501e-5)_com_NG
9.672845302533334 ## inf, higher than above
9.672897873800633 ## sup, lower than above