Hi Tommi, I would appreciate a new release, as well.
Andreas Am 09.09.2014 um 19:37 schrieb Martin Gansser: > > 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 ------------------------------------------------------------------------------ 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
