Floating point data representations as used in computers have limited accuracy. Not all decimal numbers can be stored with their exact value in a floating point data type on a computer. The numbers are rounded to the nearest value that can be represented.

0.99 for example cannot be represented exactly in a single precision floating point data type. The nearest value that can be stored is exactly 0.990000009536743164062500. The next smaller value is 0.989999949932098388671875, and the next larger value is 0.990000069141387939453125. Therefore, for values near 0.99, the step size between adjacent single-precision floating point values is 0.000000059604644775390625.

When displaying stored values, the MHA parser converts stored floating-point values to decimal representations. When it does, it normally uses 9 significant decimal digits: 0.9900000095367431640625 is rounded to 0.990000010. This is the value that you see for your 0.99 input value, except that the trailing 0 was truncated by the C++ iostream implementation.

We use a default of 9 significant decimal digits because some single-precision floating point numbers require 9 significant decimal digits for unambiguous decimal representation, see e.g.

https://stackoverflow.com/questions/607 ... mal-digits. If you want you can change this by setting the environment variable MHA_PARSER_PRECISION before starting mha or analysemhaplugin, e.g.

Code: Select all

`MHA_PARSER_PRECISION=6 analysemhaplugin my_plugin`

will give you the output that you had expected, but it does so by merely hiding the inherent inaccuracy of floating point values, not by being more accurate.

openMHA like most professional audio signal processing software chooses to do most of its computations with single precision floating point values instead of double precision floating point values because for the intended purpose, producing audio results, practically all inaccuracies caused by the single-precision floating point inaccuracy are already inaudible to human listeners by a large enough margin to also cover accumulated, follow-up inaccuracies.

My suggestion is that once you understand where this unexpected display comes from to not let it bother you.