Last active
November 27, 2015 19:20
-
-
Save gvaughn/b295e69b4eb302a4fab5 to your computer and use it in GitHub Desktop.
Caesar Cipher ElixirGolf
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# for an offset range of -26 to + 26 | |
# 114 characters | |
[n,p]=IO.gets("")|>String.split",";IO.puts for c<-to_char_list(p),do: c<97&&c||97+rem c-71-String.to_integer(n),26 | |
# for any offset range | |
# 122 characters | |
[n,p]=IO.gets("")|>String.split",";IO.puts for c<-to_char_list(p),do: c<97&&c||97+rem c-71-rem(String.to_integer(n),26),26 | |
# with @MPAherns use of a binary generator in the list comprehension | |
# 103 characters | |
[n,p]=IO.gets("")|>String.split",";IO.puts for<<c<-p>>,do: c<97&&c||97+rem c-71-String.to_integer(n),26 |
Great, that's really helpful... Thanks Ben...
Now I'm tweet sized by doing the calculation inline instead of calculating d
. 121 characters
Oh man you are the one to beat now!
115 characters
To be fair, the posted solution only works for offsets up to 26. If we want larger ones, then I can do it in 123 chars:
[n,p]=IO.gets("")|>String.split",";IO.puts for c<-to_char_list(p),do: c<97&&c||97+rem(c-71-rem(String.to_integer(n),26),26)
The posted solution in the gist is 122 characters and works for any offset. I still consider that my own work before looking at how Henrick blended our approaches. That would also let me do 114 characters for an offset of -26 to +26.
Great work... the rules don't state anything about offsets over 26 chars so, it's perfectly valid. Thanks for writing the descriptions I'll be sure to link to it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I started with a basic working solution:
d
) pipeline@a
) isn't really a character savings, but I thought it would be at firstd
is what used to be called aListDict
but has been removed. It's much like aKeyword
list but does not insist on atom keys. It's going to create a list of 2-tuples like this:[{"d", "a"}, {"e", "b"}, {"f", "c"}, {"g", "d"}, {"h", "e"}, {"i", "f"}, {"j", "g"}, {"k", "h"}, {"l", "i"}, {"m", "j"}, {"n", "k"}, {"o", "l"}, {"p", "m"}, {"q", "n"}, {"r", "o"}, {"s", "p"}, {"t", "q"}, {"u", "r"}, {"v", "s"}, {"w", "t"}, {"x", "u"}, {"y", "v"}, {"z", "w"}, {"a", "x"}, {"b", "y"}, {"c", "z"}]
. I could have used aMap
here, but this saved a character or 2 in the end.Enum.map_join
is handy for the output because we want to map and then join the results back into a string. The function passed to it is using theAccess
protocol to look up in thed
dictionary. This returnsnil
if no matching element was found, so||
is used in that case which preserves spaces.apply
was a handy way to take the split string of the user's input and turn it into parameters forencode
I went through some intermediate steps, but ultimately ended up at 168 characters (wrapped for readability here):
Further golfing steps:
apply
takes an anonymous functiond
. It gets recalculated for each character of input. Horribly inefficient! But it saves a couple of characters and that's the golfing goal.&
) saved a few more chars.d
above. That's what got me under 200 characters and where I stopped.Last minute change:
I realized I was no longer using any
Stream
functions, so getting rid of that import takes me down to 168 characters.