Changed "floating point" to "data-type float" at the beginning of the paragraph to clarify. Changed "But decimal should be preferred to floating point ..." to "But decimals should be preferred to floats ...". I think it's clear from context that decimals refers to objects of type Decimal.

But decimal should be preferred to floating point

Decimal is a type, "decimal" is a base, "floating point" is... representation? or whatever it's called. "Decimal" is orthogonal to "floating point". Decimal is a floating point decimal number.

Thanks everyone for contributions to a interesting discussion.

I have rewritten the description. The major change is the following (with some minor changes in other places):

Decimal is a Python class that provides exact representation of decimal values. Using floating point results in numerical inaccuracies because many numbers cannot be exactly represented in binary. Using decimals avoids these errors; for example, Decimal('0.1 + 0.1 + 0.1') is exactly equal to Decimal('0.3'). Using decimals does not eliminate all numerical error; for example, the fact that irrational numbers cannot be perfectly represented as fractions is an unavoidable source of numerical error. But decimal should be preferred to floating point in domains, like finance, that require very accurate calculations.

I switched to approximate equality matching. The reasons outlined above are compelling. Still, it would be nice to have a kata that illustrates that decimals can be matched directly; perhaps it needs to be in a more artificial domain.

For the record, I believe that I might be the one who sent the author on a chase of the wild goose of the accuracy and exact calculations. There already was another kata which implemented this isdea with floats, but it did not make through beta. I do realize how frustrating it can be to get two exactly opposite sets of directions, but I stand at my opinion: I still believe that using imprecise representations and approximate comparisons trades a very interesting (and difficult!) aspect of handling monetary calculations with computer software for a not very interesting aspect of imprecise calculations with oversimplified data types and a one-shot formula. In my personal opinion, this turns the problem from a challenging coding task into a mildly interesting "math, not coding" kind of task and we have plenty of those.

But it's just my opinon, YMMV. I also sincerely apologise for any inconvenience and frustration which I might have caused to the author, and not unlikely being wrong about something. However, I would still be more interested with a "correct", domain-accurate solution, than an approximate, mathy solution.

I too suggest using approximate comparisons. The description should openly state that while using decimal.Decimal is a best practice in financial calculations to minimize error, it cannot always eliminate it.

In my opinion, this kata is an example of financial planning, where the modeling assumptions -- e.g., the assumption of a time-invariant interest rate and a lack of intermediate rounding, as in this kata -- result in a level of inaccuracy that easily dwarfs any issues of round-off errors. However, it's these very modeling assumptions that allow for mathematically elegant solutions that teach us something about the underlying economics. It's only in accounting-like applications where I would insist on absolute lack of round-off error.

For this reason, I would be willing to see a translation in Javascript using ordinary floating-point arithmetic. This would yield more round-off error, but again, it's a minor inaccuracy compared to the underlying, well-intentioned modeling assumptions.

Do you have suggestions for what I should do to resolve the issues you have raised? I'm not sure exactly what you want changed.

Approximate equality or expecting the nearest representable value to the mathematical result or expecting the least representable value with which the amount reaches the target.

My intention in using phrases like the "exact value" and "maximum accuracy" wasn't meant to imply that we were getting the infinite value, just the value up to the default precision

To get the result up to the default precision, intermediate values need to be more precise.

I didn't want to get into the complexities of precision

In this case approximate comparisons are the only option.

test.assert_equals(required_interest_rate(Decimal('1000'), Decimal('1210'), 2, 2), Decimal('9.761769634030309398290702800')). Are you saying that the expected value in that test case is wrong?

Yes, you can try applying Decimal('9.761769634030309398290702736') to 1000 and it will be closer to 1200.

I'm not sure how that can be, since all the people who have solved the kata got exactly that value.

Maybe they rounded in the same places to the same precision as the reference solution.

It doesn't have round-off error - that's what the kata is trying to illustrate.

In computing, a roundoff error, also called rounding error,is the difference between the result produced by a given algorithm using exact arithmetic and the result produced by the same algorithm using finite-precision, rounded arithmetic.

(Wikipedia.) How can an irrational value not have an error when represented as a fraction?

Hi Unnamed,

Do you have suggestions for what I should do to resolve the issues you have raised? I'm not sure exactly what you want changed.

Thanks,

brodiemark

string str : is a fixed, read-only string stored in memory. You cannot modify it. so it is more correct and safer to be (const) char[]

My intention in using phrases like the "exact value" and "maximum accuracy" wasn't meant to imply that we were getting the infinite value, just the value up to the default precision, without rounding. I'm not sure what verbiage would be preferable. I didn't want to get into the complexities of precision; I'm trying to provide a "gentle" introduction to these issues for people not familiar with them.

the result is 9.761769634030309398290702735987519695..., so with the default precision it's Decimal('9.761769634030309398290702736'). The value in the description isn't rounded correctly.

The value comes from the test case test.assert_equals(required_interest_rate(Decimal('1000'), Decimal('1210'), 2, 2), Decimal('9.761769634030309398290702800')). Are you saying that the expected value in that test case is wrong? I'm not sure how that can be, since all the people who have solved the kata got exactly that value.

It can't magically make infinite fractions finite

Agreed

so it has the same issues as float.

It doesn't have round-off error - that's what the kata is trying to illustrate. I'm trying to follow the guidelines here: https://docs.codewars.com/authoring/recipes/floating-point/#use-alternatives

The function should return the exact value

This is impossible with a square root involved.

which is Decimal('9.761769634030309398290702800')

so, obviously, it's not exact.

Do not round the result

we want maximum accuracy in the result

It's impossible because the result is infinite.

One can set a desired precision for decimals, but to keep things simple this kata uses the default precision.

Well, that's what I'm saying. It contradicts the previous sentences.
Also, the result is 9.761769634030309398290702735987519695..., so with the default precision it's Decimal('9.761769634030309398290702736'). The value in the description isn't rounded correctly.

Floating point should never be used in financial programming, because of round-off error. The function should return a decimal representing the interest rate as a percentage.

Decimal is a floating point decimal number. It can't magically make infinite fractions finite, so it has the same issues as float.

The reference solution in Haskell also had some inefficiencies which might have slowed down testing even more. I've made a Haskell fork that improves the reference solution as well as removed the performance requirements.

Fixed for all

holy crap - how did I miss out on this lol

I hate that this works XD