This comment has been deleted.

You are right about the epsilon. It's been some time so I hope I didn't break anything else, but I made that epsilon relative for numbers > 1.

Also good example about a function where the limit is not equal to the function value. I added to the description that the actual value takes precedence if is finite. I don't think this edge case was tested for, and since I don't want to be too pedantic, I leave it at that.

The problem with the tolerance of 1e-12 is not that it's "not good enough". The problem is that for numbers with magnitudes above 1000, it does not even kick in. Comparison of large numbers with tolerance of 1e-12 is basically the same as strict equality without tolerance.

You are correct that a pure absolute tolerance (like 1e-12) can be problematic when dealing with values across many orders of magnitude. However, for the purpose of this specific problem, we are to treat the given tolerance as a defined part of the problem's constraints. We will implement a solution that works within this framework, acknowledging that in a broader, real-world context, a relative or mixed tolerance might be more robust.

Regarding your second point about the discontinuous function: you've identified a crucial distinction. The problem is not asking us to compute the limit to enforce continuity; it is asking us to evaluate the function at the point. The function f(x) = 1 for x ≠ 0 and f(0) = 0 is perfectly well-defined at x=0—its value is simply 0. The fact that this value is discontinuous with the limit is a property of the function itself, not an error in evaluation. Our task is to return the function's actual value at the point, not to "fix" discontinuities by returning the limit.

As the problem states, our role is to handle cases where a function is not properly defined at a point (like a division by zero that results in NaN or Inf) and, if possible, find a meaningful finite value (like taking a limit) to assign to it. In your example, the function is already well-defined at the troublesome point, so no such intervention is needed.

You had stated there is an issue here, but it is not clear how one can be resolved. Seems the issue is that your expectation of the problem are not consistent with the problem itself. I suggest to remove the issue, but propose enhancement if we can.

It is not correct to use the absolute error with the tolerance 1e-12 when results could vary from very small (0) to very large (1e+200) values. In general, the problem is not well-defined because it is impossible to compute limits numerically without any additional knowledge about the tested functions.

For example, the reference solution assumes that if r = f(x) is finite then r should be returned. It does not hold in general. Consider the function f(x) = 1 for x != 0 and f(0) = 0. The correct value which makes this function continuous at x = 0 is r = 1, not r = 0.

Personally i like this kata.

1. After many years i learned that double can hold infinity and nan values and those could be processed accordingly.
2. This kata uses std::function what is also quite interesting and useful technique
3. This kata is having quite solid mathematical background and provide users with oportunity to enhance their math skills.

What is the problem of this kata - the problem is in junction of math and computer science. It is really hard to define, understand and translate from the math the criteria for success.

I think this Kata is a great oportunity for young students to touch convergence, but at the same time it can be solved by anyone.

what the diddy, imagine this guy doing this in a level 3 kyu hahaha

happens xD

what the actual f*ck?

Nothing Personal bruv :)

cool

Yes. bitwise-or of the modulo(remainder). It is only zero if both modulos are zero.
When using it on bools you have to be a bit careful, as (1 | 2) is 0011, and that is stored in boolean. true is 0001, so while (1 | 2) evalutes to true, it's not equal to true in some way. Here it's fine, but be aware. Negating with ! (boolean not) "normalizes" it to 0000 or 0001 though. ~ would be the bitwise not.

bitwise-or may be faster as it does not branch (both sides are always evaluated), as opposed to boolean or. But don't rely on that.

is this the bitwise OR operator?

nice man good job ?? !!

lol?