![Mutability & copies/views
x = ones(4)
# y may be a view on data of x
y = x[:2]
# modifies x if y is a view
y += 1
Mutable operations and the concept of views are
important for strided in-memory array implementations
(NumPy, CuPy, PyTorch, MXNet)
They are problematic for libraries based on immutable data
structures or delayed evaluation (TensorFlow, JAX, Dask)
Decisions in API standard:
1. Support inplace operators
2. Support item and slice assignment
3. Do not support out= keyword
4. Warn users that mixing mutating operations and views
may result in implementation-specific behavior](https://image.slidesharecdn.com/mxnetworkshopapistandardizationralfgommers-201214142453/85/Standardizing-on-a-single-N-dimensional-array-API-for-Python-10-320.jpg)
![Data-dependent output shape/dtype
# Boolean indexing, and even slicing
# in some cases, results in shapes
# that depend on values in `x`
x2 = x[:, x > 3]
val = somefunc(x)
x3 = x[:val]
# Functions for which output shape
# depends on value
unique(x)
nonzero(x)
# NumPy does value-based casting
x = np.ones(3, dtype=np.float32)
x + 1 # float32 output
x + 100000 # float64 output
Data-dependent output shapes or dtypes are
problematic, because of:
● static memory allocation (TensorFlow, JAX)
● graph-based scheduling (Dask)
● JIT compilation (Numba, PyTorch, JAX,
Gluon)
Value-based dtype results can be avoided.
Value-based shapes can be important - the API
standard will include but clearly mark such
functionality.](https://image.slidesharecdn.com/mxnetworkshopapistandardizationralfgommers-201214142453/85/Standardizing-on-a-single-N-dimensional-array-API-for-Python-12-320.jpg)
More Related Content
What's hot (20)
Similar to Standardizing on a single N-dimensional array API for Python (20)
More from Ralf Gommers (9)
Recently uploaded (20)
Standardizing on a single N-dimensional array API for Python
- 1. Standardizing on a single N-dimensional array API for Python Ralf Gommers MXNet workshop, 14 Dec 2020
- 2. Array-based computing in Python
- 3. Today’s Python data ecosystem Can we make it easy to build on top of multiple array data structures?
- 4. State of compatibility today All libraries have common concepts and functionality. But, there are many small (and some large) incompatibilities. It’s very painful to translate code from one array library to another. Let’s look at some examples!
- 5. Consortium for Python Data API Standards A new organization, with participation from maintainers of many array (or tensor) and dataframe libraries. Concrete goals for first year: 1. Define a standardization methodology and necessary tooling for it 2. Publish an RFC for an array API standard 3. Publish an RFC for a dataframe API standard 4. Finalize 2021.0x API standards after community review See data-apis.org and github.com/data-apis for more on the Consortium
- 6. Goals for and scope of the array API Syntax and semantics of functions and objects in the API Casting rules, broadcasting, indexing, Python operator support Data interchange & device support Execution semantics (e.g. task scheduling, parallelism, lazy eval) Non-standard dtypes, masked arrays, I/O, subclassing array object, C API Error handling & behaviour for invalid inputs to functions and methods Goal 1: enable writing code & packages that support multiple array libraries Goal 2: make it easy for end users to switch between array libraries In Scope Out of Scope
- 7. Array- and array-consuming libraries Using DLPack, will work for any two libraries if they support device the data resides on x = xp.from_dlpack(x_other) Data interchange between array libs Portable code in array-consuming libs def softmax(x): # grab standard namespace from # the passed-in array xp = get_array_api(x) x_exp = xp.exp(x) partition = xp.sum(x_exp, axis=1, keepdims=True) return x_exp / partition
- 8. What does the full API surface look like? ● 1 array object with ○ 6 attributes: ndim, shape, size, dtype, device, T ○ dunder methods to support all Python operators ○ __array_api_version__, __array_namespace__, __dlpack__ ● 11 dtype literals: bool, (u)int8/16/32/64, float32/64 ● 1 device object ● 4 constants: inf, nan, pi, e ● ~115 functions: ○ Array creation & manipulation (18) ○ Element-wise math & logic (55) ○ Statistics (7) ○ Linear algebra (22) ○ Search, sort & set (7) ○ Utilities (4)
- 10. Mutability & copies/views x = ones(4) # y may be a view on data of x y = x[:2] # modifies x if y is a view y += 1 Mutable operations and the concept of views are important for strided in-memory array implementations (NumPy, CuPy, PyTorch, MXNet) They are problematic for libraries based on immutable data structures or delayed evaluation (TensorFlow, JAX, Dask) Decisions in API standard: 1. Support inplace operators 2. Support item and slice assignment 3. Do not support out= keyword 4. Warn users that mixing mutating operations and views may result in implementation-specific behavior
- 11. Dtype casting rules x = xp.arange(5) # will be integer y = xp.ones(5, dtype=xp.float32) # This may give float32, float64, or raise dtype = (x * y).dtype Casting rules are straightforward to align between libraries when the dtypes are of the same kind Mixed integer and floating-point casting is very inconsistent between libraries, and hard to change: Hence this will remain unspecified.
- 12. Data-dependent output shape/dtype # Boolean indexing, and even slicing # in some cases, results in shapes # that depend on values in `x` x2 = x[:, x > 3] val = somefunc(x) x3 = x[:val] # Functions for which output shape # depends on value unique(x) nonzero(x) # NumPy does value-based casting x = np.ones(3, dtype=np.float32) x + 1 # float32 output x + 100000 # float64 output Data-dependent output shapes or dtypes are problematic, because of: ● static memory allocation (TensorFlow, JAX) ● graph-based scheduling (Dask) ● JIT compilation (Numba, PyTorch, JAX, Gluon) Value-based dtype results can be avoided. Value-based shapes can be important - the API standard will include but clearly mark such functionality.
- 13. Where are we now, and what’s next? The array API standard is >90% complete and published for community review. Still work-in-progress are: ● Data interchange with DLPack ● Device support ● Data-dependent shape handling ● A handful of regular functions (linalg, result_type, meshgrid) Important next steps will be: 1. Complete the library-independent test suite 2. First (prototype) implementations in libraries 3. Get sign-off from maintainers of each array library 4. Define process to handle future & optional extensions
- 14. Thank you Consortium: ● Website & introductory blog posts: data-apis.org ● Array API main repo: github.com/data-apis/array-api ● Latest version of the standard: data-apis.github.io/array-api/latest ● Members: github.com/data-apis/governance Find me at: [email protected], rgommers, ralfgommers Try this at home - installing the latest version of all seven array libraries in one env to experiment: conda create -n many-libs python=3.7 conda activate many-libs conda install cudatoolkit=10.2 pip install numpy torch jax jaxlib tensorflow mxnet cupy-cuda102 dask toolz sparse