| Bytes | Lang | Time | Link |
|---|---|---|---|
| 022 | AWK F "" | 241127T221538Z | xrs |
| 054 | Setanta | 240810T054650Z | bb94 |
| 020 | JavaScript Node.js | 240810T003215Z | Andrew B |
| 026 | Python | 171205T201542Z | Sam Howa |
| 010 | Husk | 171207T110918Z | Martin E |
| 073 | C++ | 170905T221332Z | HatsuPoi |
| 011 | CJam | 171207T105255Z | Martin E |
| 012 | GolfScript | 171207T105141Z | Martin E |
| 036 | Haskell | 171028T213954Z | totallyh |
| 013 | K oK | 171023T092944Z | mkst |
| 013 | Dyalog APL | 170909T132716Z | Adalynn |
| 025 | JavaScript ES6 | 170905T160723Z | Shaggy |
| nan | 170907T134816Z | Bruno Co | |
| 028 | Python 2 | 170905T171023Z | Jonathan |
| 039 | C gcc | 170905T155031Z | cleblanc |
| 024 | Perl 5 | 170906T134643Z | Dom Hast |
| 011 | 05AB1E | 170905T160147Z | Mr. Xcod |
| 015 | MATL | 170905T154139Z | Luis Men |
| 022 | Perl 6 | 170905T182548Z | Massa |
| 028 | Excel | 170906T091017Z | Wernisch |
| 026 | Java 8 | 170905T160134Z | Roberto |
| 010 | Jelly | 170906T074021Z | Jonathan |
| 013 | Golfscript | 170906T013735Z | Josiah W |
| nan | Perl 5 | 170905T203524Z | Xcali |
| 023 | Proton | 170905T180941Z | totallyh |
| 289 | C# .NET Core | 170905T164620Z | snorepio |
| 012 | Japt | 170905T155122Z | Shaggy |
| 011 | Jelly | 170905T155418Z | Erik the |
| 012 | Pyke | 170905T160433Z | Mr. Xcod |
| 013 | Pyth | 170905T154609Z | Mr. Xcod |
| 029 | Python 2 | 170905T153202Z | totallyh |
Python, 26 bytes
lambda S:1923136>>len(S)&7
With a debt of thanks (for my second straight code-golf try) to Jonathan Frech's answer -- I wouldn't have thought to use the string length instead of a distinguishing letter!
This code derives from my experience with De Bruijn Sequences and programming for chess.
In chess, you often work with several 64-bit integers, where each bit indicates something is true or false about the corresponding square on the chessboard, such as "there is a white piece here" or "this square contains a pawn".
It is therefore useful to be able to quickly convert 2**n to n quickly and cheaply. In C and C++, the quickest way to do this is to multiply by a 64-bit De Bruijn sequence -- equivalent to shifting by n bits -- then right-shift 58 (to put the first six bits last -- make sure you're using an unsigned int or you'll get 1s half the time) and look up this 0..63 number in a table that gives you the corresponding n which is in the same range, but rarely the same number.
This is kind of related. Instead of changing from 2**n to n, however, we want to change from n to some other 3-bit number. So, we hide our 3-bit numbers in a magic 31-bit number (a 28-bit shift requires bits 28-30, with numbering starting at 0.)
I generated the number needed by just seeing what values had to fall where (trying both 0..6 and 1..7 as the output sets). Fortunately, the overlapping values (14, 16, and 17) happen to work out! And since the first tri-bit is 000 and the next is 001, we don't need the leftmost 7 bits, resulting in fewer digits -> fewer bytes of source.
The required number is 000xxxx001110101011xxxx100xxxx, where the x's can be 1 or 0 and it doesn't affect the result for these particular subs -- I set them to 0 just to minimize the number, but changing any of the last 8 xs shouldn't affect the source code's length. Setting all the xs to 0, and leaving off the start, gives 1923136 in decimal (or 1D5840 in hex, but then you need the 0x prefix -- shame!) The &7 at the end just masks the last 3 bits, you could also use %8, but then you'd need parentheses due to python's operator precedence rules.
tl;dr: 1923136 encodes each of the three-bit combinations from 0 to 6 in exactly the right spots that these sandwich names happen to fall in place, and then it's a matter of taking the last three bits after a right shift.
Husk, 10 bytes
%7^5←n93ṁc
Another port of my GolfScript answer. I'm sure eventually I'll find a language that can sum the code points for a single byte...
Husk (post-challenge update), 9 bytes
%7^5←n93Σ
Now, Σ does sum code points directly. Since this was added per a request after I answered this challenge, I'm not going to use it as my primary score though.
C++, 119 118 77 76 73 bytes
-41 bytes thanks to Peter Cordes
-1 byte thanks to Zacharý
-3 bytes thanks to Michael Boger
At the string index 3, character for every sandwich is different
#include<string>
int s(char*p){return std::string("enklact").find(p[3]);}
std::initializer_list<char*> t{
"Sweet Onion Chicken Teriyaki",
"Oven Roasted Chicken",
"Turkey Breast",
"Italian BMT",
"Tuna",
"Black Forest Ham",
"Meatball Marinara"
};
for (auto& a : t) {
std::cout << s(a);
}
Golfing with std::string, that was obvious ofc... what was i thinking...
CJam, 11 bytes
l1b93&(5#7%
A port of my GolfScript answer. It costs 1 byte to read the input explicitly, but we save two when summing the code points.
GolfScript, 12 bytes
{+}*93&(5?7%
Maps the inputs (via the sum of their code points) to 0 to 6.
Explanation
Found with a GolfScript snippet brute force tool I wrote a while ago...
{+}* # Sum all code points.
93& # ... AND 93.
( # Decrement.
5? # ... raised to the fifth power.
7% # ... modulo 7.
Here is how this transforms each of the inputs to the desired result:
{+}* 93& ( 5? 7%
Sweet Onion Chicken Teriyaki 2658 64 63 992436543 0
Oven Roasted Chicken 1887 93 92 6590815232 1
Turkey Breast 1285 5 4 1024 2
Italian BMT 965 69 68 1453933568 3
Tuna 408 24 23 6436343 4
Black Forest Ham 1446 4 3 243 5
Meatball Marinara 1645 77 76 2535525376 6
Haskell, 36 bytes
-9 bytes thanks to H.PWiz.
f s=length$fst$span(/=s!!3)"enklact"
Alternate solution, 45 bytes
This uses the indexOf function in Data.List as elemIndex.
import Data.List
(`elemIndex`"enklact").(!!3)
K (oK), 13 bytes
Solution:
"enklact"?*3_
Examples:
> "enklact"?*3_"Black Forest Ham"
5
> "enklact"?*3_"Turkey Breast"
2
Explanation:
Interpretted right-to-left, pull out the 4th element from the input and return the zero-index location in the "enklact" list:
"enklact"?*3_ / the solution
3_ / 3 drop, 3_"Turkey Breast" => "key Breast"
* / first, *"key Breast" => "k"
? / lookup right in left
"enklact" / list to lookup element in
JavaScript (ES6), 25 bytes
0-indexed.
s=>"enklact".search(s[3])
Test it
o.innerText=(f=
s=>"enklact".search(s[3])
)(i.value);oninput=_=>o.innerText=f(i.value)
<select id=i><option selected value="Sweet Onion Chicken Teriyaki">Sweet Onion Chicken Teriyaki</option><option value="Oven Roasted Chicken">Oven Roasted Chicken</option><option value="Turkey Breast">Turkey Breast</option><option value="Italian BMT">Italian BMT</option><option value="Tuna">Tuna</option><option value="Black Forest Ham">Black Forest Ham</option><option value="Meatball Marinara">Meatball Marinara</option></select><pre id=o>
I thought I would post a couple of other alternatives
Javascript 38 bytes
a=s=>(271474896&7<<s.Length)>>s.Length
Explanation: Bit-mask rocks?
Javascript 27 bytes
s=>"240350671"[s.length%10]
Python 2, 38 30 28 bytes
lambda S:`6793**164`[len(S)]
Unfortunately still one byte longer than the best Python 2 answer thus far; though not using the enklact-approach.
Now one byte shorter than i cri everytim's answer!
How does it work?
After a lot of brute force, I found an expression that results in a number which has just the right digits.
I noticed that looking at only one specific digit of the given string's lengths required 3 bytes (%10). So I wrote another Python program (Pastebin link) to further search for numbers who directly map the input strings' lengths to the day of the week.
The magic number looks like this: 6793**164 = 28714733692312345620167113260575862840674216760386883406587492336415023761043044176257567032312859371641211117824224067391750766520256112063756278010050204239810862527958109285342869876264808102743173594017101607983288521836082497514383184553444755034407847810524083812459571382103831904835921560285915349760536969265992879312869538914200854305957428078269094250817029486005437991820466986793657301214564264748923199288698278615871481529585816783654841131577178922192383679718074693535597651237893794976519274268917335387876260270630339777501802739852278932279775510324916969726203688466311848240746465178859847331248655567344801 (a number with an impressive 629 decimal digits)
And as you can see, the number provides the necessary mapping from [28, 20, 13, 11, 4, 16, 17] to [0, 1, 2, 3, 4, 5, 6] (Python strings are 0-indexed):
2871 4 733692 3 1 2 34 5 6 20 1 6711326 0 5758628406742167603868834...
[4]^ [11]^ [13]^ [16]^ ^[17] ^[20] ^[28]
My program also found other expressions which yield numbers with the required property, though they take more bytes to represent (29 instead of 28): 19439**540, 34052**726, 39311**604, 44873**182, 67930**164 and 78579**469. (Those are all the expressions found by the linked program; its execution took several hours.)
Alternative function that requires 28 bytes: lambda S:`7954<<850`[len(S)]
Alternative function that requires 29 bytes: lambda S:`9699<<2291`[len(S)]
Alternative function that requires 30 bytes: lambda S:`853<<4390`[len(S)+9]
Alternative function that requires 31 bytes: lambda S:`1052<<3330`[len(S)+8]
How does it work? How did I generate that number? (30 byte answer)
The 30 byte answer was lambda S:`3879**41`[len(S)%10].
Looking at the input string's lengths [28, 20, 13, 11, 4, 16, 17], I noticed that all last digits in base ten differ, resulting in the list [8, 0, 3, 1, 4, 6, 7]. So I only needed a mapping from that list to the list of all seven days of the week, [0, 1, 2, 3, 4, 5, 6].
My first approach simply used a string to perform the mapping: lambda S:"13*24*560"[len(S)%10], though the string required eleven bytes ("13*24*560").
So I wrote a Python program (Pastebin link) to test for arithmetic expressions which result in an integer with matching digits, hoping to further golf the program. What I came up with thus far is `3879**41` (only ten bytes, the only and thereby smallest expression my program finds).
Of course, there are many different possible expressions one could try; I just got lucky that there was one in the form a**b with a reasonably small result that fit my need.
Just for anyone curious, 3879**41 = 1372495608710279938309112732193682350992788476725725221643007306215781514348937145528919415861895033279220952836384201346579163035594383625990271079 = 1.372... * 10**147.
Another valid function I found whilst searching for alternative expressions that unfortunately requires 32 bytes: lambda S:`7**416`[len(S)%10+290]
05AB1E, 11 bytes
Saved 1 byte thanks to Erik the Outgolfer and 1 byte thanks to Magic Octopus Urn.
.•ΛΓ2º•I3èk
MATL, 16 15 bytes
O5OHlO7KI6vjYm)
Try it online! Or verify all test cases.
Explanation
O5OHlO7KI6 % Push numbers 0, 5, 0, 2, 1, 0, 7, 4, 3, 6
v % Concatenate all numbers into a column vector
j % Push input as a string
Ym % Mean (of ASCII codes)
) % Index into the column vector (modular, 1-based, with implicit rounding)
% Implicit display
Excel, 28 bytes
Using the enklact method:
=FIND(MID(A1,4,1),"enklact")
Java 8, 26 bytes
Credit to @icrieverytim
Takes input as a char[]
s->"enklact".indexOf(s[3])
Jelly, 10 bytes
What's with all this "enklact" business?
⁽ṃXị“Ð$¥»i
A monadic link taking a list of characters and returning the Monday=1 day of the week.
Try it online! or see the test-suite
How?
⁽ṃXị“Ð$¥»i - Link: list of characters, sandwichName e.g. "Tuna"
⁽ṃX - base 250 literal -7761
ị - index into sandwichName (1-indexed & modular) 'n'
“Ð$¥» - dictionary word "retinal"
i - index of 5
Golfscript, 13 bytes
'enklact'\3=?
Takes the 4th character (which, for each, will be unique) and looks it up in the string "enklact".
Alternatively:
'nklact'\3=?)
This takes advantage of the fact that Golfscript's ? function returns -1 if the element searched for is not found (which, for Monday, it will not). If this were allowed, the solution could be reduced by 1 byte.
Perl 5, 43 + 1 (-p) = 44 bytes
for$i(S,O,TUR,I,TUN,B,M){$"++;$_=$"if/^$i/}
Requires the first three characters of input to be upper case.
C# (.NET Core), 289 bytes
using System;class c{delegate int s(string r);static void Main(){s y=x=>{if(x[0]==83)return 1;if(x[0]==79)return 2;if (x[0]==84&x[2]=='r')return 3;if(x[0]==73)return 4;if(x[0]==84)return 5;if(x[0] ==66)return 6;if(x[0]==77)return 7;return 0;};Console.Write(y.Invoke(Console.ReadLine()));}}
Japt, 12 bytes
0-indexed, takes input in lowercase.
`kÇXsm`bUg#
Explanation
Implicit input of lowercase string U
`kÇXsm`
The compressed string kotinsm.
bUg#
Get the first index (b) of the character at index (g) 26 (#) in U. (Yay, index wrapping!)
Implicit output of integer result.
Alternative
Same as the above (and everyone else!), just using the characters at index 3 instead, allowing for title case input.
`klact`bUg3
Jelly, 11 bytes
4ị“-ƭɼoṚ0»i
Explanation:
4ị“-ƭɼoṚ0»i
4ị 4th element of z
“-ƭɼoṚ0»i First index in "enklactate"
Pyth, 13 bytes
x"enklact"@w3
Alternative:
x."atÖÅû"@w3
3 can be substituted by any of the following values: [3, 4, 11, 13, 21, 24, 25, 26]
Python 2, 29 bytes
lambda s:'enklact'.find(s[3])
Explanation
The magic string, enklact, was found by looking for the first column with unique letters.
The first column goes SOTITBM which is not useful 'cause it contains duplicates. The second and third ones also don't work because they are wvutule and eeranaa respectively. The fourth column, however works as it has all unique letters.
lambda s:'enklact'.find(s[3])
lambda s: # declare a function that takes a single paramater s
.find( ) # find the index of the first instance of...
s[3] # the fourth (0-indexing) character of s...
'enklact' # in the magic string