Control over order on repeated dimensions #20

New issue

Open

opened 2025-10-13 09:23:47 +00:00 by UserCurt · 0 comments

UserCurt commented

2025-10-13 09:23:47 +00:00

(Migrated from codeberg.org)

This issue proposes a mechanism to give the user control over the order in which elements appear in shared dimensions. For example, the mpath expression /{A,B}#1/{X,Y}#1 corresponds to [AX; AY; BX; BY] by default. There is currently no way for the user to change the order to instead consider the second instance of #1 first and the first instance second, which would return [AX; BX; AY; BY].

One implementation approach could be through syntax changes. Another implementation option could be through introduction of a new named argument.

Syntax changes: One option is to suffix the dimension specifier with some numerical indicator of the order, delimited by some character. I am not happy with this proposed syntax, but here are the few considered delimiter options:

#1-1 or #1+1 -- Shared symbols with arithmetic in #2 adds parsing complexity and possibly confusing with actual arithmetic operations, though the hyphen looks okay in my opinion
#1#1 -- Similar to ## syntax proposed in #1, though unattractive in my opinion
#1:1 -- Can be confusing with colon syntax described in #2 but also important in #5, though this look good in my opinion
#1,1 -- Shared symbol with set element delimiter in #3 and indexing dimension delimiter in #5, and generally not visually appealing in my opinion

New named argument: One option is to take inspiration from OutputDims in #1 or Listdims #13 by having a named argument, let's name it DimOrder, that indicates the order within each dimension. One option is to have this be a cell array where index i corresponds to dimension i. Each element within this cell array would be a permutation of 1:N where N is the number of times that dimension is repeated in the mpath expression. In the example above /{A,B}#1/{X,Y}#1, the default resolution result [AX; AY; BX; BY] could also be obtained by using OutputDims={[1 2]}, whereas the other resolution result [AX; BX; AY; BY] would have to be obtained by using OutputDims={[2 1]}. Dimensions with a default permutation (1:N) could be left as an empty array in the element of the cell array.

This approach can be confusing with large verbosity if there are many dimensions as each element of the cell array needs to be a valid permutation and at a glance it is unclear which index you are referring to, which can make this error-prone. Usage of a dictionary could be a reasonable alternative. In the other resolution result from before, [AX; BX; AY; BY] could be obtained using OutputDims=dictionary(1, {[2,1]}), which is more verbose in this example but could be less verbose in examples with many dimensions and many re-orderings.

I would prefer not changing the syntax, but I am also dissatisfied with the currently proposed version of new named argument approach.

This issue proposes a mechanism to give the user control over the order in which elements appear in shared dimensions. For example, the mpath expression `/{A,B}#1/{X,Y}#1` corresponds to `[AX; AY; BX; BY]` by default. There is currently no way for the user to change the order to instead consider the second instance of `#1` first and the first instance second, which would return `[AX; BX; AY; BY]`. One implementation approach could be through syntax changes. Another implementation option could be through introduction of a new named argument. **Syntax changes:** One option is to suffix the dimension specifier with some numerical indicator of the order, delimited by some character. I am not happy with this proposed syntax, but here are the few considered delimiter options: - `#1-1` or `#1+1` -- Shared symbols with arithmetic in #2 adds parsing complexity and possibly confusing with actual arithmetic operations, though the hyphen looks okay in my opinion - `#1#1` -- Similar to `##` syntax proposed in #1, though unattractive in my opinion - `#1:1` -- Can be confusing with colon syntax described in #2 but also important in #5, though this look good in my opinion - `#1,1` -- Shared symbol with set element delimiter in #3 and indexing dimension delimiter in #5, and generally not visually appealing in my opinion **New named argument:** One option is to take inspiration from OutputDims in #1 or Listdims #13 by having a named argument, let's name it `DimOrder`, that indicates the order within each dimension. One option is to have this be a cell array where index $i$ corresponds to dimension $i$. Each element within this cell array would be a permutation of 1:N where N is the number of times that dimension is repeated in the mpath expression. In the example above `/{A,B}#1/{X,Y}#1`, the default resolution result `[AX; AY; BX; BY]` could also be obtained by using `OutputDims={[1 2]}`, whereas the other resolution result `[AX; BX; AY; BY]` would have to be obtained by using `OutputDims={[2 1]}`. Dimensions with a default permutation (1:N) could be left as an empty array in the element of the cell array. This approach can be confusing with large verbosity if there are many dimensions as each element of the cell array needs to be a valid permutation and at a glance it is unclear which index you are referring to, which can make this error-prone. Usage of a dictionary could be a reasonable alternative. In the other resolution result from before, `[AX; BX; AY; BY]` could be obtained using `OutputDims=dictionary(1, {[2,1]})`, which is more verbose in this example but could be less verbose in examples with many dimensions and many re-orderings. I would prefer not changing the syntax, but I am also dissatisfied with the currently proposed version of new named argument approach.