incorrect square function

[nschaeff]

As far as I understand, the square_dd_dd function returns a pair of values that may overlap:
For instance if zlo is zero, 2*alo overlaps with ahi.
A call to Fast2Sum is needed at the end to ensure "normalization".

DoubleFloats.jl/src/math/ops/op_dd_dd.jl

Line 45 in c085185

@inline function square_dd_dd(a::Tuple{T,T}) where {T<:IEEEFloat}

[nschaeff]

Also, in this function, I think (not 100% sure though) that one could ommit zlo = fma(alo, alo, zlo) as alo*alo is always non-significant compared to 2*alo*ahi added just after.

[JeffreySarnoff]

@nschaeff Thank you for the considered comments.
I have just tested this, with and without LO(x) being zero, over random ranges 0.0:{1e-115, 1e-15, 1e-5, 1e18}, running the tests 90_000_000 times with and without LO(x) being zero. No results required renormalization.
This is not the last word -- as that should be provable.

[nschaeff]

Strange, I just tried a few numbers and all of them required renormalization. For instance:
hi=1.0 and lo = 1.11e-16

[JeffreySarnoff]

still ..

using DoubleFloats
hi=1.0
lo=1.11e-16
DoubleFloats.two_sum(hi, lo) == (hi, lo) # true
a = Double64(hi, lo)
HILO(a) == (hi, lo) # true
aa = a * a
asqr = square(a)
aa == asqr # true
HILO(asqr) # (1.0000000000000002, -4.4604925031299906e-20) 
DoubleFloats.two_sum(HILO(asqr)...) == HILO(asqr) # true, result is renormalized

[nschaeff]

The fact that you have the HI result not equal to one, means there has been some renormalization, but it is not inside the square fucntion (as you can see, it returns zhi = ahi*ahi = 1 in this case).
It probably happens when you construct the Double64 value in the function square_db_db that calls square_dd_dd.
My mistake, sorry for the false alarm !