Yes, but this can be relatively simple, like "round to nearest cent, half to even". That's exactly what the banker's rounding is for. The whole point is to round a fration (which can be done precisely), and not a float (which can be ambigous).

ok, but that requires that additional unambiguous specification, so.

That's the thing, it does not really. $5.99 is a precise value, 17% is a precise value, multiplying two fractions yields a precise fraction, and rounding of fractions of money is defined precisely and unambigously.

well, it's only about shifting the comma two places left. Meaning, there are still roundings here and there. Multiplying cents by 0.17 (percents) still gives a float.

Why not? When you have real money with real coins and notes, you can add 15% to a price and this calculation always ends up with a precisely known value and it's not a subject to any ambiguities of rounding? Or is it?

I.e. handling of monetary values is always precisely defined, otherwise accounting as a whole domain would end up imprecise.

but it doesn't really resolve the rounding troubles when a ratio is involved, does it? (like her: x 1.15)

Decimal numeric types are suported quite widely, but not completely. Alternatives for languages which do not have native decimal type is to perform calcualtions using cents as integers, or a tuple of (dollars, cents). You (i.e. both authors and solvers) can pick any internal representation they want for calcualtions, and present the result as a formatted string to make the interface representation-neutral. Or just make the numeric representation stick out of the interface, if authors prefer.

You talking about decimal I guess. Does that even work for all languages?

Floating points in strings are always horrible

The numbers in question are prices, and prices are not really floating point numbers. Having string-formatted prices is not a problem in itself, the problem is using floating point numbers for prices.

Ah, I see your edit now, since the other didn't work. Anyway, I've got something which I believe works as well.

kinda. Just use a custom generator, and keep generating values as long as abs(v*1.15%5 - 0.5) < 1e-9)

basically, I should calculate both round(x * 1.15) and x + round(x*0.15), and when these differ, generate a new number, that should be it, right?

looks quite complicated when it comes to maintainability. Morevoer, if the tests are converting everything, returning a string in the first place doesn't really make sense. Couldn't you instead tweak the random value generator?

Current Python version allows both. To me that seems the most user friendly solution. What say you?

see issue/suggestion above