I think one of the apps sends these kind of numbers.

I would be in favour of some rounding routine, say to one decimal.

I would be in favour of some rounding routine, say to one decimal

I think it should be relative… so 1 decimal or 1% of precision.

It looks exactly like the result of converting from single precision floating point values, which have 24-bit fractional parts. We could cut off below 0.00000011920928955078125 (though maybe make it just a bit larger in case the ratio calculation itself introduces an error) times the value since that is the ratio between the values of the least and the most significant bits. I doubt it, but do any products have more precision?

Alternatively, we might be able to detect special patterns in the binary representation in double-precision, which should show a long string of either 0s or 1s from a certain point (ignoring a few last significant bits- rounding errors might emerge there too). For example, double represents 0.40000000596046 as 3FD999999FFFFFAF, compared to the 0.4 which becomes 3FD999999999999A. This method should prevent genuine precise values form being rounded, but it might be overengineering.

Wikipedia article on the single-precision floating-point format

I would suggest rounding to 2 decimal. Example Pictures of nutrition (salt):

But 2.7 then shouldnt become 2.70

There's some code and some dicussion about this issue here: #3489

This issue has been open 90 days with no activity. Can you give it a little love by linking it to a parent issue, adding relevant labels and projets, creating a mockup if applicable, adding code pointers from https://github.com/openfoodfacts/openfoodfacts-server/blob/main/.github/labeler.yml, giving it a priority, editing the original issue to have a more comprehensive description… Thank you very much for your contribution to 🍊 Open Food Facts