Floating point logic leads to incorrect measurement conversions

[Para-lyzed]

Since I have not seen any progress in correspondence with my previous comment, I am opening a new issue.

There is a large discrepancy in US measurements. For instance, 1 US gallon should be 16 US cups, but I'll list a bunch of discrepancies below (due to errors in floating point logic that need to be fixed by using more modern decimal division methods, such as Java's BigDecimal implementation). The converter returns the following incorrect conversions between US volume measurements:

1 gallon = 4.000007570825068 quarts
1 gallon = 8.000015141650136 pints
1 gallon = 15.77255222607493 cups
1 gallon = 127.99993943339943 fluid ounces
1 gallon = 255.99987886679887 tablespoons
1 gallon = 767.9996366003967 teaspoons
quart -> all above conversions (gallon, pint, cups, fl oz, tbsp, tsp)
pint -> all above conversions
...
etc.

The following US length conversions are also incorrect:

1 mile = 1759.9903173999999 yards
1 mile = 5279.9870456 feet
1 mile = 63359.876734 inches
...
etc.

All US conversions are incorrect due to poorly handled floating point logic. I imagine the same is true for (non-US) imperial measurements. This also means the conversion between metric and imperial (US and non-US) has a large error.

I don't personally know much about Kotlin, but I believe there is some implementation of BigDecimal as per the documentation. I also saw some discussion about multiplatform limitations when I briefly looked into it here. At the worst, it seems like you may need to use an external library to port the functionality to Android, and that is discussed in the forum post I linked. The BigDecimal can be used for all division, it doesn't have to be used exclusively for imperial measurements with non-metric subdivisions. That would also potentially take the place of any system you used to ensure consistency in metric conversions (as while dividing by factors of 10 would still usually result in floating point inaccuracies, it seems the conversions for metric all work).

I should mention that I realize you likely use APIs to handle all of your unit conversions. However, since these conversions won't ever change, there would be no reason not to hard code them if that would allow you to achieve more accurate results. This also decreases reliance on sending requests through the Internet, which is all around a bonus for the end user. Of course, this doesn't extend to currency exchange rates, but it works great for measurements.