• ###### nomennesciocommented on ""Regular Expression for Binary Numbers Divisible by n" C++ Translation"

Can you add anti-cheat tests to check if the implementation doesn't use `<regex>`?

• ###### monadiuscommented on "Finding Derivatives" kata

This happens because of floating-point underflow. Specifically, the derivative of `(18*57.2^x-x^x+81.9*x^5.2*x^62)^x` is a very small number which is computed as `0 + 0i` by the reference solution and as `-6.09095e-315 + 8.56785e-314i` by my solution. In general, both results are unreliable. Overflow and underflow should be avoided in all randomly generated subexpressions.

• ###### C-Vresolved an issue on "Insane Coloured Triangles" kata

My mistake, the tests should be in the correct order now

• ###### balygabycommented on "Wait without blocking" kata

Brilliant news! My first approved

• ###### C-Vcommented on "Finding Derivatives" kata

I had this random test at some point :

``````The first derivative failed! f(x) = 22.5+log(sin(77.6)^(50.2^42.1)/(x/x)-(81.9/x^x*58.8)*(18*57.2^x-x^x+81.9*x^5.2*x^62)^x), x = (-4.6,-9.47)
Expected: equal to (-3.35405,2.02297) (+/- (0.000488281,0.000488281))
Actual: (226.443,4.30916)
``````

Yet the WolframAlpha command
`derivative of 22.5+log(sin(77.6)^(50.2^42.1)/(x/x)-(81.9/x^x*58.8)*(18*57.2^x-x^x+81.9*x^5.2*x^62)^x) at x=-4.6-9.47i`
does give me `226.443+4.30916i` ?

• ###### MikChanresolved a question on "Finding Derivatives" kata

Okay, hopefully I finally fixed this issue.
About the overflow thing: the marging of error is quite huge actually, so the rule of thumb is if WolframAlpha returns the expected result which is between `10^-300` and `10^300`, your soulution should be able to compute it too. Also, when designing this kata, obviosly, I was using WA's results as the refference, so if tests expected result and WA's result don't match, I'd be very grateful if you tell me.

• ###### MikChancommented on "Finding Derivatives" kata

Of course, since the tested function is actually a constant, I could program the solution to recognize it and directly yield 0 for the derivatives.

Can't give clues, but probably?..

But then the same problem arises with more complex random tests such as

This particular test case shouldn't even appear, seems like I missed something. I'll fix it soon.

Thanks !

• ###### C-Vcommented on "Wait without blocking" kata

Approved !

I haven't seen many katas tackling asynchronous programming (at least in C++), so this one was refreshing

• ###### C-Vcreated a question for "Finding Derivatives" kata

I'm currently having a similar problem to what hapster100 had. My solution sometimes passes, but most often fails one or two random tests. It seems that the power towers can get really large, to the point that the calculations get imprecise or yield inf and nan values. For instance I failed this random test :

``````The first derivative failed! f(x) = (97.2^81.1-77.6^56.9)^91.8, x = (1.48,-2.64)
Expected: equal to (0,0) (+/- (0.001,0.001))
Actual: (-nan,-nan)
``````

Of course, since the tested function is actually a constant, I could program the solution to recognize it and directly yield 0 for the derivatives. But then the same problem arises with more complex random tests such as

``````The first derivative failed! f(x) = cot(((x*x^32+22.3/53.6^80.6/x^73.7-69.6^31*x)*x+98.3-x^47)/x^(x*39.7-43.9/99.3)*35), x = (6.81,-1.78)
Expected: equal to (0,-0) (+/- (0.001,0.001))
Actual: (-nan,-nan)
``````

(even the reference solution appears to encounter precision issues, as it gives exactly zero even though both the function and the point are random)

Some people have already completed the kata, so it may be my approach that is flawed, but I still think that it shouldn't be required to deal with precision issues like these

?

• ###### Gena2018115ruscommented on "Regular Expression for Binary Numbers Divisible by n" kata

Hi, can someone approve this?

• ###### stephan.lindebaumcommented on "Sum Strings as Numbers" cpp solution

What about the performance penalty due to all the string::push_back(.) calls and the final reverse(.) call?

Wouldn't it be better to avoid reordering of 'result' and directly initialize 'result' with its final size?