Rene Brun wrote: > I understand somehow your philosophical problems with Sorting > and Collections. One could imagine to add new functionality > to sort collections in general. However, it is my personal > view that sorting problems are in general tightly connected > to an algorithm and efficiency is always an issue. I take issue with the 'always'. In cases of large sorts, this is probably true. But not all sorts are large (on computer scales, that is; sorting 200 things is not problematic for a computer, but painful to look through for a human), and it is quite possible to do this with reasonable (if not maximal) efficiency in a general structure giving users of the ROOT library easy access without having to go through the contortions of the macro you supplied. I note that the designers of the STL also disagree with your philosophy. std::sort(ComparisonFunctor) is supplied for general STL sequences. It probably (okay, almost certainly) is not perfect, and one would no doubt be wise to write one's own code for specific cases which are performance-critical. Nevertheless, the convenience is there when performance is less of an issue and writing readable, maintainable, and error-free code is more of one. > For that reason, I would recommend to use a more "conventional" > approach and far more efficient, using for example TMath::Sort. > In attachment, you will find an example of a short macro creating > filling and sorting histograms. You can change the sorting parameter > at your will. The solution you have given certainly works. I admit that I was unaware of TMath::Sort, but using this is IMHO only slightly better from the user's point of view than quickly hacking together their own bubble sort. In addition, if my experiment's user code is any indication, it seems that many Root users will not think to look further than TList::Sort for sorting functionality, leading to the kinds of hacks I mentioned. This method also assumes that you will always be able to supply a numeric value to use for the sort order; if you can't easily do so, things get a lot harder. Say for example you wanted to sort tracks by PID with + and - charges first, then neutrals, ordering by particle mass within charges, then by transverse momentum within species. This kind of thing would be painful (admittedly not impossible) to use your method for, and easy if all the user had to do was supply a compare function. If someone else provided a patch to allow TList::Sort to take a functional parameter, would the ROOT team be averse to installing it in future versions? George Heintzelman
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:16 MET