What a fascinating kata! While working on this, I kept thinking how easy the problem:

f( f(n) ) == 4 * n

would be to solve, and how to draw parallels between that problem and this kata. However, I could find no true parallels -- only false leads.

In the end, I had to write out (with pencil and paper) some sample inputs I derived logically, and go from there.

I don't see why including 00 in the sample tests is a necessity. Many katas avoid the edge cases in the sample tests, but test for them in the comprehensive ones.

To be honest, I avoided the edge cases in the sample tests on purpose, as it is very common for people to assume the problem is much simpler than it really is, even if dealing with time is a regular part of their job. My reasoning was that letting the coders see that they neglected the edge cases (when they thought their coding was done) should hopefully instill a sense of considering edge cases, even with something as simple as 12-hour to 24-hour conversion.

I've encountered this very edge-case in real life: There was a bug where a time of observation was occasionally recorded in the database incorrectly. As it turns out, a coder didn't consider the 12-hour edge-case when converting 12-hour time to 24-hour time. Because of this bug I had to troubleshoot and fix, I want to help coders realize that they should consider all possible edge-cases even when the simple sample cases don't include them.

Good catch! It certainly would make sense to make baryon_number a class variable, since it's a property of all quarks that is never expected to change.

Examining this kata's sample tests, I see that the baryon_number test is inside the test section labelled "Class attributes", so it would seem that you are correct in thinking that it should be a class variable.

But since the baryon_number is never supposed to change, it doesn't matter too much whether it's a class variable or an instance variable. The only time it makes a real difference is if you want to query the baryon_number, and there are no quarks that exist. Should we still be able to query the baryon_number? (Most people would say yes, but there are physicists who insist that measurements for particles that don't exist are non-sensical. For instance, every proton in the universe may have the exact same mass, but that measurement lacks meaning if there exist zero protons. But I digress...)

If you'll let me digress even more, what would be expected to happen if a quark suddenly happened to get its baryon number changed? Would that be an unusual quark, or would every quark in the universe also get its baryon number changed to the same value? (To be honest, I don't really know what a "baryon_number" is, but I'm sure if it changed for all quarks everywhere, life as we know it would be very different!)

Hopefully, we'll never have to worry about that scenario. But as for the purposes of the code here, it looks like that your hunch to make "baryon_number" a class variable is a correct one.

I found an issue in the Python version when reporting errors in the randomized 3-clue triangles:

It says "A should equal B" when in fact it should be reversed.

You can see what I mean if define "magic_triangle_solutions" as:

def magic_triangle_solutions(puzzle):
    return [[-1, -1, -1]]

The very first test correctly reports:

[[-1, -1, -1]] should equal []

but some of the randomized tests incorrectly report this:

[] should equal [[-1, -1, -1]]

This is incorrect, as none of the results should ever equal [-1, -1, -1].

I must confess: When I first started solving this kata, I got the bright idea to treat this problem as a "least amount of coins" problem. (For example: What's the least amount of coins needed to make 97 cents?) Instead of using 1 cent, 5 cents, 10 cents, 25 cents, etc., I used denominations of square numbers, as in: 1 cent, 4 cents, 9 cents, 16 cents, 25 cents, and so on.

So I researched the "least amount of coins" problem and I came up with a clever solution. It worked great and passed all the tests, but it kept timing out on large inputs.

So finally I had to put it away and try a different tack.

This kata gave me an example of efficiency of case-checking. Specifically, you can speed up execution by quite a bit by checking the efficient cases BEFORE the inefficient cases. That is, check your cases in order of most efficient to least efficient, EVEN IF it breaks the natural order of thinking about the problem. (And when the natural order of thinking is broken for whatever reason, it helps to comment what's going on in order to maintain your sanity.)

This was a nice, satisfying kata!

If I understand the instructions correctly, duplicate inputs should be ignored, so that sortByBit(0, 0) should be the same as sortByBit(0).

However, as of 2020-12-23, the Perl version treats sortByBit(0) == 1 and sortByBit(0, 0) == 2. I think they should both equal 1, unless I'm missing something.

I haven't solved this kata yet, but I ran into the same issue you're seeing, and I think I know why.

While 6^n does indeed evaluate to ...6 (for most n) and 7^6 == ...9, the answer is not to take 7 to the power of 6, but rather 7 to the power of ...6 . They do not give the same solutions -- for example, 7^6 does not end in the same digit as 7^16 (or of 7^(6^21), for that matter).

In other words:

7^6 == 117,649 == ...9
7^(6^21) == ...1 != ...9

"Say for example the parent array (etc, etc) has 3 sub-arrays inside: you should consider the third element of the first sub-array, the second of the second array and the last element in the third one"

This should be corrected to say:

"...and the FIRST element in the third one"

It looks like you're right.

I'm the author of this kata, and I know that someone else edited my test cases, so apparently they let a mistake pass through. I originally had many, many test cases (one for every minute of the day, in fact), but none of them had a 0 for the hour.

Thanks for bringing this to my attention.

Edit (2020-06-10): I reverted the tests so that they now handle ALL cases once again. That is, every single case is tested -- all 1440 of them.

The a should have been :a.

It is now fixed.

Fixed.