From: Aaron J. <ja...@go...> - 2011-05-26 23:05:07
|
Wow, that's crazy. I think your solution to the first problem is good. For the second, maybe the best would be to *parse* the floating point string to be checked, checking that it parses successfully and differs from the original double by no more than 0.1% or whatever? On Thu, May 26, 2011 at 5:45 PM, Baptiste Lepilleur <bap...@gm...> wrote: > > > 2011/5/25 Aaron Jacobs <ja...@go...> >> >> Hmm, but does it make sense to say a default constructed value is all >> of null, an array, and an object? Wouldn't it make more sense to have >> isArray (and only isArray) start returning true once the value is >> "turned into" an array by appending something to it? >> >> I'd appreciate if you could investigate the VC++ issues; I don't have >> easy access to a Windows machine. > > The unit test failures are real strange: > double x = kint64max; > double y = val.asDouble(); > int count = 0; > if ( y == x ) // OK (case 1) > { > ++count; > } > if ( double(kint64max) == y ) // BAD (case 2) > { > ++count; > } > Looking at the assembly, the only difference I see is that in the first case > the x value (kint64max) is loaded from the local variable, while in the > second case it never leave the FPU register if I understand correctly. My > guess is that we are stumbling into the fact that FPU register have an > internal precision of 80 bits. I'm not sure how to confirm this though... > Case 1: > if ( y == x ) > 00411B97 fld qword ptr [ebp-290h] > 00411B9D fcomp qword ptr [ebp-2A0h] > 00411BA3 fnstsw ax > Case 2: > if ( double(kint64max) == y ) > 00411BB9 call std::numeric_limits<__int64>::max (412D60h) > 00411BBE mov dword ptr [ebp-0A4Ch],eax > 00411BC4 mov dword ptr [ebp-0A48h],edx > 00411BCA fild qword ptr [ebp-0A4Ch] > 00411BD0 fcomp qword ptr [ebp-2A0h] > 00411BD6 fnstsw ax > I worked-around this by making code match case 1... > > There is another kinds of test failures that occurs related to how floating > pointer number are represented as string. With MSVS AFAIK we always get > three digits in the exponent. Here are some examples of failures: > 1>* Detail of ValueTest/integers test failure: > 1>..\..\src\test_lib_json\main.cpp(582): "1.04858e+06" == val.asString() > 1> Expected: '1.04858e+06' > 1> Actual : '1.04858e+006' > > * Test E:\prg\vc\Lib\jsoncpp-trunk\test\data\test_real_09.json > Difference in input at line 1: > Expected: '.=1.9e+19' > Actual: '.=1.9e+019' > The easiest is probably to normalize floating point string before > comparison. What do you think? > Baptiste. |