Skip to content

Conversation

@TysonRayJones
Copy link
Member

as per the discussions in #645

This allows it to be changed post-compilation/installation, pre-execution, as per the machination in #645

Additionally inserted whitespaces into cmake error message about MacOS multithreading to make the advised commands clearer
which previously made use of stold() to validate that a user-given string contained a number which can be parsed as a qreal. This enabled a bug where users using FLOAT_PRECISION=1 or 2 could specify a number (e.g. in createInlinePauliStrSum) which is well-formed but exceeds the maximum or minimum storable qreal. By using stold() (the long-double version of "string to float"), the validation was too lenient and permitted literals of numbers which can fit into a long-double-qreal but not the current smaller-precision qreal.

We now instead use a string-to-float function specific to the precision of qreal (stof(), stod() or stold()) so that the "can store number as qreal" validation always runs correctly.

We further refactored number parsing in parser.cpp to "trust" the regex and throw an internal error (rather than a user-blaming validation error) when the string-to-float functions fail when the regex assured otherwise. This
and changed DEFAULT_VALIDATION_EPSILON from a macro to an env-var
since float underflow is now detected - confirming the bug (qcomp literals underflowing to zero without a validation message) was silently occurring in our tests!
@TysonRayJones TysonRayJones merged commit eeedec7 into devel Jun 25, 2025
130 checks passed
@TysonRayJones TysonRayJones deleted the env-vars branch June 25, 2025 21:09
@TysonRayJones TysonRayJones mentioned this pull request Oct 13, 2025
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

Successfully merging this pull request may close these issues.

2 participants