Use _Float128 where available?

[aragilar]

It's great to see that quad precision exists for numpy! I'm wondering if support for using the standard C type _Float128 would be merged if a PR adding it was created? I spent a fair bit of time around 2016 getting this to work as a patch to numpy, and when I have some spare time I could try to bring that work up to scratch so it could be merged.

[juntyr]

At least on my end we're not married to any particular backend (so far SLEEF). So if there is an alternative, especially a standardised one, that is easier to maintain and extend, I definitely would be interested.

[SwayamInSync]

@aragilar If I am recalling correctly then isn't _Float128 is the alias for __float128?
If this is true then yes we support it directly and in that case numpy_quaddtype's sleef backend will also directly alias the __float128 and use corresponding operations

[aragilar]

I believe it's the other way round, _Float128 is the underlying type and __float128 is the compatibility alias (but I could be wrong, it's been many years since I looked into this in detail), and I vaguely recall seeing somewhere (gcc docs or a gcc issue?) that the "N2601" types (e.g. _Float64) were distinct from the old types (e.g. double), and hence different optimisations/compiler rules were allowed. I think if sleef falls back the complier-based types (I wasn't aware sleef did that), then as long as there's not some subtle complier thing around the "N2601", just using sleef is probably better (given the SIMD support).

Do we know if sleef supports complex quad? I had some issue getting complex quad to work (and I didn't really need it for what I was doing), but I think that was more an issue on my side.

[SwayamInSync]

Do we know if sleef supports complex quad?

I don't think so, didn't see any mention in the docs :)