Deduplicate - Big Integer: Sum

[hobovsky]

From wiki list

1. Sum Strings as Numbers

• 4 kyu.
• Satisfaction 83% with 36k completions.
• 17 pending issues.
• 8 languages + 2 pending translations (Python exclusive).
• Published Mar 2014, author inactive.

2. Adding Big Numbers

• 4 kyu
• Satisfaction 86% with 27k completions
• 11 pending issues.
• 8 languages, 7 pending translations
• Published Oct 2013, author inactive.

3. Adding Binary Numbers

• 6 kyu.
• Input is binary digits, built-in parsing and binary stringification is restricted.
• Satisfaction 88% with 1100+ completions.
• 1 pending issue.
• 4 languages, 1 pending translation.
• Published Aug 2015, author active.

[hobovsky]

The kata 3. was suggested as a duplicate but I do not think it is one. I solved it only in Python and it was okay, if you think that other languages are also good, it can stay. Or it can be evaluated in a separate ticket, not related to deduplication.

Both kata 1. and 2. are a great example of kata which aged badly.
Tests are bad, mostly due to weak /absent restrictions in languages which support bigintegers out of the box.
Specs are also problematic, because requirements of empty strings and leading zeros are not enforced across all languages consistently.

Out of the two, I think that 1. could be retired, and 2. could stay because it has more languages, is older, and has no empty strings. Ideally, the bigint translations would be strenghtened or removed when the functionality of disabling translations gets implemented.

Another possibility is to retire both and create a new kata, in languages which cannot be cheesed easily with bigint, but it's more effort than waiting for the new function :)

[ejini6969]

I prefer creating a brand new kata. Not only do we need not to handle the fuss of removing languages with BigInt support (which is not limited to JS), but it can be reranked to a more appropriate one, plus less likely that cheaters / copycats would take advantage as those first 2 katas have been a "gem" for those group of ppl.

BTW, 3 should be kept because it is a good learning material for beginners, many would just use the built-in functions without knowing how to perform the real task

[awesomeAD1]

I agree that 1. is problematic because it has a Python translation, which 2. doesn't.
However, I do not agree that 3. is not a duplicate. The only difference is that you have to carry at 2 instead of 10. The algorithm is otherwise identical. The only other difference is that more work has to be put in to somehow disallow use of decimals, for... no good reason.

[hobovsky]

LOL I did not even think about solving the 3. with long addition. I just converted to int, added the two, and stringified back (with functions implemented by me). I didnt carry nothin' :D That's why I considered the 3. to not be a duplicate, because I used a different method than in solutions for the other two.

[akar-0]

Agree with ejini, keep 3 and create a brand new one properly ranked.

[Chrono79]

I'd start with retiring 1.

[KayleighWasTaken]

Opinions in order of preference:

• Retire all three, create new kata for adding strings in arbitrary bases, or at least in the 2-36 range.
• Retire 1 and 2, create direct replacement at a more correct rank.

There's also something to be said for making a kata which requires better than simple long addition to solve (probably only applicable to lower level languages).