you need random kind of operations too so you'll have to mix the three batches (and most likely add more kind of tests, see issue below)

Hi,

• There are currently 2 extra methods in the solutin setup that are not talked about in the description. That should be done. ;)
• about the above, is there any point to enforce the use of the getters? I'd personnally prefere to see a usual property (to the user to decide if he want's to protect the data through a @property or not)
• the getters, if used, should be in snake_case
• the class kata should be in PascalCase
• it's not said if (and actually not tested either):
  • x + kata can happen
  • kata += x can happen
• since the kata class can be added with different kind of thing, invalid types should be tested too

Cheers

It appears I marked my previous question as resolved too soon. :)

Here is a base 10 to base 10 conversion where the reference solution produces trailing zeroes in the fractional part:

[511593250458.57654, 10]
'511593250458.57654' should equal '511593250458.5765400000'

Since base 10 to base 10 can be done exactly, there is no possibility of more nonzero fractional digits coming after that. So the reference solution should not produce zeroes at the end.

'11G75H1H2F.539C000000' should equal '11G75H1H2F.539BJJJJJJ'

The issue is not fixed. Don't resolve anything just because you think it's working.

Without stripping zeros: '565181118393.1542000000' should equal '565181118393.1542'. With stripping zeros: '230C1040C39.B885CB0CC' should equal '230C1040C39.B885CB0CC0'.

What?

The input should be explicitly provided of type Decimal, str or Fraction. Otherwise, there is possible inconsistency of treating floating point number due to internal representation.

I.e.,

>>> Fraction(10.2)
Fraction(2871044762448691, 281474976710656)

whereas

>>> Fraction('10.2')
Fraction(51, 5)

• Random Tests are labeled as Basic Tests
• function name should use snake_case
• "invalide" should be spelled "invalid"
• parameters should not shadow the module name string

Hi,

• you should say in the description that n>0 is guaranteed (by talking about "only valid" inputs, you cover the 0 case, but not the negative values)
• we generally prefere to have the ref solution inside the testing block of the random tests. Moreover, we prefere to not have a call to the ref solution or the expected result computed on the same line/expression than the one holding the call to the user's function (otherwise, the user can see the name of the ref function (or worse, the actual answer...) in the stack trace when his code raises an exception).

Cheers

random tests are with sample tests instead of fixed tests

Narcissistic number with constant base are numbers where the sum of a base with the exponent of a number gives the result

This sentence is incorrect, and the task is different from what is said here. Also, this has nothing to do with narcissistic numbers.

Python can easily calculate such huge numbers, so the whole kata can be solved by calling eval (or converting the strings to numbers and performing exponentiation manually, it doesn't matter). And even if you increase the input range to prevent it, this kata will be a duplicate of this one.

both expressions are called *1 in the description.

You get 2 powers in the format (number1^exponent1, number1^exponent1)

• It is not explained how matches are counted
• The function name should be in snake_case
• Trivial map/filter/reduce is not a novel kata idea

hi,

that's a duplicate and ref solution is most likely incorrect looks like you already corrected the tests.
you should unpublish it.

cheers

Sample tests and fixed tests are inadequate: there are only 2 test cases with expected x = 0, which doesn't help ensure that code is at least mostly correct.