in reply to Re^4: Sort mechanics problems ...
in thread Sort mechanics problems with objects and potentially contradicting comparisons (would cause infinite loop)

Thank you for the clarification! It was unclear to me at first if maybe it was some kind of infinite recursion problem, but I see now what you mean. As tye has already explained, the answer is clear: a comparator like that means the result of the sort is not well-defined.

Although I think in this case a solution other than sort is more appropriate, just to play out the idea in theory: If you wanted to sort by changing criteria, including criteria based on the position of each item in the list, then something resembling an iterative approach might be possible: 1. calculate and cache the sort criteria, 2. run the sort, 3. check if the ordering is appropriate and if not go back to step 1. That way, you're not violating the requirements of sort (the criteria remain stable during the entire run of sort), although you do have the problem that the algorithm might not converge overall.

Regards,
-- Hauke D

Replies are listed 'Best First'.
Re^6: Sort mechanics problems ...
by anonymized user 468275 (Curate) on Jun 02, 2016 at 10:51 UTC
    For the actual requirement of DB load I can live with what perl sort does: it assumes that the sort is well-defined. And it is, provided the required insertion order actually exists. If there is no solution for the comparison rules, perl sort will break one or more of these rules and deliver anyway a permutation of the list. That permutation will not be a solution to an insoluble schedule and the database will complain. That's fine if I have a single transaction for the entire load and can roll back, which is not difficult to arrange, using DBI.

    One world, one people