CHOP float precision

Hello,

I’m reporting an issue I encountered while attempting to manipulate small float values in CHOPs, as I’ve noticed that float precision varies between operators.

I created a value of 0.00001 using a ConstantCHOP and then multiplied this value by 0.00001 using a MathCHOP. However, when I tried to retrieve this value using me.inputVal in an ExpressionCHOP, the result was 0, which seems to be an issue. Additionally, it appears that the ConstantCHOP cannot produce extremely small values, such as 1e-10, and is limited to values no smaller than 1e-05.

Is this difference in numeric precision dependent on the type of CHOP used, or is it a bug affecting certain operators? If possible, I would like for all operators to perform calculations with the same precision to avoid any rounding issues or loss of precision mid-process.

Thanks!
float_precision_bug.toe (5.4 KB)

Hello @JoeOhara,

I am not a TD developer, but as far as I am aware CHOPs are internally using floats, which means they can represent numbers with up to 6-9 digits. The number you are trying to represent has more digits - that’s why you are hitting floating point rounding errors. For it to work properly you would need double type which allows for more precision (15-17 significant digits). You can represent and work with such number in Python. Python uses double type by default when working with floating point numbers (unless you specifically create variables with lower precision). Hope this helps.

@monty_python
Thank you for your response.
I understand that using double precision in Python can handle the issue due to its ability to represent and work with numbers with 15-17 significant digits, as opposed to floats which have a precision of 6-9 digits.
My question, however, is why this discrepancy occurs specifically between the MathCHOP and ExpressionCHOP within TouchDesigner.

If this precision issue is isolated to certain operators, resulting in lower float precision, I believe it would be beneficial for these differences to be either unified across all CHOPs or made clear to users.
This clarity would help in avoiding unexpected results when performing calculations within the software.

Aha, I see. I am not sure about this, but I feel like your math1 already holds value that couldn’t be reliably defined by floats. Therefore I wouldn’t be surprised that conversion to Python (double) and back to CHOP (float) would result in rounding error. But I could be wrong and something else could be happening here. :slight_smile:

Hi there,

I think the issue is within the parameters of operators. Like you mentioned, you can’t use smaller numbers than 1e-05 inside a constantCHOP. The expressionCHOP uses the parameter ‘expression’ to store the value, and so will also be truncated/rounded to 0.
I think the reason why this is the case, is because of rounding errors with floats. Like .999999999999… is the same as 1, rounding it to 5 decimals, will result in 1. Though perhaps a good RFE would be to increase this decimal count to like 8 or something :slight_smile:

Work around would be to work in higher values. Like multiplying it with 1e5, then at the very last dividing it again inside CHOP world. Not sure what you eventually doing with those small numbers though, since displaying them other than in scientific notation won’t be much of help I guess :smiley:

Cheers,
Tim