Floating point conversion to string precision loss fix for Chunk's du…

[indivisibleatom]

…ration

It seems that Python's %f formatting defaults to 6 digits. However, this precision is not sufficient within Chunks. str(float) uses higher precision. Specifically, a this (should) Fix #25 . This is not a fool-proof fix, but, add extra precision, and enables the Python path for the set of data I am working with. The fool proof way, for those who desire it, would be to use the C++ pathway only, or write more complex, bit-wise accurate serialization / deserialization of floats being passed around in strings across the Python and C++ interface.

#25 seems to be caused the by following control-flow:
a) QuadraticConstraints are created in Python using higher precision values of chunk durations which is used when populating constraint vectors in ComputeKinematicConstraints in TOPPPy.py. Specifically, ndiscrsteps is computed using trajectory duration.
b) The PiecewisePolynomial trajectory is serialized to string and transmitted when a TOPPInstance is created (in test code / app code written by user) -- here, currently, low precision chunk duration is used.
c) The received string is unserialized, and the trajectory duration, and the ndiscrsteps are computed in Constraints::Preprocess in TOPP.cpp. Due to precision loss, this can be different (and, even more) than ndiscrsteps computed in python code.
d) Then, TOPP::QuadraticConstraints::InterpolateDynamics uses the above computed value to index into vectors that were created in Python (avect, bvect, etc). This might cause out of bounds indexing of the array, giving =>
received signal SIGSEGV, Segmentation fault.
0x00007f600b042eb0 in TOPP::QuadraticConstraints::InterpolateDynamics

Quick check on fix:
On Python3 --

print('%s' %(str(0.000534543)))
0.000534543
print('%f' %(0.000534543))
0.000535

Also, https://stackoverflow.com/questions/20586011/python-precision-in-string-formatting-with-float-numbers.

[quangounet]

Great fix, thanks @indivisibleatom !