Klaus Crusius

IMO that is a good idea, which solves a minor issue with `AbstractArray`. I would like to go a step further: You are right that `AbstractQ` "is not" an `AbstractMatrix`,...

> is a showstopper for this PR ? No, I only wanted to point out, that there is still a way to go for a satisfactory treatment of `AbstractArray` /...

> it just needs a non-mutating branch This branch is already in place. Only problem, it does not recognize, that `PartitionedArray{_,Tuple{SVector,SVector}}` is not mutable. A fix is pending in `RecursiveArrayTools`,...

A fix could look like so: in `DoubleFloats/src/math/errorfree.jl:120` ``` """ two_hilo_sum(a, b) *unchecked* requirement `|a| ≥ |b|` Computes `s = fl(a+b)` and `e = err(a+b)`. """ @inline function two_hilo_sum(a::T, b::T)...

I think, the issue is with all base operations (+, -, *, /), which all return `NaN` in cases when they should return `Inf` or `-Inf`. `` julia> a =...

I think we must first make the base operation correct. The `exp` example should be considered later. ``` julia> d = Double64(Inf, -Inf) Inf julia> d + d NaN julia>...

I agree. Question is where to insert the checks to avoid runtime regression afa possible. I my experience the intermediate terms are "contaminated" with `NaN` , when operations like `Inf...

Consequently all other `*_dddd_dd` should be modified accordingly. But as I see, that `add_dddd_dd` is called many times internally, it is maybe possible to change only in the user-facing situations....

That would work at the cost of one additional `Float64` op. (Actually I did not understand, why the original test for infinity was based on the `NaN`s in the LO...

Your last proposal looks more obvious to me. ( I mean `isfinite(x::Double64) = isfinite(HI(x))`)