What a selection operator could look like

[byjtew]

Closes #270

• Wrapping the selection operators in their own namespace to avoid confusion: grb::operators::select::

• Implement selectLambda

• Distributed backends implementation

• In-place variants (should come in a separate PR)

• Masked variants (should come in a separate PR)

• Pattern matrices support (should come in a separate PR)

[anyzelman]

The current state does not have bsp1d nor hybrid implementations of select, that's correct right? I think this is a super useful enhancement, but before merge it should have those distributed-memory implementations also

[byjtew]

The current state does not have bsp1d nor hybrid implementations of select, that's correct right? I think this is a super useful enhancement, but before merge it should have those distributed-memory implementations also

Absolutely, I also wanted to switch the namespace from operators:: to select_operators:: or operators::select:: since they have different signatures than usual operators::

I'll ping you once it will be implemented

[anyzelman]

The current state does not have bsp1d nor hybrid implementations of select, that's correct right? I think this is a super useful enhancement, but before merge it should have those distributed-memory implementations also

Absolutely, I also wanted to switch the namespace from operators:: to select_operators:: or operators::select:: since they have different signatures than usual operators::

I'll ping you once it will be implemented

maybe just grb::select?

[byjtew]

maybe just grb::select?

But then it could be either the primitive or the operator's namespace, what about grb::select::operators ?

[anyzelman]

maybe just grb::select?

But then it could be either the primitive or the operator's namespace, what about grb::select::operators ?

Oh right.. It could still work by having select as a class with the "primitive call" via operator() and the pre-defined lambdas as public static members, but that's perhaps a bit hacky. Maybe just think of something and we can look at it in more detail later, once it's more or less ready?

[anyzelman]

Also doc/spec should be added to base/blas3.hpp

[anyzelman]

Thanks for this useful primitive!

I think this one can be simplified as in the comments. The suggested simplifications should benefit both usage as well asimplementation.

[anyzelman]

This one is ready to merge (after conflict resolution)

[anyzelman]

This one is ready to merge (after conflict resolution)

Correction: unit tests still detect a bug in BSP1D, fixing it is TODO

[anyzelman]

Fixed

[anyzelman]

Some final tests (with LPF) are running, as is the CI. Will merge if all OK.

Concept release notes:

This MR introduces the matrix selection feature -- given a operator that takes matrix nonzero coordinates and a value as arguments and produces a boolean, elements from an input matrix are selected to be copied in some output matrix. This primitive operates in an out-of-place fashion. In-place semantics may be achieved via a temporary (pattern) matrix and fold, and thus are currently not planned to be added. Standard matrix selection operators such as (strictly) lower triangular etc. are provided, including type traits for them. Non-standard selection operators provided by users are simple to add as the new grb::select primitive accepts arbitrary lambda functions as a selection operator as well.

This MR also fixes a bug for the BSP1D and hybrid eWiseApply on matrices with the resize mode, which could return SUCCESS even if it was not successful. The MR includes unit tests for matrix distributions and the new select operator, as well as code style fixes in related and unrelated files.