Implement path grouping and value mapping in set #35
Labels
No labels
bug
duplicate
enhancement/documentation
enhancement/feature
enhancement/organization
question
rejected
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
UserCurt/mpath#35
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This issue proposes
mpath.sethaving features to allow control over:This would mirror
ResolveUniformOutput,UniformOutputfound 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:
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.UniformValues=false, values should be supplied in cells to avoid ambiguity between “this array is the payload” and “this array contains multiple payloads.”UniformValues=false, but expansion should happen only within each target group, not across groups created byUniformPaths=false.setmay need a diagnostic resolution pass to identify which input path expressions resolve to no concrete targets while preservingresolvedimension-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 eachmpath.set(2x3 pointer, 1x3 vector): assigning a scalar for each element in each columnmpath.set(1x3 pointer, 2x3 vector): assigning a 2x1 column slice to each pointerThis 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
ValueMappingcould take on values"broadcast","cell", or"array"to disambiguate.Separately, when
UniformValues=falseand 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,UniformOutputfor similar control, though those names become awkward forset, 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=...)An additional contract should be satisfied which relates
getandset(without broadcasting):Commit
b541c6faddsNonmissingRequirementtoset. Currently,setcan only check each input pointer independently. WithUniformPaths, this will become configurable.UniformPaths=trueshould combine all resolved targets before checking and assigning themUniformPaths=falseshould keep each input pointer as a separate groupUniformPathsgrouping may also apply toremove, even thoughremovehas no assigned values to map. This may have ramifications on validation specifically because validation behavior is a bit different whetherUniformPaths=trueversusUniformPaths=false. Normally,UniformPaths=truecombines the resolved path groups before applyingNonmissingRequirementand planning removals, whileUniformPaths=falsekeeps each input pointer as a separate validation and removal group.UniformValuesdoes not apply toremovebecause no values are assigned.Commit
8d6a50aremovedUniformOutputandResolveUniformOutputand introducedUniformPathsandUniformValues.setis not complete.Commit
a3506feaddedUniformPathstoremove.Broadcasting (and slicing) is now tracked separately in #44.
This issue is completed in commit
977b9d3.setnow supportsUniformPathsandUniformValueswith similar expected behavior asgetfor all four combinations.The implementation differs from the original proposal to align more closely with
get. The proposal used one global payload whenUniformPaths=falseandUniformValues=true. Instead,UniformPaths=falsenow always requires an outer cell array matching the input pointer array. Each outer cell contains either one payload for its path group or, whenUniformValues=false, an exact target-value grid. This givesUniformPathsthe same structural meaning acrossgetandset.Note that this commit resulted in
setno longer supporting implicit linear ordering assignment.