Talk:Playfair cipher: Difference between revisions

Disagreement about the way to process duplicate letters.
m (→‎Inadequate spec: removing extra Xes and Qs that don't make sense.)
(Disagreement about the way to process duplicate letters.)
Line 73:
 
::: 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 problematically. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 19:22, 28 May 2014 (UTC)
 
== Disagreement about the way to process duplicate letters ==
It seems that there is two ways to interpret the specification.
Let’s choose some text with duplicate letters starting at an odd position, for instance “A TREE”.
 
As I understand the specification, the text ATREE should be successively decomposed in digrams, i.e. AT TR E and, as the last digram is incomplete, we add an X. So we have to encode AT TR EX with the table.
 
But some solutions have interpreted the specification another way. They process the whole text, searching for duplicates and inserting an X when found one. This way, the text becomes, when decomposed in digrams afterward, AT RE XE.
 
I think that the first interpretation is the right one but somewhat less easy to implement as we have to split in digrams a first time to add the X when necessary.
 
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.
Anonymous user