--- 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

> > 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]
> >
> >
> > 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 ?
> >

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Tntnet-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tntnet-general

Reply via email to