Decimals in source quantity are not used for price-per quantity

[Freso]

What

For products with a quantity with decimal values (e.g., “8.6 g”), Prices will drop the decimals (not even attempt to round), and will not include them in “price per quantity” calculations, leading those to be wrong.

Steps to reproduce the behavior:

1. Go to https://prices.openfoodfacts.org/products/8720289261542
2. Note the quantity is shown as “8 g” when the product on OBF is “8.6 g”
3. Note the calculated price-per-quantity is “SEK 1,250.00 / kg” rather than “SEK 1,162.79 / kg”.

Expected behavior

I expected the price-per-quantity to be based on the actual known quantity rather than an approximation of it.

Part of

• Return the price per quantity #77

[raphodn]

Hi Freso!
Open Prices uses data from openfoodfacts-server for product data.
Especially the product_quantity & product_quantity_unit fields.
So I'd presume that the issue is on Product Opener's side..
Or a sync issue ?

[raphodn]

oh i see the problem.. the product_quantity is stored as an IntegerField 🤦
how many decimals should we expect ?

[Freso]

Well, far most cases will have 0 (which is likely why no one’s noticed or bothered to report until now), but at least 1 decimal isn’t uncommon. My vague notion of a guess would be 3 decimals to catch most use cases, as this both matches #794 and also, for most SI units at least, at >3 decimals it usually makes sense to change the unit instead. (e.g., 1.5036 kg might be better written as 1,503.6 g).

Idk if it’s worth it to run some query on the various PO databases and see what the most amount of given decimals are, and how common that is? (I think I’ve seen some producer-data entries with a lot of decimals, but those I think are results of floating-point accuracy issues and not something that should necessarily be accommodated here.)

[raphodn]

Yeah 2 or 3.
I searched in Product Opener's code but couldn't find the info on how it's stored over there. Simpler to mimick the behavior as we simply sync stuff.

[raphodn]

I also opened another PR to start syncing the raw quantity field: #1114