Yes, the lookup certainly would be an improvement: since the memoization is also $dim-dependent, I've written the rest of the code to assume a series of calculations with $dim fixed, so I'd only need to set up the table once per run.
In general (though I haven't benchmarked it recently[0]) I believe that @$args[ @mapping ] should be very fast, so I think either calculating the mapping array from the lookup table or (memory permitting) replacing the lookup-of-bitswaps with a lookup-of-mappings would be preferable to doing sequences of individual swaps within the array.
(I hadn't mentioned it, but the $args arrayref needs to be preserved, so serial swapping would need to be preceded by a copy.)
Hmm, of course each bitswap could be replaced by a mapping array - that way only $dim * ($dim + 1) / 2 mappings would need to be stored, rather than O($dim * (2 ^ $dim) / 2), at the cost of applying multiple mappings in some cases.
Hugo
[0] bad optimizer, no cookie
In reply to Re^2: better algorithm: bitwise reordering
by hv
in thread better algorithm: bitwise reordering
by hv
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |