something new every day.. should be resolved, thank you!

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.

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.

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

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 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

In languages other than Python permutations add considerable complexity to the previous kata.

assuming i fixed it

I feel like I gotta quit talking Russian after so many problems reported with this task.

Don't take it too seriously. I'm glad y'all are reporting them, so I can fix it asap.

but два is masculine and neuter, whereas две is feminine in nominative case.

Done. Also added a brief explanation of mascuiline "один" and "два". Hope now everything is fine.