Discussion thread for Babylonian square roots.
Need to specify a tolerance for how accurate you want the approximation to the square root
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 (https://discourse.projectlovelace.net/) or via email (ada@mg.projectlovelace.net).
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/api.py", line 165, in on_post
passed, expected_output = problem.verify_user_solution(tc, input_tuple, user_output)
File "/root/lovelace-engine/problems/babylonian_square_roots.py", 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/test_case.py", line 128, in test_case_solution_correct
output_correct = values_match(user_val, correct_val, tolerance_type, tolerance)
File "/root/lovelace-engine/problems/test_case.py", 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
Input:
(0,)
Output:
(7.888609052210118e-31,)
Expected:
0
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?
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!