3 ms·

Here are the rest of the 25 letter sets, found using brute force with the same 1 vowel per word with no repeated letters trick. [['brung', 'waqfs', 'vozhd',

by adamjb 5y ago

Here are the rest of the 25 letter sets, found using brute force with the same 1 vowel per word with no repeated letters trick. [['brung', 'waqfs', 'vozhd', 'cylix', 'kempt'], ['brung', 'waqfs', 'vozhd', 'xylic', 'kempt'], ['jumby', 'waqfs', 'vozhd', 'clipt', 'kreng'], ['jumby', 'waqfs', 'vozhd', 'pling', 'treck'], ['jumby', 'waqfs', 'vozhd', 'prick', 'glent'], ['jumpy', 'waqfs', 'vozhd', 'bling', 'treck'], ['jumpy', 'waqfs', 'vozhd', 'brick', 'glent']] I was a little inspired by this thread [0] about the practicality of implementing brute force algs in pure python for solving wordle. Using only built-ins and with a bit of optimisation [1] it runs in 4 minutes single threaded in cpython. [0] https://twitter.com/eevee/status/1484716294179934209 https://twitter.com/eevee/status/1484716294179934209 [1] Instead of considering every possible combination, it discards non-optimal subsets. E.g. when considering o-words, only u- and a-word combos that already cover 10 letters are looked at. This significantly dampens the combinatorial explosion

hiptobecubic 5y ago
This is a lesson I think should really be brought up more often. Everyone constantly talks about which language is fast or slow, but 9 times out of 10 the question should be which _programs_ are fast or slow. Improvements like this often completely trump everything else. The move from bash to rust is generally a linear improvement, but discovering a better algorithm has way more potential. My experience has been that the range of problems big enough for scale to matter, but small enough for language to matter isn't that big. If I won't wait a year for python to compute something, I probably won't wait three weeks for rust either. Obviously if we're talking about paying for compute cycles then it matters, but surprisingly that's not usually where discussion is focused.

by adamjb 5y ago

hiptobecubic 5y ago

This is a lesson I think should really be brought up more often. Everyone constantly talks about which language is fast or slow, but 9 times out of 10 the question should be which _programs_ are fast or slow. Improvements like this often completely trump everything else. The move from bash to rust is generally a linear improvement, but discovering a better algorithm has way more potential. My experience has been that the range of problems big enough for scale to matter, but small enough for language to matter isn't that big. If I won't wait a year for python to compute something, I probably won't wait three weeks for rust either. Obviously if we're talking about paying for compute cycles then it matters, but surprisingly that's not usually where discussion is focused.