DecimalsAndRounding

Problem: The technique of finding the max flow down a path, converting between units at each step to discover pinch points (credit limits being only given in account units at each step), then starting with that max flow at the start and converting down to the end doesn't generally yield the same final amount at the end as we discovered in the first place, due to rounding error in the conversion process. Similarly, a path supporting the full amount of credit might report back as supporting a different amount due to rounding in the back-conversion process.

Solution: When finding max flow, store the total desired payment amount in account units at each step. When max flow is discovered, calculate its proportion of the total payment amount, and use that proportion to define the max flow in each account's units. Report back the proportion rather than the actual amount. When committing the transaction, commit these values (with a suitable sanity check) rather than doing the conversions again.

Problem: Different accounts may be kept at different decimal-point precision. If Ripple rounds to this precision during max flow calculations, accuracy may be lost. But if Ripple does not round during calculations, results reported to the client may seem to use a slightly different exchange rate than specified -- even to the point of seeming to exchange something for nothing or vice-versa.

Solution: Decide on a the number of digits Ripple transactions will be correct to, and report all those digits. The client then does what it wants with it, including rounding to zero if it must, and explaining the results to its users as need be.