[BUG] the aggregation result in float field type is inaccurate about opensearch

[mgodwan]

This seems like a precision issue (32 vs 64 bits) to me.

Can be reproduced with:

 NumericUtils.sortableLongToDouble(NumericUtils.doubleToSortableLong(0.000001f)) // Returns 9.999999974752427E-7

If we use double for the initial value

 NumericUtils.sortableLongToDouble(NumericUtils.doubleToSortableLong(0.000001d)) // Returns  1.0E-6

@kkewwei Since the mapping type used here is float, the precision is lost when the value is actually parsed as a number and you get the nearest value representable as float and is used in bucket creation. The hit returned returns the source as it was ingested (i.e. the source content itself), and hence shows the provided value.

Using double in mappings should solve this

[kkewwei]

@mgodwan yes if it's a bug, I'm pleasure to solve it.

[getsaurabh02]

@mgodwan let us know if this still needs to be fixed? we are assuming this is just a mapping issue based on the comment " mappings should solve this"

[kkewwei]

@mgodwan let us know if this still needs to be fixed? we are assuming this is just a mapping issue based on the comment " mappings should solve this"

I think we should fix it, as float field type is common, when it is used in aggregation, the bucket name of the aggregation response may be inaccurate, which is confusing to user. We can't force the user not to use float field type in aggregation.