+SG1 concurrency and parallelism <parallel_at_[hidden]> as I wasn't a
member of the list until a moment ago.

On Tue, 25 Jun 2019 at 15:46, Christopher Di Bella <cjdb.ns_at_[hidden]>
wrote:

> I'm researching what is necessary to bring the numeric algorithms into
> namespace std::ranges (for those wondering why it's non-trivial: they
> require close study like those in <algorithm> got from N3351 + ranges
> work). Part of this research involves me consistently scratching my head
> over whether or not all of the numeric algorithms should be imported into
> std::ranges, or if it's possible to get away with just reduce,
> transform_reduce, exclusive_scan, inclusive_scan, transform_exclusive_scan,
> transform_inclusive_scan, and adjacent_difference. iota is deliberately
> not in that list, but that's also not relevant to the discussion I'm
> wanting to have.
>
> Note that I'm only considering the overloads without an ExecutionPolicy.
>
> Are there any practical reasons for reduce(begin(v), end(v), 0, plus{})
> to permit out-of-order computation? For example, is this allowed as an
> implementation?
>
> ```
> template<class InputIterator, class T, class BOp>
> T reduce(InputIterator first, InputIterator last, T init, BOp bop)
> {
> #if NDEBUG
> return reduce(execution::par_unseq, first, last, init, bop);
> #else
> return accumulate(first, last, init, bop);
> #endif // NDEBUG
> }
> ```
>
> If either question can be answered with "yes", then forgetting accumulate
> is a non-starter, and I'll work on nailing down all of the numeric
> algorithms. I suspect this is the case, but lack the experience to answer
> them myself, and am yet to find a proposal or minutes detailing this
> discussion.
>
> If there aren't advantages for this overload of reduce, et al. to
> co-exist with their C++98 counterparts, then I'm inclined to propose that
> only the C++17 names be ported (plus adjacent_difference), because:
>
> 1. It seems redundant for us to have two algorithms that are specified
> differently, but produce equivalent results.
> 1. The ExecutionPolicy numeric algorithms can still have formal
> requirements for associativity and commutativity.
> 2. I've had a teacher pass on a question to me from a student
> asking if they should be using accumulate or reduce, so I have
> teachability concerns.
> 1. It's likely that there are more than two people in the situation
> of 'Curious Student Reading the C++ Reference' and 'Hesitant Teacher'.
> 2. If there's only one name in namespace std::ranges, then advice
> boils down to "prefer what's in namespace std::ranges; the rest are
> historical".
>
> Cheers,
>
> Chris
>