Good point. I added

/* `dst` has room for strlen(src) - 1 bytes */

in the C setup, and allocated dst like so:

const size_t mem_size = strlen(input) - 1;
char *user_string = memset(malloc(mem_size), '@', mem_size);

I did not fix NASM because it uses a completely different test style than C, the output buffers have a fixed length and are embedded inside a struct.

same issue in JS. it's not strictly Int, but it is integral Number, which means floating point representation inaccuracy does not rear its head.

there now is :D

I think you meant spaces instead of zeros? Because zeros should be considered valid.

In my opinion, using Option<T> doesn't make sense to tell that an error happened, just that. Plus, Result<T, ()> is simplified for the kata, but you could give a descriptive error in normal code.

It's not just cases where d == n either. See above for (8,4).

n=2, d=2 isn't valid: d<n. it should be valid ofc.

You have taken the same approach as me. Now look at your code, put (2, 2) as the inputs and you will get the output of 3, when the answer is clearly 2 ({}, {2}). I am rereading an article about the generator function, which is the core of the solution to these types of discrete math problems. I'm trying to see where does this issue come from.

Removed rounding in crystal.

It is a duplicate of my own kata. I screwed it up the first time and received too many negative votes. I asked mods and we decided to just redo it. It now has a higher performance requirement and no issues that the previous one had.

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.