You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note that long double is not a well defined type in practice. It appears that Visual Studio might map long double to double. And long double could vary from standard binary128 to other variants.
It appears that long double is system and compiler specific.
Given that fast_float is compiler and system agnostic, it could prove difficult to support long double.
Well, as pointed in the original post, there is a long double overload in the C++ standard. And it is present in the standard regardless of the system/compiler.
I actually don't care at the moment about long double precision, I just care about the API to be more close to the standard, so that when from_chars(float/double/long double) become widely supported by C++ standard library implementations it would be easier to switch to that. Hopefully, those implementations will adopt fast_float implementation under the hood.
So, maybe in context of this issue we could just add long double overload which will do double under the hood?
Well, as pointed in the original post, there is a long double overload in the C++ standard. And it is present in the standard regardless of the system/compiler.
Yes, but that doesn't change anything about what Daniel said.
On Power systems long double is double double which has a completely different representation from IEEE binary128. On x86 long double is an 80-bit "extended precision" type, stored in a 128-bit object. Aarch64 uses binary128. On Windows long double has identical representation to double. So the point is that writing the code for long double needs a lot more effort, and platform-specific knowledge.
Just using double would give incorrect answers. If you're happy to get incorrect answers, you can just use the existing overload for double.
On x86 long double is an 80-bit "extended precision" type, stored in a 128-bit object.
Only on some (most?) x86 Linux. Both macOS and Windows have 64-bit long double.
Ryu shows the peril of supporting this type. They have a generic_128 module to support up to 128-bit floats and provide a helper function for long double, but omit any checks for the size of the type. So on macOS you simply get wrong answers.
Activity
lemire commentedon Jun 26, 2021
This is similar to issue #86
You would probably want to introduce a whole distinct code sequence, akin to our current fallback.
Pull requests invited. Be mindful of the need to prove correctness.
lemire commentedon Jul 7, 2021
Note that
long doubleis not a well defined type in practice. It appears that Visual Studio might maplong doubletodouble. Andlong doublecould vary from standardbinary128to other variants.It appears that
long doubleis system and compiler specific.Given that
fast_floatis compiler and system agnostic, it could prove difficult to supportlong double.But then, again, pull requests are invited.
igagis commentedon Jul 7, 2021
Well, as pointed in the original post, there is a
long doubleoverload in the C++ standard. And it is present in the standard regardless of the system/compiler.I actually don't care at the moment about long double precision, I just care about the API to be more close to the standard, so that when
from_chars(float/double/long double)become widely supported by C++ standard library implementations it would be easier to switch to that. Hopefully, those implementations will adoptfast_floatimplementation under the hood.So, maybe in context of this issue we could just add
long doubleoverload which will dodoubleunder the hood?Pseudocode:
jwakely commentedon Jan 18, 2022
Yes, but that doesn't change anything about what Daniel said.
On Power systems
long doubleis double double which has a completely different representation from IEEE binary128. On x86long doubleis an 80-bit "extended precision" type, stored in a 128-bit object. Aarch64 uses binary128. On Windowslong doublehas identical representation todouble. So the point is that writing the code forlong doubleneeds a lot more effort, and platform-specific knowledge.Just using
doublewould give incorrect answers. If you're happy to get incorrect answers, you can just use the existing overload fordouble.alugowski commentedon Mar 7, 2023
Only on some (most?) x86 Linux. Both macOS and Windows have 64-bit
long double.Ryu shows the peril of supporting this type. They have a
generic_128module to support up to 128-bit floats and provide a helper function forlong double, but omit any checks for the size of the type. So on macOS you simply get wrong answers.alugowski commentedon Jun 21, 2023
Something that might make sense is the C++23 fixed-width floating-point types:
std::float16_tthroughstd::float128_tandstd::bfloat16_t.https://en.cppreference.com/w/cpp/types/floating-point
lemire commentedon Jun 22, 2023
@alugowski Agreed.
dalle commentedon Nov 23, 2024
Can
std::numeric_limits<T>::is_iec559be used to disqualify implementations and types that isn't IEEE compatible?Do not attempt to benchmark fast_float with long double