Anonymous user
Talk:Playfair cipher: Difference between revisions
m
added a forced table of contents.
(Disagreement about the way to process duplicate letters.) |
m (added a forced table of contents.) |
||
| (2 intermediate revisions by 2 users not shown) | |||
Line 1:
__TOC__
== Inadequate spec ==
Line 72 ⟶ 74:
::I'm not saying that this is right, nor that yours is wrong. I am saying that the spec is not clear about how to handle this case. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 18:57, 28 May 2014 (UTC)
::: Right or wrong, the REXX version does encrypt/decrypt the above two messages correctly. It's not 100% successful in handling all cases that contain replicated characters however. As to the specs, yes, I agree, it's rather fuzzy, especially about the part that states "... dropping any extra "X"es, or "Q"s that do not make sense in the final message... That's pretty hard to do
== Disagreement about the way to process duplicate letters ==
Line 85 ⟶ 87:
I have not checked all the solutions, but, for instance, the Java solution has chosen the first interpretation while the FreeBASIC solution has chosen the second interpretation. It doesn’t matter with the example “Hide the gold in...the TREESTUMP!!!!” as the duplicate appears at an even position. But in other cases, the result will be different.
:My understanding differs a little from yours. Using ATREE as an example: First digraph is 'AT' (no problem), 2nd digraph is 'RE' (not TR as above), The 3rd digraph (E) is incomplete as suggested, so X is added. So the text to encrypt is: AT RE EX
:If the original text was ATTREE: First digraph is 'AT' (no problem), 2nd digraph is 'TR' (no problem), The 3rd digraph (EE) needs to be split so an X is inserted in the string and the digraph becomes 'EX'. That leaves a singleton E again which needs an X added to complete it. So the text to encrypt is: AT TR EX EX . --[[User:Tikkanz|Tikkanz]] ([[User talk:Tikkanz|talk]]) 06:28, 20 March 2021 (UTC)
| |||