python float to C++ double (Real) - Precision problem

[ddeconinck]

I noticed that when python floats are converted to C++ doubles the precision is somewhere around 6, the rest of the decimals are truncated. Unfortunately this is too low for our applications.

I took a look in PythonAny.cpp but I did not find any way to control this precision. Any ideas? Thx

[barche]

If there is loss of precision, it is unintended. Python floats are double precision, so there should be no loss in the conversion. Could you provide a test-case, then I'll see if I can track down where this is coming from.

[ddeconinck]

I have a component with a signal "assign" which takes an argument "value" of type Real (double). In the signal, the value gets printed to screen with precision 20.

void Constant::signal_assign( common::SignalArgs& args)
{
  common::XML::SignalOptions opts(args);
  std::cout << std::setprecision(20) << opts.value<double>("value") << std::endl;
}

The output of this code in python is as follows:

>>> import coolfluid as cf
>>> cf.root.create_component("q", "cf3.muphys.quantities.Constant")
cpath:/q
>>> cf.root.q.assign(value=1.2345678901234567890)
1.2345699999999999452

This indicates that the argument "value" is truncated to the 6th significant digit.

I noticed that this truncation does not happen to the same extent when assigning options. The "Constant" component has an option "alphaf" of type Real.

>>> cf.root.q.alphaf = 1.2345678901234567890
>>> print "%.20f" % cf.root.q.alphaf
1.23456789012345669043

thus, a precision to the 16th significant digit.

[barche]

OK, this makes sense: signals are converted to XML, so I think the string representation is insufficient to keep the precision. I'll look into fixing this.

[barche]

I pushed a fix for this to main, the problem was indeed the conversion to strings. Should you still see an issue with this, please extend utest-python-math to capture the problem.

[ddeconinck]

Bedankt Bart, het werkt!

Groetjes, Daan

On 12 Aug 2013, at 00:24, Bart Janssens notifications@github.com wrote:

I pushed a fix for this to main, the problem was indeed the conversion to strings. Should you still see an issue with this, please extend utest-python-math to capture the problem.

— Reply to this email directly or view it on GitHub.