0 + x = x/2

[juntyr]

thanks to my fuzzer

import numpy_quaddtype

0 + numpy_quaddtype.QuadPrecision("6.724206286224186953608055004397316e-4932")
# prints QuadPrecision('3.362103143112093476804027502198658e-4932', backend='sleef')

[juntyr]

@SwayamInSync I don't even know ;(

[ngoldbaum]

Does it trigger if you do this operation in C using SLEEF directly? If so it's a SLEEF bug.

[juntyr]

That's a good question but I no longer have my build env setup for sleef so maybe it's quicker for somebody else to test

[SwayamInSync]

From just looking it seems SLEEF issue, 3.362103143112093476804027502198658e-4932 this is the smallest_normal value for a float128 and what you've in input is seems 2x of the smalles_normal

I'll check this

[SwayamInSync]

Yup SLEEF 3.8 issue

~/temp/OSS$ bash run_sleef.sh
x = 6.724206286224186953608055004397315806e-4932
y = 0.000000000000000000000000000000000000e+00
y + x (0 + val) = 3.362103143112093476804027502198657903e-4932
x + y (val + 0) = 6.724206286224186953608055004397315806e-4932

Sleef_addq1_u05(y, x) where y=0 and x is a very small number → Returns half the value! (3.36e-4932)
Sleef_addq1_u05(x, y) where x is a very small number and y=0 → Returns correct value (6.72e-4932)

BTW the the reverse order works correctly, have to inspect the implementation of Sleef_addq1_u05 (possibly this issue might also be with the other ops, have to check them)

Maybe I should also run this with the latest sleef version as well

[SwayamInSync]

@ngoldbaum I just checked and SLEEF (build from source) fixed this issue (maybe because it relies on another tlfloat library for such computations)

(base) ➜  sleef git:(master) ✗ cd /Users/swayam/Desktop/numpy_dtypes && bash run_sleef_main.sh
val + 0 = 6.724206286224186953608055004397315807e-4932
0 + val = 6.724206286224186953608055004397315807e-4932

So I can update the entire package and workflows to use the latest build, if this sounds good to you?

[SwayamInSync]

Its just in their latest version Sleef_strtoq does not follow the standards strtod-like behaviour which can lead to significant code changes in string parsing helpers.
But I think this is what we have to do ourselves if we require functional correctness, raising issues might not work as well

Our project provides only the current and previous versions of
software free of charge. No other materials and services are provided
free of charge unless they are explicitly stated to be free of
charge.
If you want us to process your issue, you will need to pay a fee. The
specific amount you need to pay will be determined by negotiation,
depending on the nature of the issue and your project. If a
significant percentage of those who will benefit from the change you
want to make are considered to be direct or indirect customers of your
company, you will be required to pay a fee.
By becoming a sponsor of our project, you will receive a substantial
discount on the cost of processing your issue.
It is still possible to create an issue without paying a fee, but in
that case we will not process your issue.
If you have any questions, please contact us before creating an issue.
Simply remove this notice when you create an issue.

But this is doable so if sounds right I can start a PR on this

[juntyr]

Upgrading sounds like a good idea then, thanks for investigating @SwayamInSync!

[ngoldbaum]

Yeah, seems worth updating if that's not too painful.