Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

long double overload #88

Open
igagis opened this issue Jun 26, 2021 · 8 comments
Open

long double overload #88

igagis opened this issue Jun 26, 2021 · 8 comments

Comments

@igagis
Copy link

igagis commented Jun 26, 2021

Add long double overload for from_chars() to fully mimic std::from_chars. See https://en.cppreference.com/w/cpp/utility/from_chars overload no.4

@lemire
Copy link
Member

lemire commented 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
Copy link
Member

lemire commented Jul 7, 2021

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.

But then, again, pull requests are invited.

@igagis
Copy link
Author

igagis commented Jul 7, 2021

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?

Pseudocode:

from_chars(const char* str, long double& out){
    double value;
    from_chars(str, value);
    out = (long double)(value);
}

@jwakely
Copy link
Contributor

jwakely commented Jan 18, 2022

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.

@alugowski
Copy link
Contributor

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.

@alugowski
Copy link
Contributor

Something that might make sense is the C++23 fixed-width floating-point types: std::float16_t through std::float128_t and std::bfloat16_t.

https://en.cppreference.com/w/cpp/types/floating-point

@lemire
Copy link
Member

lemire commented Jun 22, 2023

@alugowski Agreed.

@dalle
Copy link
Collaborator

dalle commented Nov 23, 2024

On Power systems long double is double double which has a completely different representation from IEEE binary128.

Can std::numeric_limits<T>::is_iec559 be used to disqualify implementations and types that isn't IEEE compatible?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants