Skip to content

v1 convention: pair unlabeled operands with dimensions by size, raise on ambiguity #736

@FBumann

Description

@FBumann

Part of the v1 convention (#714, spec in arithmetics-design/convention.md, introduced by #717). The rule is specified but not yet implemented — this issue tracks the implementation.

The rule

Unlabeled operands — numpy arrays, lists, polars Series — carry no labels to align by, so they pair with the linopy operand's dimensions by size: each axis adopts the dimension (and the coordinates) whose length matches. The pairing must be determined by the sizes alone — when it would be a guess, raise.

Spec vs. today

With x(time: 5), rect(a: 4, time: 5), sq(a: 4, b: 4):

Operation Today (leading-positional) v1 spec (size-determined)
np.arange(5.) + x maps to time maps to time (unique match)
np.arange(4.) + x raises (opaque xarray error) raises with a linopy message (no size match)
np.arange(4.) * rect maps to a maps to a (unique match)
np.arange(5.) * rect raises maps to time (unique match, not the leading dim)
np.arange(4.) * sq silently maps to a raises — ambiguous (a or b?)
np.arange(16.).reshape(4,4) * sq maps to (a, b) in order raises — ambiguous (sizes cannot tell (a, b) from (b, a))
[1., 2., 3., 4.] + x legacy: silent left-join / v1: coord-mismatch raise raises with a linopy message (no size match)

The fix for an ambiguous case is to name the dimensions: wrap the array in an xarray.DataArray (or use a pandas Series/DataFrame with a named index).

Implementation notes

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions