Boost.JSON test has been added and the old test has been renamed.

[nuald]

No description provided.

[beached]

Shouldn't these floats be doubles? I think Boost.JSON will store them as double internally anyways.

[nuald]

Yes, but looks like it's some precision problem with Boost.JSON - when I used double, it's read 1.1 as 1.1000...00001, so auto-comparison 1.1 == 1.1 failed (I know that it's not quite proper way to compare rational numbers, but I didn't have that problem before). It could be some intermittent problem as I've used HEAD instead of stable release, and using floats fixed that, so I let it slip.

[beached]

both those values are correct, I think. I wonder if a test like

bool are_close( double lhs, double rhs ) {
  std::uint64_t l;
  memcpy( &l, &lhs, sizeof( std::uint64_t ) );
  std::uint64_t r;
   memcpy( &r, &rhs, sizeof( std::uint64_t ) );
  return std::abs( l - r ) < 3;
}

Or something like that

[nuald]

I hesitate to change the testing code, because literally all other code including C++-based (thus using the same doubles internally) don't have this problem. There could be some actual issue in Boost.JSON, but as it's not a stable release, I don't want to do make any conclusions yet. I think I'll test it again when they have the stable release, and if the issue still occurs, I'll dig the actual reason and contact them.

[beached]

I just tested and it's encoding 3.3 as 3.2999999999999998224, others are as 3.3000000000000002665. Both are correct. The test should probably be fixed as 3.3 cannot be encoded as exactly IEEE floating point and they are both on either side of it. The two encodings are 1 ulp apart. std::nextafter might help in the check or if it's just to see if the values are parsing in the correct order, use integers.

[nuald]

Unfortunately, I can't use almostEqual-like comparison utilizing ulps/nextafter as it's not quite portable to other languages (not all of them have rich math libraries). However, I've verified numbers with base 2 (2.0, 0.5, 0.25), and it works fine in tests, I'll update the Boost.JSON code to use doubles, and update other tests to use those numbers too.

[beached]

That seems better. Simple and, assuming they are IEEE754, it should always be exact.

[nuald]

Addressed in #279, verified on all tests, all work correctly, and changed Boost.JSON test to use doubles.

[lemire]

Note that I just tested and it's encoding 3.3 as 3.2999999999999998224, others are as 3.3000000000000002665.

I would expect parsers to always return 3.2999999999999998224 since it is the nearest floating point value. You can verify that it at 1.77 x 10^-16 of 3.3. Meanwhile, the other value you propose is at a distance 2.66 x 10^-16. I would certainly expect your compiler to treat 3.3 as 3.2999999999999998224.