On 6/18/21 5:18 AM, Cleiton Santoia via Std-Proposals wrote:
>
>
> With C++ ranges today you can do :
>
> auto const ints = {0,1,2,3,4,5,6};
> auto d = ints | views::transform([](int x) { return x*2; });
> https://godbolt.org/z/qszGT8xj6 <https://godbolt.org/z/qszGT8xj6>

This is great but it'll need to support 2D / 3D / 4D / ... matrices
cleanly also.

auto const mat = {{0,1},{2,3},{4,5},{6,7}};


For parallel computation it'll need to either:

- Apply maths in parallel across the entire piping sequence, element by
element, row by row, vector by vector or matrix by matrix or etc.:

auto res = mat | /* operation 1 */ views::transform([](int x) {
return x*2; }) | /* operation 2 */ views::transform([](int x) {
return x-2; }) | /* operation 3 */ views::transform([](int x) {
return x^2; });

The final "res" here will be filled up in parallel, like if op 1 + op 2
+ op 3 is one giant function running in parallel


- Or apply maths in parallel at each piping operation:

auto res = mat | /* operation 1 */ views::transform([](int x) {
return x*2; }) | /* operation 2 */ views::transform([](int x) {
return x-2; }) | /* operation 3 */ views::transform([](int x) {
return x^2; });

The final "res" here will be filled up with 3 sequential parallel
functions, or one parallel function at the time.


> You're right, I did read very quickly on this but it's the
> standard OR operator being used differently:
>
> Well, I think that is a "good thing" if the language allows you to
> reuse the syntax (operator overload) through library implementations
> without changing the compiler.
Definitely.
>
> So there would seem be be a need here since this is not yet
> implemented if I am right.
>
> Not yet, but being flexible to convert from ranges to *ANY* kind of
> container may be challenging...
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1206r1.pdf
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1206r1.pdf>
> https://timur.audio/how-to-make-a-container-from-a-c20-range
> <https://timur.audio/how-to-make-a-container-from-a-c20-range >
>
> We are also trying to avoid macros... they are not module-friendly,
> not bounded to the type system, among many other issues:
>
> https://stackoverflow.com/questions/14041453/why-are-preprocessor-macros-evil-and-what-are-the-alternatives
> <https://stackoverflow.com/questions/14041453/why-are-preprocessor-macros-evil-and-what-are-the-alternatives>
>
> BR
> Cleiton
>
>
So anyway it's important the C++ remains extensible enough to support
these parallel operations sooner or later.

-- 
*Phil Bouchard*
Founder & CTO
C.: (819) 328-4743
Fornux Logo <http://www.fornux.com>