Deduplicate - Shortest steps to a number

[4500zenja1]

Taken from the wiki (link)

1. Shortest steps to a number

• 6 kyu;
• You need to find the amount of steps to go from 1 to N, the accesible steps are +1 or x2;
• 95% satisfaction from 511;
• 1.5 pending issues (one on this matter, the other is about to be resolved);
• 14 languages;
• Published May 2019, author last active on May 2024.

2. T.T.T.19: How many steps are required to turn A into B?

• 6 kyu;
• You need to find the amount of steps to go from A to B, the accesible steps are +1 or x2;
• 97% satisfaction from 85;
• 1 pending issue on this matter;
• 2 languages + 1 pending translation
• Published August 2016, author inactive.

3. Time Is Money (number of operations)

• 6 kyu;
• Basically that's a performance (input is up to 99^9999) kata which uses the reverse process of the katas above
• 82% satisfaction from 33;
• 1 pending issue on this matter;
• 1 language (Python)
• Published November 2022, author active.

[monadius]

2 is different from 1 and 3. 3 is very similar to 1. It has performance requirements but they are not very important for this task because O(log n) solutions are simpler than other solutions (BFS). So I propose to retire 3 and keep 1 and 2.

[4500zenja1]

To think about that, 1 and 2 have the same concept, but 2 works with different starting numbers, which differentiate it from 1.

3 is just 1 but with performance-stress tests, maybe you just need to add them to 1 and then safely retire 3

[monadius]

There are should be no performance requirements for 1: It is always good to see different solutions. Moreover, there are not many solutions which will time out if performance tests are added to 1. It is also difficult to add consistent performance tests to all existing languages. JS should be switched to BigInt, C has no big integers, etc.

[vvrmatos]

I am the author of 3, and I say

These are three complete different katas:

I believe all three metrics, Time Complexity, Memory Complexity, and Number of Operations, should be kept because they each represent a distinct and essential dimension of algorithm evaluation. Time complexity describes how a solution scales with input size, which is critical for understanding algorithmic efficiency. Memory complexity reflects the additional memory consumed during execution, helping users recognize data structure trade-offs and resource constraints. Number of operations, unlike the other two, provides a concrete measure of the actual computational effort involved in executing the code, capturing performance nuances even within the same Big-O class. For example, two O(n) solutions may differ significantly in runtime due to differing numbers of additions, comparisons, or function calls. This metric is especially useful in optimization katas and code-golf contexts, where every operation matters. It also provides valuable feedback for beginners learning how different constructs affect execution cost. Together, these three metrics give a complete view of a solution: how it scales (time), whether it fits (memory), and how efficient it is at the instruction level (operations). None of the metrics are redundant, removing any one of them weakens the ability to assess code comprehensively. Therefore, I strongly recommend retaining all three.