I wonder whether you never needed an anti-sort.
In my definition, “anti-sort” is not “randomization”.
Say your data is sorted by more than one keys. Under normal sort, you will get pretty correlated items together. If each field is Boolean, the neighboring records will have minimal Hamming distance from each other.
Anti-sort should strive to put it in other way – it should try to maximize Hamming distance between subsequent records.
Where is anti-sort useful? It is useful when you want to have a “quick-fact-check” across all the keys of sorting.
For example, you want to test skills portfolio of your house remodeling contractor. So you list out all the remodeling tasks against skills as Boolean fields.
Say some works need only carpentry, some need carpentry and civil work and some need only civil work.
If you sort the list by skills now, you will have carpentry only list at the top and civil only list at the bottom.
Giving one task from each is very difficult if number of such keys grow.
That is where anti-sorted list will come handy.
Can someone write an algorithm for it? [It is tricky! Whether you will place multi-skill tasks at top and keep its complementary as the second? Will you take “a skill at a time” tasks at top and go multi-skill later?]