Speed isn't the primary objective, but to avoid the digital apocalypse by increasing computer literacy. In particular, with the insane British anagram challenge, any entry that obtains the correct answer wins.scruss wrote: ↑Wed Aug 21, 2019 3:25 pmLor' lummy, are youse all still at this? Perl is Fast Enough for me, so I've not given it much more thought, except for:
Here's how that insane word list stacks up by word length:
- it may be quicker to find anagrams of words all the same length, since by definition two words can only be anagrams of each other if they're the same length. Reading and classifying strings by length is a bit slow under the Unix paradigm as we don't have fixed-length records baked into the filesystem. Either way, you only have to hash far fewer words against one another even if you still need a master array for the final output order.
- each of those comparisons of words of the same length might work quite well as separate threads.
Code: Select all
Length Count % of total 1 26 0% 2 240 0% 3 1910 0% 4 7349 2% 5 17257 4% 6 32498 8% 7 46596 11% 8 57535 13% 9 59453 14% 10 54659 13% 11 45499 11% 12 35410 8% 13 25569 6% 14 17592 4% 15 11264 3% 16 6855 2% 17 3939 1% … (longer words aren't significant as there are so few)
I previously found 32-bit hash algorithms that are sufficient if the number of letters in the word were included as a secondary key. As it was easier to use 64-bit hashes, I never posted the code. It's possible using 32-bit hashes would make the existing C code faster when run on a 32-bit architecture; however, I was hesitant to give the zombies any more access to the encabulator.