Hi,
any luck to have a new version available with your correction ? Martin Gesendet: Montag, 28. Juli 2014 um 19:03 Uhr Von: "Tommi Mäkitalo" <[email protected]> An: [email protected] Betreff: Re: [Tntnet-general] cxxtools-2.2.1-4.fc21 ppc64le - std::numeric_limits<double>::max() returns 1.79769e+308 Hi, I checked in a different solution. Your solution do not work correctly when using long double. Note that the max value in SerializationInfo::_getFloat may be std::numeric_limits<long double>::max, which should not be multiplied with a number larger than 1. So I changed the limit values passed to _getFloat when extracting float or double values. Tommi Am 28.07.2014 15:47, schrieb Martin Gansser: > --- Comment from Menanteau Guy --- > > New patch to accept slightly larger value than double max. > https://bugzilla.redhat.com/attachment.cgi?id=921759 > is this ok and can this be go to upstream ? > > thanks > > >> Gesendet: Freitag, 25. Juli 2014 um 20:14 Uhr >> Von: "Tommi Mäkitalo" <[email protected]> >> An: [email protected] >> Betreff: Re: [Tntnet-general] cxxtools-2.2.1-4.fc21 ppc64le - >> std::numeric_limits<double>::max() returns 1.79769e+308 >> Hi, >> >> I looked at the patch and I guess it does not solve the problem. >> >> The double value is still converted to long double, then to decimal and >> back to long double. Somewhere in this chain a rounding error increases >> the value slightly, that it is too large to fit into a double. >> >> The solution is to accept a slightly larger value than double max. If >> the value is just slightly bigger, it should be converted to double max. >> >> Tommi >> >> Am 24.07.2014 14:49, schrieb Martin Gansser: >>> --- Comment from Menanteau Guy --- >>> >>> I understood the problem of rounding error due to diffrent precision between >>> float and double but I don't see why not just process double as double >>> instead >>> of float. >>> I did a patch to handle serialization double as double for casting and test >>> is >>> succesfull now. Note that there was no need to create a new t_double type in >>> serializationinfo.h. >>> >>> Please could you have a look to the linked patch. >>> >>> https://bugzilla.redhat.com/attachment.cgi?id=920168[https://bugzilla.redhat.com/attachment.cgi?id=920168] >>> >>>>> Gesendet: Montag, 07. Juli 2014 um 21:01 Uhr >>>>> Von: "Tommi Mäkitalo" <[email protected]> >>>>> An: [email protected] >>>>> Betreff: Re: [Tntnet-general] cxxtools-2.2.1-4.fc21 ppc64le - >>>>> std::numeric_limits<double>::max() returns 1.79769e+308 >>>>> Hi, >>>>> The problem is a rounding error when converting double to decimal and >>>>> back. >>>>> >>>>> The xmlserializer do not use scientific notation but converts floating >>>>> point values to decimal, so that the maximum double value results in >>>>> something like "17976900000000000000000000000000000000000000.....". >>>>> Internally long double is used in serialization and due to rounding >>>>> errors it may really happen, that the max double converted to long >>>>> double converted to a string and back to double max do exceed the range. >>>>> >>>>> The solution may be to accept slightly larger values than max-double. >>>>> >>>>> The actual code, which results in the error can be found in >>>>> include/cxxtools/serializationinfo.h and src/serializationinfo.cpp: >>>>> >>>>> serializationinfo.h: >>>>> >>>>> void getValue(double& value) const >>>>> { value = static_cast<double>(_getFloat("double", >>>>> std::numeric_limits<double>::max())); } >>>>> >>>>> serializationinfo.cpp: >>>>> long double SerializationInfo::_getFloat(const char* type, long double >>>>> max) const >>>>> { >>>>> ... >>>>> if (ret != std::numeric_limits<long double>::infinity() >>>>> && ret != -std::numeric_limits<long double>::infinity() >>>>> && ret == ret // check for NaN >>>>> && (ret < -max || ret > max)) >>>>> { >>>>> std::ostringstream msg; >>>>> msg << "value " << ret << " does not fit into " << type; >>>>> throw std::range_error(msg.str()); >>>>> } >>>>> >>>>> A possible fix is to change the acceptable limits of double to a >>>>> slightly larger value: >>>>> >>>>> serializationinfo.h: >>>>> >>>>> void getValue(double& value) const >>>>> { value = static_cast<double>(_getFloat("double", >>>>> static_cast<long >>>>> double>(std::numeric_limits<double>::max()))*1.0000000001); } >>>>> >>>>> The same should be done with float type. What do you think? >>>>> >>>>> Question: what happens, when a long double value is really too large and >>>>> it is casted to double? >>>>> >>>>> >>>>> Tommi >>>>> >>>>> >>>>> Am 07.07.2014 13:30, schrieb Martin Gansser: >>>>> Bug Report on: >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1108800[https://bugzilla.redhat.com/show_bug.cgi?id=1108800][https://bugzilla.redhat.com/show_bug.cgi?id=1108800[https://bugzilla.redhat.com/show_bug.cgi?id=1108800]][https://bugzilla.redhat.com/show_bug.cgi?id=1108800[https://bugzilla.redhat.com/show_bug.cgi?id=1108800][https://bugzilla.redhat.com/show_bug.cgi?id=1108800[https://bugzilla.redhat.com/show_bug.cgi?id=1108800]]] >>>>> >>>>> >>>>> Description of problem: >>>>> running test (make check) of cxxtools package on ppc64le arch, I get an >>>>> error on test:xmlserializer::testDouble >>>>> problem occurs at testDoubleValue(std::numeric_limits<double>::max()); >>>>> value returned is 1.79769e+308 and later in the test following exception >>>>> is raised: >>>>> EXCEPTION: >>>>> value 1.79769e+308 does not fit into double >>>>> >>>>> Version-Release number of selected component (if applicable): >>>>> cxxtools-2.2.1-4.fc21 ppc64le >>>>> gcc-4.9.0-6.fc21 ppc64le >>>>> >>>>> Actual results: >>>>> xmlserializer::testDouble: EXCEPTION >>>>> value 1.79769e+308 does not fit into double >>>>> >>>>> Back to this problem, I understood value 1.79769e+308 is correct for the >>>>> maximum value of a type double. >>>>> This means the problem is not relative to gcc. I change component to >>>>> cxxtools for now. >>>>> >>>>> Is there any advice ? >>>>> > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk[http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk] > _______________________________________________ > Tntnet-general mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tntnet-general[https://lists.sourceforge.net/lists/listinfo/tntnet-general] ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk[http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk] _______________________________________________ Tntnet-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tntnet-general[https://lists.sourceforge.net/lists/listinfo/tntnet-general] ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Tntnet-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tntnet-general
