Implement path grouping and value mapping in set #35

Closed
opened 2026-07-03 06:15:21 +00:00 by UserCurt · 6 comments
UserCurt commented 2026-07-03 06:15:21 +00:00 (Migrated from codeberg.org)

This issue proposes mpath.set having features to allow control over:

  1. How resolved target paths are grouped.
  2. How supplied values are mapped onto those targets.

This would mirror ResolveUniformOutput, UniformOutput found in other MPath functions and would be implemented through two differently named arguments:

  • UniformPaths: Controls whether resolved paths from an MPath array are combined into one target array or preserved as a separate group for each input MPath element.
  • UniformValues: Controls whether the supplied value is one payload assigned to every target or a container of per-target payloads.

Combinations of these arguments

  • UniformPaths=true, UniformValues=true: Combine all resolved targets and assign the same payload to every target.
  • UniformPaths=false, UniformValues=true: Preserve one target group per input MPath element, but assign the same payload to every target.
  • UniformPaths=true, UniformValues=false: Combine all resolved targets; require a cell array compatible with the combined target shape.
  • UniformPaths=false, UniformValues=false: Preserve one target group per input MPath element; require a cell array of cell arrays, where each inner cell array maps to that input path's resolved target shape.

Important details:

  • With UniformValues=true, any MATLAB value is one assignment payload, including numeric arrays, strings, structs, tables, and objects. For example, [10 20 30] should be assigned as one array payload, not treated as three separate assignments.
  • With UniformValues=false, values should be supplied in cells to avoid ambiguity between “this array is the payload” and “this array contains multiple payloads.”
  • Singleton-dimension expansion may be useful for UniformValues=false, but expansion should happen only within each target group, not across groups created by UniformPaths=false.
  • set may need a diagnostic resolution pass to identify which input path expressions resolve to no concrete targets while preserving resolve dimension-assignment behavior.

Broadcasting

The above uses cell arrays for per-target assignment but does not mention behavior when there is a mismatch is sizing. The input could expand singleton dimensions to match the target pointer size, or to take value slices when the pointer array has singleton dimensions:

  • mpath.set(1x3 pointer, 1x3 vector): assigning a scalar for each
  • mpath.set(2x3 pointer, 1x3 vector): assigning a scalar for each element in each column
  • mpath.set(1x3 pointer, 2x3 vector): assigning a 2x1 column slice to each pointer

This kind of mapping would be more convenient than requiring cells, but it introduces ambiguity because the same array could also be a single payload. A new named argument ValueMapping could take on values "broadcast", "cell", or "array" to disambiguate.

Separately, when UniformValues=false and values are supplied as a cell array, singleton dimensions of the cell array could expand to match the target path shape, allowing one cell element to apply to multiple mpath pointers. When a singleton target dimension corresponds to a non-singleton cell array value dimension, it should give an error.

Renaming arguments in other MPath functions

Other functions from MPath currently use ResolveUniformOutput, UniformOutput for similar control, though those names become awkward for set, where both the MPath expression and assigned value are inputs. This issue also proposes renaming those arguments to match the new proposal above so they are uniformly concept-oriented in name:

  • resolve(..., UniformOutput=...)resolve(..., UniformPaths=...)
  • get(..., ResolveUniformOutput=...)get(..., UniformPaths=...)
  • get(..., UniformOutput=...)get(..., UniformValues=...)
This issue proposes `mpath.set` having features to allow control over: 1. How resolved target paths are grouped. 2. How supplied values are mapped onto those targets. This would mirror `ResolveUniformOutput`, `UniformOutput` found in other MPath functions and would be implemented through two differently named arguments: - `UniformPaths`: Controls whether resolved paths from an MPath array are combined into one target array or preserved as a separate group for each input MPath element. - `UniformValues`: Controls whether the supplied value is one payload assigned to every target or a container of per-target payloads. ### Combinations of these arguments - `UniformPaths=true`, `UniformValues=true`: Combine all resolved targets and assign the same payload to every target. - `UniformPaths=false`, `UniformValues=true`: Preserve one target group per input MPath element, but assign the same payload to every target. - `UniformPaths=true`, `UniformValues=false`: Combine all resolved targets; require a cell array compatible with the combined target shape. - `UniformPaths=false`, `UniformValues=false`: Preserve one target group per input MPath element; require a cell array of cell arrays, where each inner cell array maps to that input path's resolved target shape. Important details: - With `UniformValues=true`, any MATLAB value is one assignment payload, including numeric arrays, strings, structs, tables, and objects. For example, `[10 20 30]` should be assigned as one array payload, not treated as three separate assignments. - With `UniformValues=false`, values should be supplied in cells to avoid ambiguity between “this array is the payload” and “this array contains multiple payloads.” - Singleton-dimension expansion may be useful for `UniformValues=false`, but expansion should happen only within each target group, not across groups created by `UniformPaths=false`. - `set` may need a diagnostic resolution pass to identify which input path expressions resolve to no concrete targets while preserving `resolve` dimension-assignment behavior. ### Broadcasting The above uses cell arrays for per-target assignment but does not mention behavior when there is a mismatch is sizing. The input could expand singleton dimensions to match the target pointer size, or to take value slices when the pointer array has singleton dimensions: - `mpath.set(1x3 pointer, 1x3 vector)`: assigning a scalar for each - `mpath.set(2x3 pointer, 1x3 vector)`: assigning a scalar for each element in each column - `mpath.set(1x3 pointer, 2x3 vector)`: assigning a 2x1 column slice to each pointer This kind of mapping would be more convenient than requiring cells, but it introduces ambiguity because the same array could also be a single payload. A new named argument `ValueMapping` could take on values `"broadcast"`, `"cell"`, or `"array"` to disambiguate. Separately, when `UniformValues=false` and values are supplied as a cell array, singleton dimensions of the cell array could expand to match the target path shape, allowing one cell element to apply to multiple mpath pointers. When a singleton target dimension corresponds to a non-singleton cell array value dimension, it should give an error. ### Renaming arguments in other MPath functions Other functions from MPath currently use `ResolveUniformOutput`, `UniformOutput` for similar control, though those names become awkward for `set`, where both the MPath expression and assigned value are inputs. This issue also proposes renaming those arguments to match the new proposal above so they are uniformly concept-oriented in name: - `resolve(..., UniformOutput=...)` → `resolve(..., UniformPaths=...)` - `get(..., ResolveUniformOutput=...)` → `get(..., UniformPaths=...)` - `get(..., UniformOutput=...)` → `get(..., UniformValues=...)`
UserCurt commented 2026-07-08 16:26:16 +00:00 (Migrated from codeberg.org)

An additional contract should be satisfied which relates get and set (without broadcasting):

values = mpath.get(data, mp, UniformPaths=false, UniformValues=false);
data2 = mpath.set(data, mp, values, UniformPaths=false, UniformValues=false);
An additional contract should be satisfied which relates `get` and `set` (without broadcasting): ```matlab values = mpath.get(data, mp, UniformPaths=false, UniformValues=false); data2 = mpath.set(data, mp, values, UniformPaths=false, UniformValues=false); ```
UserCurt commented 2026-07-19 13:58:11 +00:00 (Migrated from codeberg.org)

Commit b541c6f adds NonmissingRequirement to set. Currently, set can only check each input pointer independently. With UniformPaths, this will become configurable.

  • UniformPaths=true should combine all resolved targets before checking and assigning them
  • UniformPaths=false should keep each input pointer as a separate group
Commit `b541c6f` adds `NonmissingRequirement` to `set`. Currently, `set` can only check each input pointer independently. With `UniformPaths`, this will become configurable. - `UniformPaths=true` should combine all resolved targets before checking and assigning them - `UniformPaths=false` should keep each input pointer as a separate group
UserCurt commented 2026-07-19 15:25:34 +00:00 (Migrated from codeberg.org)

UniformPaths grouping may also apply to remove, even though remove has no assigned values to map. This may have ramifications on validation specifically because validation behavior is a bit different whether UniformPaths=true versus UniformPaths=false. Normally, UniformPaths=true combines the resolved path groups before applying NonmissingRequirement and planning removals, while UniformPaths=false keeps each input pointer as a separate validation and removal group.

UniformValues does not apply to remove because no values are assigned.

`UniformPaths` grouping may also apply to `remove`, even though `remove` has no assigned values to map. This may have ramifications on validation specifically because validation behavior is a bit different whether `UniformPaths=true` versus `UniformPaths=false`. Normally, `UniformPaths=true` combines the resolved path groups before applying `NonmissingRequirement` and planning removals, while `UniformPaths=false` keeps each input pointer as a separate validation and removal group. `UniformValues` does not apply to `remove` because no values are assigned.
UserCurt commented 2026-07-23 00:52:24 +00:00 (Migrated from codeberg.org)

Commit 8d6a50a removed UniformOutput and ResolveUniformOutput and introduced UniformPaths and UniformValues. set is not complete.

Commit `8d6a50a` removed `UniformOutput` and `ResolveUniformOutput` and introduced `UniformPaths` and `UniformValues`. `set` is not complete.
UserCurt commented 2026-07-23 00:54:18 +00:00 (Migrated from codeberg.org)

Commit a3506fe added UniformPaths to remove.

Commit `a3506fe` added `UniformPaths` to `remove`.
UserCurt commented 2026-07-23 07:46:15 +00:00 (Migrated from codeberg.org)

Broadcasting (and slicing) is now tracked separately in #44.

This issue is completed in commit 977b9d3. set now supports UniformPaths and UniformValues with similar expected behavior as get for all four combinations.

The implementation differs from the original proposal to align more closely with get. The proposal used one global payload when UniformPaths=false and UniformValues=true. Instead, UniformPaths=false now always requires an outer cell array matching the input pointer array. Each outer cell contains either one payload for its path group or, when UniformValues=false, an exact target-value grid. This gives UniformPaths the same structural meaning across get and set.

Note that this commit resulted in set no longer supporting implicit linear ordering assignment.

Broadcasting (and slicing) is now tracked separately in #44. This issue is completed in commit `977b9d3`. `set` now supports `UniformPaths` and `UniformValues` with similar expected behavior as `get` for all four combinations. The implementation differs from the original proposal to align more closely with `get`. The proposal used one global payload when `UniformPaths=false` and `UniformValues=true`. Instead, `UniformPaths=false` now always requires an outer cell array matching the input pointer array. Each outer cell contains either one payload for its path group or, when `UniformValues=false`, an exact target-value grid. This gives `UniformPaths` the same structural meaning across `get` and `set`. Note that this commit resulted in `set` no longer supporting implicit linear ordering assignment.
Sign in to join this conversation.
No description provided.