Best to keep the issues together rather than open a new one. We can borrow from boost but can't use c++, so some work would be needed, especially for the Python long type which is not stored as a common integer type. We could always go through a string, but that seems a bit unwieldy.

Which issue is this a duplicate of? I only added the bug because I couldn't find one.

(#5272 just says to rename float128 to be float80_96 or float80_128 depending on the platform, which is different from implementing float128).

If you mean true ieee quad precision, there should be something somewhere. Note that it is not generally supported by C, which has only the long double type, so it gets more complicated, especially if you want to support trig functions and such. There are some mailing list posts if that is what you mean, but adding the quad type would be some significant work. Note that gcc provide a library for that.

To be honest, I'm not really interested in this feature. I only created the bug because I couldn't find it.

I think it would be very worthwhile to have a proper float128, so having an open issue to track that seems appropriate.

As I have been implementing yet another class using a hack with two doubles, thought I'd ping here. It seems there is an IEEE standard for proper float128 and gcc supports it on what seems a very complete list of processors [1].

It seems fine if this would just replace the current float128.

[1] https://www.gnu.org/software/libc/manual/html_node/Mathematics.html

What about other compilers? A GCC-specific change will just make the confusion worse I'm afraid.

Maybe we should deprecate the float128 name? If users switch to np.longdouble instead, the name clears up for proper 128bit IEEE floating point numbers.

float128 and float96 seem much clearer than `longdouble'.

@NeilGirdhar yes, but they are also completely misleading and ill defined. longdouble at least is clear about mapping to the C long double definition.

@rgommers - some googling suggests both the llwm and the intel compiler also support it, though the latter perhaps not trivially (but presumably we can get some help from the intel folks). Are there other compilers are you thinking about?

Since currently np.float128 is not guaranteed to exist either, I'm not sure the situation will be worse than it is now. At least, if it exists, it will have consistent behaviour...

Deprecating float128 in favour of longdouble would seem to make sense - as noted, it at least has the benefit of not suggesting what precision or storage requirement the type has. Though there still is a question of how to represent it in a dtype.

But the good news is that while we may cause performance loss for the rare users that use the current longdouble, we cannot cause precision regressions.

@seberg I understand the draw of having this match C's definition of long double, but this is going to cause problems when GPUs start supporting float128. I like the suggestion in #5272 to rename float128 to be float80_96 or float80_128 depending on the platform, and then make float128 the true quadruple precision float. longdouble doesn't fit within numpy's very elegant naming scheme.

@NeilGirdhar I was merely thinking we could try to Deprecate or if we already know we can pull of true float128 now Future warn float128, naming it differently, such as float80_96 would seem good (although I am not sure that is correct on Macs? Weren't they double-double users?).

@rgommers - some googling suggests both the llwm and the intel compiler also support it, though the latter perhaps not trivially (but presumably we can get some help from the intel folks). Are there other compilers are you thinking about?

MSVC mainly.

Hmm, MSVC status seems rather unclear for quad precision. Though I'm not sure it is better to have a regular double inside a float128, as I gather is the case now according to the numpy docs. cc @eric-wieser in case he knows.

Also - there will be users who have saved e.g. npy files with float128 / float96 type, where float128 is in fact padded float80. If you re-purpose float128, you'll break those files.

@matthew-brett Can't you just bump the npy version number?

I guess - maybe with some extra code to cast the loaded data to the new types, say float80_128. This just a marker to remind us that we will need those types, and to do those changes.