The unit of x and phase is not mentioned. They're apparently different (x is in angular wavenumber, phase is in radians)

Duplicate.

Rounding is a bad idea. This is documented.

Also, this kata is a duplicate of this and this

Initial code has incorrect method signature:

  def evaluate(t: float):

should be

  def evaluate(self, t: float):

• the assertion call, is over complicated for nothing and misleading:

  test.assert_equals(absolute_test(nump(s),qwerty(s)),True,f"nump({s}) should equal to {qwerty(s)}")
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                              ^^^^^^^^^
  

  1. the user's code is still the first function to be called (see issue below)
  2. the first section is the very same as using test.expect. If you keep something lik this, don't "hide" the fact/use the proper assertion tool
  3. assert_equals already handles deep comparison, so don't use the absolute_test thing in the first place
  4. ...then, the message argument doesn't even need to show the expected result, because assert_equals will already do that job

  In the end: test.assert_equals(actual, expected, message_showing_ONLY_the_input), and compute the expected result first.

• in absolute_test: len(v1)!=v2 this will ALWAYS be True. => the function is wrong anyway

Hi,

• sum of interior angles is also a float and must be tested with approximate equality (for instance, (180-a)*n doesn't pass, but 180*n-a*n does)
• the number of sides in the output has mostly no interest, since it's the input already

Cheers

• The description should specify that angles are in degrees.
• The function should return a tuple.

Hi,

• the sample tests are not "samlpe" at all => they are totally unusable to debug the solution (way too big)
• the description doesn't match the actual task at all (where are the nested lists?)

Cheers

Hi,

Well, what's the point in reinventing the wheel and making it a square on the way...?

In a normal world, one would just call to nextprime() as a method (which should be next_prime, btw) and get the prime without ever using the primes() method. This would boil down to a somwhat elipsoid wheel, and to make it round again, you'd just throw away the entire class and use what you put in there.

Summary: the setup is 100% artificial, hence "not good". In addition to that, the task really lacks interest (primes have been done again and again... and again... and again-again...).

Cheers

Hi,

• there is no point in doing 6200 tests for such a kind of task
• the function name is wrong in the solution setup
• the image is not readable in night mode
• the inputs/outputs should be described properly in the... description
• the test suites (full and example ones) are using wrong blocks hierarchies: @test.it are leaves. All tests blocks above those should be describe blocks
• the full test is breaking code-mirror colouring => spread the input data over several lines
• the description of the task is incorrect: the user has nothing to due about the precision: the tests are suing a margin of 1e-6.
• the output format is neither described nor actually tested (ie: tuple or list? what about sequences with more than 2 items? => not validated)
• the tests should call several times the user's function for the same input
• cartesion -> cartesian

cheers

Floats should be compared with test.assert_approx_equals.

• 10000 tests is way too excessive
• there's no need to use preloaded to import from the standard library
• this kata is basically "guess the formula I used"