Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Array-API interfaces #25

Closed
jorenham opened this issue Mar 21, 2024 · 4 comments
Closed

Array-API interfaces #25

jorenham opened this issue Mar 21, 2024 · 4 comments

Comments

@jorenham
Copy link
Owner

jorenham commented Mar 21, 2024

https://data-apis.org/array-api/latest/API_specification/index.html

goal

The goal is to provide Protocols that can be used to type e.g. scipy.fft.fftfreq (through its xp kwarg) and scipy.fft.fftshift (via the passed array).

the (big) problems

  • The dtype spec only defines __eq__, which also exists in object. So it's impossible to (structurally) type a "dtype".
  • In the same way, it's impossible to (structurally) type a "device".
  • Shapes are defined as tuples of "something". So the best we can do is type the number of dimensions, and ignore the axis types.

This means that static type-checkers won't be able to see the difference between a boolean array on your CPU, and a complex-floating array on a quantum computer within the core of a neutron star in the Andromeda galaxy.

so now what?

We can still figure out the following types:

  • Array + the dimensionality (because shape: tuple[?, ...] kinda tells us the ndim, but not the actual shape)
  • Namespace, which is a protocollable module-type (often named xp), that could give us
    • xp.array: the specific Array type (but there's still no HKT after asking for it for over 6 years...), and
    • xp.(bool|((u?)int|float|complex)(8|16|32|64)) -i.e. the impossible-to-type DType types (🎩 🪄 🐰)
    • xp.__array_namespace_info__() -> Info (docs), an object with some other "magical" methods:
      • .default_device() -> DefaultDevice
      • .devices() -> list[Device]
      • .dtypes(*, device: Device?, kind: Kind?) - with Kind a literal string category, which allows us to "categorize" the e.g. floats, ints, and complexes (assuming the lib properly typed it), i.e. as type aliases.

problem solved: just type the untypeable

Note that we can also obtain the Info type via Array, since Array.__array_namespace__() -> Namespace[Info] s.t. Namespace[InfoT].__array_namespace_info__() -> InfoT (ignoring the versions).
So we can get all dtype types from either Array or Namespace, and we can either one from the other, and vice-versa (i.e. bidirectionally in both ways, and also the other way around).

@jorenham jorenham added this to the v1.0.0 milestone Mar 21, 2024
@jorenham

This comment was marked as outdated.

@jorenham

This comment was marked as outdated.

@jorenham jorenham self-assigned this Oct 26, 2024
@jorenham jorenham pinned this issue Oct 26, 2024
@jorenham

This comment was marked as resolved.

@jorenham
Copy link
Owner Author

@jorenham jorenham removed this from the v1.0.0 milestone Nov 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant