You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The standard considers lazy graph libraries so we should be fine. The only large difference I saw was that the .shape attribute should return a tuple of integers or None, whereas our variable.shape attribute returns a symbolic vector variable.
That would be equivalent to our variable.type.shape (static shape).
However they mention it is okay to return a custom type as long as it behaves like a tuple. Our shape does because you can iter/index/tuplify it just fine, so it may be fine?
It seems dangerous to change the behavior of .shape. Opened an issue: data-apis/array-api#891
The text was updated successfully, but these errors were encountered:
Description
https://data-apis.org/array-api/latest/index.html
The standard considers lazy graph libraries so we should be fine. The only large difference I saw was that the
.shape
attribute should return a tuple of integers or None, whereas ourvariable.shape
attribute returns a symbolic vector variable.https://data-apis.org/array-api/latest/API_specification/generated/array_api.array.shape.html#shape
That would be equivalent to our
variable.type.shape
(static shape).However they mention it is okay to return a custom type as long as it behaves like a tuple. Our shape does because you can iter/index/tuplify it just fine, so it may be fine?
It seems dangerous to change the behavior of
.shape
. Opened an issue: data-apis/array-api#891The text was updated successfully, but these errors were encountered: