math: simplify types conversion

[edsiper]

This PR aims to address some issues presented in Fluent Bit repo:

• opentelemetry metrics are not decoded / encoded as expected fluent-bit#8083
• cmt_math: fix metric conversions fluent-bit#8762

Note that internally we store everything as uint64_t, to deal with floating point numbers we need to avoid losing precision, so this PR consider changes by using memcpy() when storing data.

Other pending thing, we need decide how to handle NaN and Inf values (encoding/decoding)

[aidanleuck]

@edsiper I tested this change locally, I am still seeing a similar issue. Is there any reason we are not just casting from uint64_t to a double? We are going to lose precision, but we can just let the compiler handle doing the conversion rather than copying arbitrary memory. It seems to me the issue is that a double is a floating point value and a uint64_t is not.

Debug Output:

2024-04-26T19:08:59.360517800Z _Weather_Temperature{summary="Sweltering"} = 1.6304166312761136e-322
2024-04-26T19:08:59.360517800Z _Weather_Temperature{summary="Hot"} = 1.4821969375237396e-322
2024-04-26T19:08:59.360517800Z _Weather_Temperature{summary="Cool"} = 3.1620201333839779e-322
2024-04-26T19:08:59.360517800Z _Weather_Temperature{summary="Freezing"} = 9.8813129168249309e-323

[edsiper]

Do u have the original payload that I can use for testing? Ideally we don't want to lose precision since we convert between different formats

[aidanleuck]

@edsiper
The payload is just a number (uint64_t) between 10 and 55. I just have a mock application that sends fake OpenTelemetry data periodically. When running in the debugger I can validate that the value coming into the function is correct.

[edsiper]

Are the original values integers or floats/double?

[aidanleuck]

They are integers.

[edsiper]

So maybe the problem is on another area. Can u provide the code/tool you use for testing?

[edsiper]

Great, we look into that in a couple of hours.

So maybe the cast thing can still be handled as it was before

[aidanleuck]

Yes you are correct @edsiper the issue is not with the encode/decode functions in math.h but actually cmt_decode_opentelemetry.c:455
Changing the line to value = data_point->as_int and removing the conversion works for me!

[aidanleuck]

I also checked with the union implementation in cmt_math.h. I can confirm that the issue is with that line as opposed to the original implementation. This PR can be reverted.

[edsiper]

Thanks, I will update the code shortly

[edsiper]

FYI: #205