On Fri, Oct 2, 2015 at 4:55 AM, Rob Stewart
On October 1, 2015 10:29:57 PM EDT, Gottlob Frege
wrote: 'range' is wrong and shouldn't be used, unless somehow qualified. The things passed in are ranges, pairs of iterators are ranges, but sort_subrange is using 'range' to mean the after-the-fact range. ie the range that would be there after sorting. Yes it turns out to be the same iterators, but it's confusing.
I had begun a reply with similar complaints, but never finished it, so I'll jump on your bandwagon instead.
I, too, found the naming confusing. I find the interface really odd, too. I've never seen an algorithm that uses an iterator range that refers to a portion of an as-if-sorted range. I suppose there are real use cases or Sean wouldn't have worked on the algorithm he presented, but it's still an odd interface.
I would think sort_subrange would only sort the elements within the subrange (verb object - sort subrange) not sort things from the total range _into_ the subrange.
Right
So 'into' (or similar) might help. ie sort_into_subrange for the first one. (just as a starting idea)
That's better, but it still fails to capture the behavior well. The algorithm acts as if the entire range is sorted, providing a view into a subrange that is actually sorted. Perhaps "view" should be in the name: view_sorted_subrange?
The second could be gather_into_subrange. Leaves you wondering what criteria is used to select the gathering, but you'll check the docs instead guessing incorrectly.
I also think "gather" should be part of the name of the second algorithm.
(NOT understanding is better than MISunderstanding when it comes to names)
Indeed
I do like gather. And the association with nth element.
The problem with nth_element is that no index is given, but that algorithm is already established, so building on that name could help. However, nth_element also specifies the order of the elements to the left and right of the nth.
To be clear, the leftover elements on the left and right aren't even partitioned? ie elements on the left could be greater than some elements on the right?
If that were specified, then the mth_to_nth_element name has merit for Sean's algorithm, but Marshall's is still left without a good name. Finding similar names that vary only on the use of "sort" vs. "gather", for example, would be helpful.
After listening to the talk, IIUC, everything on the left is less than everything in the middle, is less than everything on the right. (And thanks Marshall, I didn't need sleep last night. Sean's talk, followed by Chandler's, followed by... Or I could blame youtube for automatically starting the next video. But I choose Marshall.) Tony
___ Rob
(Sent from my portable computation engine with which I am not forced to top post)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost