rotational-cipher: Is this meant to test only encoding/encrypting of a message?

[NobbZ]

The current canonical data seems to test only in a single direction and not back.

Thats makes it hard to do property based testing on this.

Since everything that is not an letter is not changed at all AND we keep case of a letter as well, I should be able to postulate the property decrypt n . encrypt n == id. But I am unsure how the dataset handles decrypting, so I'm unsure right now how to implement the exercise in general.

I am aware of the fact though that decrypt n == encrypt (26 - n), which might be another property to test, but that I do not want to mix into the first one...

[rbasso]

First of all, I never solved/implemented this exercise, so may I didn't got the point.

The way I read the description.md and the canonical-data.json, there is no backwards rotation or decryption, only rotation, which is consistent with modular arithmetic. In that case, the only properties I can think of are (for m and n in Z/26):

• rotate n [] == []
• rotate 0 xs == xs
• rotate n xs ++ rotate n ys == rotate n (xs ++ ys)
• (rotate m . rotate n) xs == rotate (m + n) xs

[petertseng]

I suppose one could use negative numbers if one really desired?

[NobbZ]

Well if we just see it as arbitrary rotating, of course there is not really a way back, but since its called cipher it is only natural to do it backwards. rbasso <notifications@github.com> schrieb am Mo., 20. Feb. 2017, 12:41:

…

I suppose one could use negative numbers if one really desired? Sure. But for property testing purposes, @NobbZ <https://github.com/NobbZ> only need to ``mod 26`` the number given to rotate. This way you only test that it behaves as expected on normal input. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#605 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADmR_CwblESMXjEvmbTn0FSDGdQM235ks5reXvfgaJpZM4MGCN8> .

[petertseng]

I would feel there is a bit of unnecessary repetition if another set of test cases were added for decrypt. If I want to avoid that, then I thought of various options:

• Add to the README: "This exercise will only ask you to implement the rotate function instead of encrypt and decrypt! Why do you suppose that is so?! How can decrypt be expressed in terms of encrypt?" and leave it as an exercise for the reader to convince self that no extra code needs to be written.
• Add to canonical-data.json a comment that the decrypt tests can just be the reverse of the encrypt tests and/or a comment that property-based testing can be used to relate encrypt and decrypt together. I guess that was already done in https://github.com/exercism/xerlang/blob/master/exercises/rotational-cipher/test/rotational_cipher_tests.erl huh, why not make it official?

[rpottsoh]

I think PR #701 should have closed this issue..... Or stated another way. The changes that resulted from #701 have resolved the issue being discussed here.

[petertseng]

Hmm, by this, do you mean something along the lines of "by choosing not to add a decrypt operation, #701 made an implicit choice of No on this issue" ? My current reading was to not assume it makes a decision either way since it performs a purely mechanical operation

[rpottsoh]

I guess I am just pointing out that during the life-span of this issue "property": "rotate" has been added to the testdata.

[rpottsoh]

Yes the exercise is just performing a mechanical operation. For the sake of the encryption / decryption discussion the test data is only utilizing "rotate" for encryption. Perhaps a case like this:

        {
          "description": "rotate all letters the same amount a second time",
          "property": "rotate",
          "input": {
            "text": "Gur dhvpx oebja sbk whzcf bire gur ynml qbt.",
            "shiftKey": 13
          },
          "expected": "The quick brown fox jumps over the lazy dog."
        }

could be added to acknowledge the decryption side of the coin.

or just another, unrelated, test case entirely:

        {
          "description": "decipher what is the soup of the day",
          "property": "rotate",
          "input": {
            "text": "Znk yuav ul znk jge oy Zusgzu Hoywak.",
            "shiftKey": 6
          },
          "expected": "The soup of the day is Tomato Bisque."
        }

Furthermore, there is no mention of encrypting or decrypting in the current form of the README, just transposing.

[petertseng]

Yes the exercise is just performing a mechanical operation.

To me I am unsure why say "yes" there, since it sounds like the "yes" implies agreement with me, but I never said any such thing. I said the PR performs a purely mechanical operation, not the exercise.

Perhaps a case like this: "text": "Gur dhvpx oebja sbk whzcf bire gur ynml qbt.", "shiftKey": 13 could be added to acknowledge the decryption side of the coin.

oh. sure I guess.

[rpottsoh]

To me I am unsure why say "yes" there, since it sounds like the "yes"
implies agreement with me, but I never said any such thing. I said the PR
performs a purely mechanical operation, not the exercise.

My fault, apologies, I mistook "it" to be referring to the exercise and not the PR since it was used in a new paragraph.

oh. sure I guess.

Missed understandings aside can I take it that you think a test case like what I have proposed could be good for this exercise and might bring this issue to a close? I'm willing to open a PR if you think there is merit.

[petertseng]

might bring this issue to a close

My reading of this issue: CONCERN: This is called a cipher, but it's not clear what the "encipher" and "decipher" operations are, since only the "rotate" operation is provided. Any way to answer this concern closes this issue. For example: Make it clear that the *rotate* operation can be used to do *decipher* as well.

can I take it that you think a test case like what I have proposed

<#605 (comment)> could be good for this exercise and might bring this issue to a close I've upgraded from "sure I guess" (unenthusiastic) to "yes" now that I believe I characterise the concern.

[rpottsoh]

Thanks @petertseng this is helpful to me. I don't have the testdata or README in front of me to refer to, but I am thinking that perhaps rephrasing [some of] the cases in the testdata to imply that the input is being encrypted / decrypted would suffice. One or more cases would need to be added to cover decryption. I'll think about this some more later, when I can have the README and testdata before me to look at.