FEAT: Implementing same_value casting rule in quaddtype

[SwayamInSync]

closes #153

As per the title

[juntyr]

Thanks @SwayamInSync for your work! My comments are mostly nits and extra tests, I'll review again afterwards

[SwayamInSync]

New things fixed and added

• For supporting -nan in strings, dragon4 has to preserve the sign in output to ensure the complete roundtrip
• Sleef's vendored methods for casting to/from double aren't all supportable over platforms, can cause discripencies so we are explicitly handling those cases.

[juntyr]

we have a const for negative zero

[SwayamInSync]

There's a subtle issues in using that, we didn't used QUAD_PRECISION_NEG_ZERO anywhere because qutil gave the logical representation but the sign information is stored in the actual IEEE 754 binary format, not in the integer literal itself. Basically the sign is encoded in the high mantissa bits. Simply putting a minus sign in front of 0x0 doesn't create a negative zero representation.

I can replace it with a valid representation maybe in future PRs, for now that is just an artifact in the code.

[juntyr]

LGTM with minor nits addressed

[ngoldbaum]

@mattip any chance you have time and interest to look this over?

[SwayamInSync]

Details for easing the review process

Only casts.cpp and test_quaddtype requires the major review, I added comments wherever I made the changes to give reasoning for that step, the rest files are modified for the caues listed below

Small refactoring

• quad_value union with __float128 causes lot of ABI & compiler optimization issues in C++, hence refactoring the methods to not perform any kind of copy of this passed union instead use pointers
• Inter-backend operation is broken in previous builds, not sure why someone wants to go in that direction, but just for the sake of completeness I fixed it here as well, to implement the same_value casting between QuadPrecision with different backends
• Remove the aligned/unlaigned separate loops with their templated versions

This is still valid, outside this are just tweaks and refactoring to make things work in stable manner

[mattip]

I can take a look after Jan 11.

[ngoldbaum]

@SwayamInSync do you mind waiting a couple weeks on this? I'd like to have Matti look because he added same_value casting and also has a try at this in #161.

In the meantime: one thing that would help is to make the PR more atomic. There's a fair amount of renaming and other stuff like that you could do in another PR then rebase this once the other PR is merged to reduce the diff size.

In general I'd much rather review several smaller more focused PRs rather than one big PR.

[juntyr]

I was hoping for a faster timeline to the release (since numpy-quaddtype is used in my research) but life is life and I'll adapt my own timelines if need be

[SwayamInSync]

@SwayamInSync do you mind waiting a couple weeks on this? I'd like to have Matti look because he added same_value casting and also has a try at this in #161.

In the meantime: one thing that would help is to make the PR more atomic. There's a fair amount of renaming and other stuff like that you could do in another PR then rebase this once the other PR is merged to reduce the diff size.

In general I'd much rather review several smaller more focused PRs rather than one big PR.

Right, I also didn't want to make it this big, but it the design choice of using union with SIMD types in C++ gave a lot of ABI breaks (as __float128 isn't standard so on x86-64 machines, doing careless copies gives heisenbugs)
I can do some independent refactor PRs, and since we are allowing some time window I'll also get some work to do on docs 😄

[SwayamInSync]

Cool so the diff got down now, mostly again covered by casts.cpp and tests