Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

feat: addbroadcast_shapes to the specification#983

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
kgryte wants to merge2 commits intodata-apis:main
base:main
Choose a base branch
Loading
fromkgryte:feat/broadcast_shapes

Conversation

@kgryte
Copy link
Contributor

This PR

  • resolvesRFC: addbroadcast_shapes to the specification #893 by adding support forbroadcast_shapes to the specification.
  • follows NumPy et al in supporting an arbitrary number of input shapes to be broadcasted.
  • specifies that only shapes which contain integers are explicitly supported. For shapes containing sentinel values such asNone for a dimension of unknown size, behavior is left unspecified and thus implementation-defined.

@kgrytekgryte added API extensionAdds new functions or objects to the API. topic: ManipulationArray manipulation and transformation. labelsDec 8, 2025
Copy link
Member

@rgommersrgommers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Thanks@kgryte! Overall LGTM and seems good to add this function to the standard. A few comments with the "unknown shape" one the key thing to discuss.

Returns
-------
out: Tuple[int, ...]
a broadcasted shape.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This should probably say something like "The shape should match the regular broadcasting rules as documented in :ref:broadcasting" to make the specification a little bit more tight.

- If not provided one or more arguments, the function **must** return an empty tuple.
.. note::
Array libraries which build computation graphs (e.g., ndonnx and Dask) commonly support shapes having dimensions of unknown size. If a shape contains a value other than an integer (e.g., ``None`` for a dimension of unknown size), behavior is unspecified and thus implementation-defined. Array-conforming libraries **may** choose to propagate such values (e.g., if a shape contains a dimension size of ``None``, the returned broadcasted shape also has a corresponding dimension having a size equal to ``None``) or raise an exception.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This can be phrased such that it works for computation graphs in the expected manner I believe, since the broadcasting math is abstract anyway and any sentinels can propagate correctly. To be discussed in the next call I think.

@lucascolley
Copy link
Member

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@rgommersrgommersrgommers left review comments

Assignees

No one assigned

Labels

API extensionAdds new functions or objects to the API.topic: ManipulationArray manipulation and transformation.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

RFC: addbroadcast_shapes to the specification

3 participants

@kgryte@lucascolley@rgommers

[8]ページ先頭

©2009-2025 Movatter.jp