Skip to content

long double overload #88

Open
Open

Description

@igagis

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

Activity

  1. lemire commented on Jun 26, 2021

    @lemire
    Member

    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.

  2. lemire commented on Jul 7, 2021

    @lemire
    Member

    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.

  3. igagis commented on Jul 7, 2021

    @igagis
    Author

    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);
    }
  4. jwakely commented on Jan 18, 2022

    @jwakely
    Contributor

    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.

  5. alugowski commented on Mar 7, 2023

    @alugowski
    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.

  6. alugowski commented on Jun 21, 2023

    @alugowski
    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

  7. lemire commented on Jun 22, 2023

    @lemire
    Member

    @alugowski Agreed.

  8. dalle commented on Nov 23, 2024

    @dalle
    Collaborator

    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions