Babylonian square roots

Discussion thread for Babylonian square roots.

Need to specify a tolerance for how accurate you want the approximation to the square root

1 Like

Hey @djwalker! Thanks for mentioning this, yeah the accuracy is especially important for this problem.

The engine has been checking that answers are correct to within a relative error of 1e-10 so I’ve added a note about the relative error to the output section!

I think there might be a couple of bugs in the Python tests for this problem. Firstly, if you submit the template code the tests crash (I guess because the negative value isn’t handled):

Internal engine error during user test case verification. Returning falcon HTTP 500.

A stacktrace should appear below with more information about this error which might help
you debug your code. But if it's not your code then it might be our fault :( If this is a
website error and you have the time, we'd really appreciate it if you could report this
on Discourse ( or via email (
All the information is embedded in the email link so all you have to do is press send.
Thanks so much!

Error: Traceback (most recent call last):
  File "/root/lovelace-engine/engine/", line 165, in on_post
    passed, expected_output = problem.verify_user_solution(tc, input_tuple, user_output)
  File "/root/lovelace-engine/problems/", line 69, in verify_user_solution
    passed, correct_test_case = test_case_solution_correct(correct_test_case, user_test_case, ATOL, RTOL)
  File "/root/lovelace-engine/problems/", line 128, in test_case_solution_correct
    output_correct = values_match(user_val, correct_val, tolerance_type, tolerance)
  File "/root/lovelace-engine/problems/", line 75, in values_match
    return isclose(v1, v2, rel_tol=tol)
TypeError: must be real number, not str

The second issue is a bit stranger. My submission failed the test for an input of zero, however the output is within the stated tolerance:

Test case 1/7 (zero): failed.

Runtime: 221 μs
Max memory usage: 1991 kB

It looks like you’re using the isclose function in the test code, so I’m not really sure why this test fails. Do you know what’s wrong?

1 Like

Thanks for pointing out these issues @sharepaprika!

Yeah as the stacktrace suggested we are using math.isclose with a relative tolerance which won’t work for the zero case: 0±10% is still just 0 so we needed to use an absolute tolerance for checking against zero. I just added in a special case for when n = 0 so that isclose uses an absolute tolerance of 1e-10, so your answer should pass now!

As for the different types, I actually ended up removing the negative number test case. Like you said, it causes issues with the template code, but also because we’re trying to support C/C++ and C/C++ has to declare the return type, so sometimes having to return a string is not super friendly (probably doable with some messy code though).

Right, if you’re trying to keep the problem requirements exactly the same for every language I guess some issues with different types will be unavoidable. Removing the requirement to handle negative inputs is definitely simpler overall, but for what it’s worth I might also mention that python would normally return None in that situation (or maybe raise an exception), rather than returning a string.

Thanks again for all the hard work!