From 6699210727153475ed9cb3ba319f744464602c3e Mon Sep 17 00:00:00 2001 From: Anirudh Dagar Date: Wed, 9 Jun 2021 11:46:29 +0530 Subject: [PATCH 1/3] [Docs] Fix indendation and rendering of Rationale --- spec/purpose_and_scope.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/spec/purpose_and_scope.md b/spec/purpose_and_scope.md index a8fb596c6..56046a277 100644 --- a/spec/purpose_and_scope.md +++ b/spec/purpose_and_scope.md @@ -187,10 +187,10 @@ extensions are dealt with_): 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._ + _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: From 1be4a5cfa460fd30b8e95ad459448b16a5608421 Mon Sep 17 00:00:00 2001 From: Anirudh Dagar Date: Wed, 9 Jun 2021 18:32:04 +0530 Subject: [PATCH 2/3] add link for gh-1 --- spec/use_cases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/use_cases.md b/spec/use_cases.md index bd9f4888e..50b6bd24d 100644 --- a/spec/use_cases.md +++ b/spec/use_cases.md @@ -50,7 +50,7 @@ parallelism in some algorithms. However SciPy itself will not directly start depending on a GPU or distributed array implementation, or contain (e.g.) CUDA code - that's not maintainable given the resources for development. _However_, there is a way to provide distributed or GPU support. Part of the -solution is provided by NumPy's "array protocols" (see gh-1), that allow +solution is provided by NumPy's "array protocols" (see [gh-1](https://github.com/data-apis/array-api/issues/1)), that allow dispatching to other array implementations. The main problem then becomes how to know whether this will work with a particular distributed or GPU array implementation - given that there are zero other array implementations that From 7d40b31ce7ad6faa4ec44d1784f5b330f5e90aa6 Mon Sep 17 00:00:00 2001 From: Anirudh Dagar Date: Wed, 9 Jun 2021 21:48:45 +0530 Subject: [PATCH 3/3] [Docs] Fix rendering of interchange mechanisms --- spec/design_topics/data_interchange.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/spec/design_topics/data_interchange.md b/spec/design_topics/data_interchange.md index a834db3ae..d01f5adad 100644 --- a/spec/design_topics/data_interchange.md +++ b/spec/design_topics/data_interchange.md @@ -12,20 +12,28 @@ The interchange mechanism must offer the following: 1. Data access via a protocol that describes the memory layout of the array in an implementation-independent manner. + _Rationale: any number of libraries must be able to exchange data, and no particular package must be needed to do so._ + 2. Support for all dtypes in this API standard (see {ref}`data-types`). + 3. Device support. It must be possible to determine on what device the array that is to be converted lives. + _Rationale: there are CPU-only, GPU-only, and multi-device array types; it's best to support these with a single protocol (with separate per-device protocols it's hard to figure out unambiguous rules for which protocol gets used, and the situation will get more complex over time as TPU's and other accelerators become more widely available)._ + 4. Zero-copy semantics where possible, making a copy only if needed (e.g. when data is not contiguous in memory). + _Rationale: performance._ + 5. A Python-side and a C-side interface, the latter with a stable C ABI. + _Rationale: all prominent existing array libraries are implemented in C/C++, and are released independently from each other. Hence a stable C ABI is required for packages to work well together._