Timeline for Abbreviate that US state!
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 27, 2017 at 18:55 | comment | added | Arnauld | @Hankrecords This one has become more complex than I wanted it to be. You may want to have a look at this one, which is using the same principle (a hash function generating an index into a lookup table) but with a simpler formula and a simpler dataset. Does that make sense? | |
| May 27, 2017 at 7:46 | comment | added | ovs | I found an alternative 76 bytes search string with less modulo operations | |
| May 26, 2017 at 14:30 | comment | added | Steve Bennett | now mine is 135! | |
| May 26, 2017 at 13:43 | comment | added | Steve Bennett | Damn, my hand-crafted solution is one byte longer :/ | |
| May 26, 2017 at 11:12 | comment | added | Arnauld | @Hankrecords Sure, will do. (But I'm in a train with limited Internet access right now.) | |
| May 26, 2017 at 11:10 | history | edited | Arnauld | CC BY-SA 3.0 |
saved 20 bytes
|
| May 26, 2017 at 10:17 | comment | added | Hankrecords | Could you explain to a newb what this does? | |
| May 26, 2017 at 8:13 | comment | added | Arnauld |
@ASCII-only This is bruteforced on arbitral ranges, so it's only guaranteed to be optimal for X MOD[50-1000] MOD[50-1000] MOD[50-100]. But the .slice(1) was a mistake. Currently running again on the whole string.
|
|
| May 26, 2017 at 8:10 | comment | added | ASCII-only | Is this bruteforced to be optimal using this method? | |
| May 26, 2017 at 8:03 | history | answered | Arnauld | CC BY-SA 3.0 |