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

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

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

  • Brilliant news! My first approved

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

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

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

  • Approved !

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

  • 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

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

  • Loading more items...