Skip to content

Add notes on unexpected inputs and mixing array types to Scope section #58

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.

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 3, 2020
Merged

Add notes on unexpected inputs and mixing array types to Scope section #58

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions spec/purpose_and_scope.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -109,6 +109,13 @@ extensions are dealt with_):
particular way of building regular functions with a few extra
methods/properties._

7. Behaviour for unexpected/invalid input to functions and methods.

_Rationale: there are a huge amount of ways in which users can provide
invalid or unspecified input to functionality in the standard. Exception
types or other resulting behaviour cannot be completely covered and would
be hard to make consistent between libraries._


**Non-goals** for the API standard include:

Expand All @@ -126,6 +133,13 @@ extensions are dealt with_):
library switches from one array type to another, some testing and possibly
code adjustment for performance or other reasons may be needed._

- Making it possible to mix multiple array libraries in function calls.
Copy link
Member

Choose a reason for hiding this comment

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

What about native Python types (int, float, bool, list)? I've been trying to avoid using them anywhere in the test suite except for full, but perhaps that is too restrictive. OTOH, float((), 1.0, dtype=float64) is more explicit about the dtype than just 1.0.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good question. This was discussed in gh-14, with the decision that it shouldn't be allowed in functions calls, and that we'd need a special case for array + scalar (to be added to the dunder methods). I will need to double check if that's spelled out clearly enough.

Copy link
Member Author

Choose a reason for hiding this comment

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

EDIT: "shouldn't be allowed" --> "shouldn't be required".

Copy link
Member Author

Choose a reason for hiding this comment

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

I looked into this, the Python types clarification is needed. I believe it should go into the sections "Function and method signatures" and "Array object" rather than here. So I'll send a follow-up PR for that.

Copy link
Member Author

Choose a reason for hiding this comment

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

  • I've just tested with TensorFlow 2.3.0 and recent JAX and CuPy; it looks like all libs now support using scalars in function calls. This needs to be stated explicitly.
  • The type promotion section says "Non-array ("scalar") operands are not permitted to participate in type promotion.", so that part is covered.


_Most array libraries do not know about other libraries, and the functions
they implement may try to convert "foreign" input, or raise an exception.
This behaviour is hard to specify; ensuring only a single array type is
used is best left to the end user._


### TBD whether or not in scope, or for a later version

Expand Down