Re: [boost] Painting a bikeshed ...

Subject: Re: [boost] Painting a bikeshed ...
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2015-10-02 10:49:33

On Fri, Oct 2, 2015 at 4:55 AM, Rob Stewart <rob.stewart_at_[hidden]> wrote:
> On October 1, 2015 10:29:57 PM EDT, Gottlob Frege <gottlobfrege_at_[hidden]> 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