No random tests - can hardcode solutions

Python translation has sample test being test.assert_equals(1 + 1, 2) instead of actual tests

In the python translation (haven't checked closure translation) the type chart and the list of types doesn't include the grass type.

sample test cases are str, random test cases are List[str]. Description claims that the type passed into the function is str, i.e. random test cases give wrong type.

The description claims Bases are always of length 4 but a sample test has a base of length 0, i.e. a contradiction. This discrepancy should be fixed.

I would advise changing the test(s), not the description.

Given that an n-dimenional cuboid of n=1 (i.e. a line) has its hyperperimeter being two points (which by definiton each have size of 1) , shouldn't the hyperperimeter be 2, not 0, in those cases?

i.e. it seems to me that hyper_rectangle_details([n]) should equal (n, 2) not (n,0).

In Python 3.8, attempting to return a fraction.Fraction object causes the test suite to crash, since it can't format the returned object, whether or not the answer is correct.

Note that returning floats works.

Error message:

Traceback (most recent call last):
  File "tests.py", line 17, in <module>
    assertFuzzyEquals(rolldice_sum_prob(11, 2), 0.055555555555)
  File "tests.py", line 14, in assertFuzzyEquals
    msg = msg.format(expected, actual)
TypeError: unsupported format string passed to Fraction.__format__

Description has

0->2->3->7->10->12 => 32

as a possible path. However, 0+2+3+7+10+12 = 34, not 32.
I assume this is a typo.

in initial solution, supplied function has name/comments from another kata, apparently two_oldest_ages

It should be algebra with correct (or no) comments.

My implementation passes every random test checked now. Issue seems to be resolved.

My solution passes every fixed test case. However, it infrequently fails on random tests, due to some minor differences in behaviour with out implementations (you round to 13 dp every iteraton, I don't. Rounding to 13 dp is not mentioned in the description). These random tests are infrequent enough that I can get luckly and get test cases with no errors if I attempt a few times.

This seems to be because in those cases either

a) my algorithm finds a solution, yours doesn't.

b) my algorithm finds a different solution than yours.

Neither of those should result in failed tests

My suggestion:

If the returned result doesn't match yours, also have the code check if it's a valid solution (even if it's different from yours), instead of rejecting it.

The description claims that data passed into order is [float (or int), str], meaning that data passed into calculate should always have numbers at even indices, and strings at odd ones, i.e. [float, str, float, str, ... ].
However, in the actual test cases, some inputs are [str, float, str float, ... ] the opposite of what is stated.

i.e. the description contradicts the tests.