• Solution and solution setup could be simplified as

local function remove(s)

end

return remove;

• The structure of tests should be a top-level describe block, followed by an it block for Fixed and random test respectively. Having assertions as an individual it block can mess up the output panel with a ton of messages, hardening debugging process for solvers

• All functions and global variables should be declared local

• Reference solution can be removed and replaced with in-line random generation along the given input string

• math.randomseed(os.time()) is missing in the random test's it block (currently it is describe block)

• Random tests do not generate cases when there is no trailing ! in the given string

• Identation should be unified and cleaned up

• it block messages should be useful assertion messages (with the inclusion of quotes surrounding the input string)

Kindly refer to the docs on how to write a good translation. Also you may be interested in this translation as a reference in future

• Solution and solution setup could be simplified as

local function area_or_perimeter(s)

end

return area_or_perimeter;

• The structure of tests should be a top-level describe block, followed by an it block for Fixed and random test respectively. Having assertions as an individual it block can mess up the output panel with a ton of messages, hardening debugging process for solvers

• All functions should be declared local

• math.randomseed(os.time()) is missing in the random test's it block (currently it is describe block)

• Too many unnecessary tests, it can be simplified to 100 tests, with half of them having a == b and the other half randomly generated. (Kindly refer to C / Ruby translation for that)

• Reference solution can be removed and be generated concurrently as the given inputs

• Identation should be unified and cleaned up

Kindly refer to the docs on how to write a good translation. Also you may be interested in this translation as a reference in future

• Solution and solution setup could be simplified as

local function cockroach_speed(s)

end

return cockroach_speed;

• The structure of tests should be a top-level describe block, followed by an it block for Fixed and random test respectively. Having assertions as an individual it block can mess up the output panel with a ton of messages, hardening debugging process for solvers

• All functions should be declared local

• math.randomseed(os.time()) should be within the random test's it block (currently it is describe block)

• local s = require 'solution' is abit unclear. The parameter name of initial solution setup is also s, suggesting to change it to local cockroach_speed = require ('solution')

• Sample tests do not compile due to a missing quote

• Identation and unnecessary comments should be cleaned up and removed respectively

Kindly refer to the docs on how to write a good translation. Also you may be interested in this translation as a reference in future

whoops

initial solution setup:
def cannonball(theta,v) should be def cannonball(theta,v,h):

great minds think alike

damn we did exactly the same lol

Changed all cases of test.assert_equals to test.expect, because i genuinely didnt know how to get rid of that false should equal true at the end

When tests fail, assertion message could be slightly improved. The part "Expected True but got False" is superfluous and potentially confusing, and information about tolerance is missing. MAybe you could check if using test.expect with a fully customised assertion message, including input values, expected values, actual values, and tolerance, would give a cleaner feedback on failure?

forgot to tick the resolve issue box whoops

so use normal brackets instead of square ones right? understood

issue resolved

A known number of values with entirely different meanings should be represented as a tuple, not an array or a list. Use appropriate datatypes!

Do not ask for rounded results. This is documented.