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

json float parsing problem #98

Closed
TmsKtel opened this issue Jun 24, 2015 · 6 comments
Closed

json float parsing problem #98

TmsKtel opened this issue Jun 24, 2015 · 6 comments
Assignees

Comments

@TmsKtel
Copy link

TmsKtel commented Jun 24, 2015

int main()
{
    std::string s = "{\"num\" : 1.0}";
    json p = json::parse(s);
    json a = p["num"];

    if(a.is_number_integer())
    {
        std::cout<<"this is int\n";
    }

    if(a.is_number_float())
    {
        std::cout<<"this is float\n";
    } else
    {
        std::cout<<"this is not a number\n";
    }

    return 0;
}

The above code complies without problem, but the output is:
this is int
this is not a number

@nlohmann
Copy link
Owner

This is correct. The parser will store number values as integers where possible. 1.0 will hence be treated as 1. JSON itself has no concept of "number type", so there is no way to "force " a library to choose a specific type. I am sorry about the inconvenience.

@TmsKtel
Copy link
Author

TmsKtel commented Jun 24, 2015

Ah alright.
Thank You for feedback.

@TmsKtel TmsKtel closed this as completed Jun 24, 2015
@nlohmann
Copy link
Owner

(As a background: The parser needs to decide how to store a read number. Without knowing whether it is a floating-point or integer number, I chose the following strategy:

  1. Convert the number-string to a float.
  2. Convert the number-string to an integer.
  3. Compare the integer with a conversion of (1) to an integer.

If (3) does not yield precision loss, value (2) is used (integer). Otherwise, value (1) is used (floating-point).)

@ropuls
Copy link

ropuls commented Jun 25, 2015

Hi Niels,

stupid question, but why not make the decision based on the presence of a floating point separator (aka a dot). In my understanding, the parser will have a character representation of the number at some point, or may conditionally branch when encountering a dot inside a number.

i.e.

  • "1" => int
  • "1.0" => float
  • "1.2" => float
  • "1." => float

Thanks and cheers,
R.

@TmsKtel
Copy link
Author

TmsKtel commented Jun 25, 2015

+1 for that.
I would personally expect 1.0 parsed to be a floating point. As You can see I immidiately thought this was a bug without looking into the parser.

@nlohmann
Copy link
Owner

It's not that simple:

"10E-3" = 0.01 (not containing a dot, but negative exponent)
"1000E-3" = 1 (not containing a dot, but negative exponent)
"1.1E3" = 1100 (containing a dot and positive exponent)
"1.147E2" = 114.7 (containing a dot and positive exponent)

I understand your idea, but since JSON does not specify a format for numbers, a JSON library cannot guarantee that it stores numbers in the "correct" format - it can only make sure that it stores them without loosing too much precision. Therefore, I try to use the integer type (int64_t by default) where possible and the floating-point type (double by default) where necessary.

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

No branches or pull requests

3 participants