(anagrams "abcdefgh") --> 40,320 anagrams in 5.6 seconds
(anagrams "abcdefghi") --> 362,880 anagrams in 64.5 seconds
on my 500 MHz 192Mbyte laptop. Does anyone see any significant speed or code improvements? What about the use of 'append' in the 'aux' function to prepend a character to a string? Would 'string' be a better choice? And how about that 'rotate-string' function? It looks relatively expensive time-wise.
Checking the speed of rotate-string isolated from the anagram algorithm, the Eddie solution is faster, but measuring the speed of the overall algorithm, there seems to be no difference, which 'rotate-string' is used, and the 'rotate/explode' solution looks definitely very elegant.
Sam asked about 'append' versus 'string': 'string' should only be used if elements of the stuff to append have to be converted to strings. when everything is a string already (as in Sam's case) than append is much faster.
I am also contemplating a total different solution for the 'anagram' algorithm: somehow generating the permutations just with numbers and than using 'select' or 'collect' to re-arrange the letters from the string:
Now that's an interesting idea! I think the advantage is that the anagrams can be precomputed for any reasonable length string and then applied to a particular string. I experimented with
Sam's solution is still double as fast and a bit shorter, but the permutations function might come in handy for other projects. Investigating Nigel's links I also realized that other solutions (liked the rank/unrank method) lack a 'rotate' function and are longer for that reason than the newLISP solution.
Developing this I realized that 'rotate' crashes on an empty list. This is fixed and will be in the next developers release.