-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Large floats not accepted anymore #1349
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
Comments
Sorry, I don't like to change/break old behavior. This was our mistake. But now, I wonder whether we can recover the old behavior without reverting that large PR. Somehow, we need big numbers to map to In that case, there is probably a relatively simply way to use |
I'll give it a try to fix. |
Return 1.9.1 functionality where values too large to fit in double are converted to positive or negative infinity. Commit 645cd04 changed functionality so that large floats cause parse error, while version 1.9.1 accepted them as infinite. This is problematic because writer outputs infinity values as `1e+9999`, which could no longer be parsed back. Fixed also legacy Reader even though it did not parse large values even before breaking change, due to problematic output/parse asymmetry. `>>` operator sets value to numeric_limits::max/lowest value if representation is too large to fit to double. [1][2] In macos value appears to be parsed to infinity. > | value in *val* | description | > |--------------------------|-------------| > | numeric_limits::max() | The sequence represents a value too large for the type of val | > | numeric_limits::lowest() | The sequence represents a value too large negative for the type of val | [1] https://www.cplusplus.com/reference/istream/istream/operator%3E%3E/ [2] https://www.cplusplus.com/reference/locale/num_get/get/ Signed-off-by: Tero Kinnunen <[email protected]> Co-authored-by: Tero Kinnunen <[email protected]>
…e-parsers#1353) Return 1.9.1 functionality where values too large to fit in double are converted to positive or negative infinity. Commit 645cd04 changed functionality so that large floats cause parse error, while version 1.9.1 accepted them as infinite. This is problematic because writer outputs infinity values as `1e+9999`, which could no longer be parsed back. Fixed also legacy Reader even though it did not parse large values even before breaking change, due to problematic output/parse asymmetry. `>>` operator sets value to numeric_limits::max/lowest value if representation is too large to fit to double. [1][2] In macos value appears to be parsed to infinity. > | value in *val* | description | > |--------------------------|-------------| > | numeric_limits::max() | The sequence represents a value too large for the type of val | > | numeric_limits::lowest() | The sequence represents a value too large negative for the type of val | [1] https://www.cplusplus.com/reference/istream/istream/operator%3E%3E/ [2] https://www.cplusplus.com/reference/locale/num_get/get/ Signed-off-by: Tero Kinnunen <[email protected]> Co-authored-by: Tero Kinnunen <[email protected]>
Not fixed by 1.9.6 In the following code , for a token of
|
Describe the bug
Version 1.9.2 no longer accepts
1+e9999
(or2e+308
and anything above), regardless ofallowSpecialFloats
setting.To Reproduce
Steps to reproduce the behavior:
Expected behavior
1e+9999 -> inf
Actual behavior:
Desktop (please complete the following information):
Additional context
1e+9999
as infinite, regardless ofallowSpecialFloats
setting.2e+308
or above, regardless ofallowSpecialFloats
setting.Specifically breaking change seems to be commit 645cd04 "Number fixes (#1053)".
The text was updated successfully, but these errors were encountered: