560 alp reference sort primitive

[hidanielesgit]

PR for introducing iterator-based (vector) sort primitive. Its use in existing algorithms will follow with a separate PR.

[djelovina]

can there be one version of sort with default cmp = less_then ?

[hidanielesgit]

This will be addressed soon by allowing a single variant of the function which always expects a poset/total order.

[hidanielesgit]

Based on previous discussion I've added a first draft of an ALP relation concept including few basic cases directly usable with alp::sort. Possible items of discussion/review:

• In this draft I've separated the concept of operator from the one of relation, although relations could be seen as operators $SET \times SET \rightarrow bool$ (or operators as ternary relations). On the one hand this allowed to play with properties which are not typical of operators such as reflexivity, etc.On the other hand this creates a bit of redundancy with existing operators::equal, and few others already possibly in use in an operator context.
• We could also add relations such complement, union, and intersection which would allow building more complex relations. While checking would be straightforward (they would "negate", "and", and "or", respectively their source relations) the effect of them on the resulting relation's properties requires a bit of thought.

[djelovina]

Could you also update (if needed)

ALP/include/alp/algorithms/symm_tridiag_eigensolver.hpp

Line 487 in 7315f18

// permutations which sort dtmp

in this branch?

[ghost]

Consider replacing "Used to inspect" -> "Inspects".

[hidanielesgit]

No problem with this. Should we adapt all surrounding docs as well? Just to keep the wording similar across the header.

[anyzelman]

• In this draft I've separated the concept of operator from the one of relation, although relations could be seen as operators

One question here, btw: could a relation be an interpretation of said binary operator, thus potentially preventing duplication? (E.g., the less-than relation could "wrap" around the less-than operator?)

[anyzelman]

One more minor additional comment, while not duplicating existing review comments:) Looking great!

[djelovina]

Could you also update (if needed)

ALP/include/alp/algorithms/symm_tridiag_eigensolver.hpp

Line 487 in 7315f18

// permutations which sort dtmp

in this branch?

I think it is ok to do it in this branch.

[hidanielesgit]

• In this draft I've separated the concept of operator from the one of relation, although relations could be seen as operators

One question here, btw: could a relation be an interpretation of said binary operator, thus potentially preventing duplication? (E.g., the less-than relation could "wrap" around the less-than operator?)

I think this could be a possibility for relations that have similar assumptions on the existence of their respective c++ operators.
For example, for lt the assumption would shift from

Assumes native availability of \a operator> on the given data types

to something like

Assumes availability of ALP operator \a less_than forming a strict total order on SET

This way we could decide the best way to wrap around. Eg, the lt<SET, impl>::check method would rely on less_than<SET, SET, bool, impl>::apply.

On the pros side, I think it would be a way to rely on a single apply logic when this exists. Still the dependence on the existence of an operator would not be strictly enforced, allowing if needed/desired the definition of relations not based on any particular operator (eg, I could decide to create a relation, perhaps with no properties at all, where I could literally enumerate a subset of $SET\times SET$).

Perhaps on the cons side, we would always have to allocate a variable for the boolean output c? Also differently from OP::apply, REL::check does not impose a restrict assumption on the two input pointers since a relation should also be able to check if a REL a.

Does this make sense?

[anyzelman]

• In this draft I've separated the concept of operator from the one of relation, although relations could be seen as operators

One question here, btw: could a relation be an interpretation of said binary operator, thus potentially preventing duplication? (E.g., the less-than relation could "wrap" around the less-than operator?)

I think this could be a possibility for relations that have similar assumptions on the existence of their respective c++ operators. For example, for lt the assumption would shift from

Assumes native availability of \a operator> on the given data types

to something like

Assumes availability of ALP operator \a less_than forming a strict total order on SET

This way we could decide the best way to wrap around. Eg, the lt<SET, impl>::check method would rely on less_than<SET, SET, bool, impl>::apply.

On the pros side, I think it would be a way to rely on a single apply logic when this exists. Still the dependence on the existence of an operator would not be strictly enforced, allowing if needed/desired the definition of relations not based on any particular operator (eg, I could decide to create a relation, perhaps with no properties at all, where I could literally enumerate a subset of SET×SET).

Perhaps on the cons side, we would always have to allocate a variable for the boolean output c? Also differently from OP::apply, REL::check does not impose a restrict assumption on the two input pointers since a relation should also be able to check if a REL a.

Does this make sense?

Yeah I think that makes sense. The other advantage is that all of the ALP operator mechanics get inherited -- auto-vectorisation (if ever applicable), but also operator overloads to specific backends (e.g., Banshee/Snitch).

The allocation of a boolean -- yes and no: a place for it is required, but it need not be dynamically allocated, it goes on the stack? Like const bool check = false; apply( check, ..., ltOp ); At reasonable compiler optimisation levels it is likely to be equivalent even?

[anyzelman]

Ok for me, pending perhaps the dependence of relations on operators issue

[hidanielesgit]

The allocation of a boolean -- yes and no: a place for it is required, but it need not be dynamically allocated, it goes on the stack? Like const bool check = false; apply( check, ..., ltOp ); At reasonable compiler optimisation levels it is likely to be equivalent even?

Correct we would use stack memory there. And I agree the compiler might optimize things anyway given that they are very short (inline-able) function calls.

OK I think I'll try wrapping around existing operators (equal/not-equal if I am not mistaken) before merging into 303 and later if we are OK with it we could also add missing operators.