22
votes
Programming Challenge: Make a Caesar cipher!
The point of this thread is to post your code for solving the task. Other will comment with feedback and new ideas. Post what language (and version, if relevant) your code is written in.
Have fun!
Task description
Your task is to make a caesar cipher that takes a word and an integer as arguments.
An article explaining what the cipher does.
Input description
A word followed by a space and an integer.
Output description
The ciphered word.
Sample onput
A 1
Caesar 5
Tildes 25
Sample output
B
Hfjxfw
Shkcdr
Bonus 1
Make the cipher work backwards.
Sample input
B 1
Hfjxfw 5
Shkcdr 25
Sample output
A
Caesar
Tildes
Bonus 2
Make the cipher handle special characters.
Sample onput
A_ 1
Cae?sar 5
Til!des 25
Sample output
B
Hfj?xfw
Shk!cdr
I like python.
Could you explain how your code works? I like python as well but am lacking a bit in experience of it and this makes no sense to me.
This program is intentionally very obtuse, but what it's doing is converting each character into an ASCII code, 'normalising' those codes so that they lie in the range 1...26 (regardless of whether they are upper or lower case), shifting the codes by the required amount, then converting them back into ASCII codes in the required region of the table (for upper or lower case characters respectively). This program relies on the fact that the alphabet is contiguous in ASCII, so that ASCII(J) + 6 = ASCII(P), for example. It also relies on the fact that Caeser shift wraps around, allowing the shifted code to be coerced back into the 1...26 range with the modulo operator.
You and your one-liners. :P
My solution in C/C++, including the bonus challenges:
Props. One of the cleanest solutions and in c++. That's a bamf right here
https://github.com/tsikorksi/historic-crypto I tried my hand hand at some simple cryptography a while ago, but here's the relevant functions :
Its not the finest solution but fairly easy to understand, despite the lack of comments (I've gotten better about that since I wrote this) and the output is poorly formatted here, but its better on the github.
As an ex-teaching assistant, I'm obligated to look for the weird stuff no one cares about. What about negative shifts? Then again, it'd probably be better to clean up negatives in a common preceding function, like when gathering input. Are negative shifts even legal in a Caesar cipher or are left and right shifts their own category?
Negatives work fine, because the code changes the ASCII value, rather than the actual char, so a -4 shift will work fine.
Would a -50? I have not tested it, but I assume it would fail given your initial
if shift >= 26
Unexpectedly, it works fine. What does break it is a negative value > 255 (or less than -255, you know what I mean)
In case you didn't catch it on reddit the other day,
Hitting this Block for 416 Years Crashes Paper Mario
is now relevant.MoonScript
MoonScript isn't the most prevalent language, yet you used it two days in a row. What got you started on it?
MoonScript compiles to Lua, which I've had a lot of experience with. It's a cleaner syntax, allows for object-oriented programming (better than you'd get in Lua at least), and has more features.
If you're interested, I'd recommend looking at the reference or "Learn MoonScript in 15 Minutes".
How mature would you say the language is? How useful do you find it for larger scripts?
A web framework was written in it, so I'd say very mature and useful for large scripts.
I'm halfway through skimming your
Learn MoonScript
link, and this stuff is crazy. Dynamic typing is always pleasant to deal with, but the dependency on spacing for function calls and negation makes me think debugging would be a nightmare. Do you use Lua professionally or for some hobby?You don't have to use that spacing. You can always call functions normally (i.e., with parenthesis.) The spacing is just syntactic sugar for when you think it'd look nicer. The script behaves exactly the same when written as follows:
I don't use it professionally, just as a hobby.
Here's my solution in rust. It has a very basic argument parsers:
Perl 6
Code
Tests
Challenge
Bonus 1
Bonus 2
Notes
I've changed one test for the second bonus part, where the original challenge posed that
A_
should becomeB
, dropping the trailing_
. This behaviour looks odd, and since there's other typos in the OP as well I assumed that one to be a type as well.Having looked through the comments a bit, I've noticed most people don't even pass the actual challenge, as they don't use a single string as output. Instead, they already split the clear-text string and the number of shift rounds manually when handing it over to a function.
No JavaScript solution? OK, I'll bite...
JavaScript
tests
So i just gave this a bit of a go since I haven't done much scratch programming recently. Just fixing bugs/logic errors in my discord bot and whatnot. Sorry for the abomonation i just created. I think it works though
https://goplay.space/#FbAEPwlpkdX
e: A friend just gave this a go (wayyyy more experienced than me) so here's a more golang-ish approach
https://goplay.space/#G8OxQ-5ILq8
I see what you did there...
C# code. Works forwards and backwards, should handle whatever special characters you code into it. Input is changed to:
Decrypts on "y".
I just noticed that this breaks if you use more than twice the number of characters. To fix that, change the if statement that checks if it's in range into a while loop.
Edit: Found a bug where if the key is too large (like 2000) then it doesn't work properly. I'm not sure why so if anyone knows I'd appreciate if you could share.
Very new to C (learning it through CS50 ), but I actually was on the Caesar Cypher assignment today anyway, so good timing. I'm positive there are ways to do this infinitely better, but this works as far as I can tell. And yes, I'm using the library the course staff built for class use, which conveniently includes a get_string() function...
CS50 is a great course. Enjoy it! :)
Thanks! So far so good.
In response to the edit: why would you even need such a big key (2000)?
You wouldn't as far as I can tell. But in theory the key size shouldn't matter, yet it seems to.
Theory breaks down when the unpredictable happens in reality: hypothetical new user interfaces allow for words to be mapped to a new letter encoding. That's highly unlikely but whose to say it won't happen