6 kyu

ADFGX Simplified

184Caders
Description
Loading description...
Cryptography
Algorithms
Fundamentals
View
AllIssues3QuestionsSuggestions3Show Resolved
  • Please sign in or sign up to leave a comment.
  • saudiGuy Avatar

    This comment has been hidden.

  • saudiGuy Avatar

    python new test framework is required. updated in this fork

  • ejini战神 Avatar

    • Description should be language-agnostic

    • Example and fixed tests on j included in plaintext and square should be tested

  • bouchert Avatar

    The behavior of j and i is somewhat unclear from the description and example test cases. While you say j should be treated as i, neither the examples in the description nor in the test cases contain a "j" in the square paramater. They do, however, contain i's. Therefore, one might assume that the instruction meant to perform a j to i substitution on the plaintext. This has clearly confused others than just me.

    I suggest altering the description to say: If either an i or j appears in the encryption square text, the corresponding two-letter code should be used to encrypt both i and j. Furthermore, you should remove all mention of a substitution from the decryption section of the description. It says (PLEASE NOTE, j SHOULD BE TREATED AS i), but this is incorrect. If a j appears in the square text for adfgx_decrypt, then if the corresponding two-letter code appears in the ciphertext, your tests expect a j, not an i.

  • ATeran Avatar

    This comment has been hidden.

  • Blind4Basics Avatar

    Why this strange behavior about 'j'??? That seems to not make any sense, actually. If not artificial, the reason should be explained in the description. If it is, it should be removed. It's just boring to code and doesn't change anything to the difficulty of the task.

    bye,

    B4B

    • Caders Avatar

      This is because the 5x5 nature of the block only allows 25 letters. We have 26 letters in our alphabet. Traditionally this has been solved by using i and j interchangably.

      If I hadn't put 'treat i as j', then many would become confused with that inconsistency.

      I don't understand how it is boring, it requires an extra line simply converting from one to the other.

      I hope this clears up any confusion. :)

      Suggestion marked resolved by Caders 8 years ago
    • Blind4Basics Avatar

      thx for the explaination. :)

    • akar-0 Avatar

      Moreover, Latin does not distinguish between i and j characters (actually j is a late creation in Romances languages)

  • kjmosher Avatar

    I didn't see any tests that validate the handling of the "j should be treated as i" requirement. I submitted a solution that I had messed up that part of the handling, and it still passed all of the tests.

    I would recommend adding one example test that exercises this part of the solution, as well as adding the possibility of 'j' showing up in the random test cases.

    Other than that, nice kata!

    • Caders Avatar

      Thanks for bringing this up!

      I've added random cases with 'j' mixed in as input, along with one static case. :D

      Issue marked resolved by Caders 9 years ago