0

In light of CS50's plagiarism rules I'll do this in part psuedo code. My question lies within the for loop that iterates through the user's input to translate it into Caesar's cipher. For some reason, when I'm translating lowercase letters into the cipher, I'm getting unpredictable results past the 'e' character. For example, if I run ./caesar 11 and then input the string "austin", the result is l?dety. Then if I run ./caesar 12 and input the same string, the result is l?d?ty. Uppercase letters work fine, though. Running ./ceasar 11 with "AUSTIN", the result is LFDETY.

Here is how my solution is set up:

for(int i = 0, n = strlen(user_input); i < n; i++)
    {
        // code equals user_input[i]

        // if code is between A and Z
            {
                code = code + user_key % 26;

                // if this is greater than Z
                    {
                        // get the amount overflowed and add it to A - 1 
                    }
            }
    }

As I stated previously, this code works fine. Immediately after this, I run a second if statement for lowercase letters. They are identical except for the case. Can anyone tell me why the lowercase letters won't output properly past the 'e' character? I've tried it a bunch a different ways and I seem to have hit a wall, so this is a last resort. I'd appreciate any help. Thanks!

Edit: made a mistake when I converted to pseudocode

Improve this question

1 Answer 1

Reset to default
1

Simply put, your formula is flawed. Look at the formula that you have:

code = code + user_key % 26;

Assuming that you haven't altered the formula in your conversion to pseudocode, it has two problems. First, modulo has the same precedence rules as multiplication or division, so you would only be applying it to user_key and not to code or the sum of the two. If your user_key is <26, the %26 has no effect at all. If you were to change it to (code + user_key) % 26; you have a bigger problem because you can't apply the %26 to the ASCII values of letters and get a correct result. Instead, you need to convert the ASCII values of the letters to a number between 0 and 25, add the key, apply the modulo, and then convert back to a valid ASCII value. (Review class material if you don't follow.)

Now, since the %26 isn't being applied, all you are doing is adding the key to the ASCII value of the letter, so you're seeing unpredictable results when you go past z or Z, mostly either non-alphas or converting an upper case to another lower case that is an incorrect encoding.

That's what's happening. Once you think about it enough, you'll figure out the correct formula to use. If you're still having trouble, try working out on paper what's happening, by replacing letters with ASCII values, calculating the changes, and returning to the ASCII result.

If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)

Improve this answer
4
  • Thanks for the thoughtful response! I did make a mistake when I converted my program to pseudocode, hence the edit I made to the above code. It might not be entirely clear in my post, but I don't think the formula I used is logically incorrect (code = code + user_key % 26). The modulo need not be applied if user_key < 26. For example, if the user enters the string 'abc' with a key of 1, then all it has to do is add 1 to the value of 'abc' to make 'bcd'.
    – LeviJames
    Dec 12, 2015 at 2:42
  • Sorry my response was too long so I had to make another comment. But in the case that a user enters a larger number, say 27, then the modulo would return 1. In the case that 1 is added to 'z', the if statement should cycle back to 'a - 1' and apply what's left over. In the case of 27 with a string of 'z', what's left over would be 1, so 1 + (a-1) is 'a'. But anyway, what's weird is that upper case letters work perfectly, it's just the lowercase letters that aren't working after the 'e'. 'f' and so on won't output properly.
    – LeviJames
    Dec 12, 2015 at 2:47
  • Not surprising, when you remember that a char behaves like a 1 byte signed integer, meaning that if the value is >127, it will be treated as a negative number (google two's complement representation for more.) The minute you add the char to the key and it exceeds 127 and gets stored, you have a big problem because it gets converted to a negative number in subsequent calculations.
    – Cliff B
    Dec 12, 2015 at 2:55
  • It all makes sense now. I don't remember that little piece of info from the lectures or walkthroughs for some reason. Thank you so much for your help!
    – LeviJames
    Dec 12, 2015 at 3:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .