Matthew Barber
Matthew Barber
Initialising an [interchange protocol](https://data-apis.org/dataframe-protocol/latest/API.html) buffer (`_VaexBuffer`) only works for vaex columns with NumPy backends https://github.com/vaexio/vaex/blob/35c250d585f889272b8ef1096de6fa5462816f52/packages/vaex-core/vaex/dataframe_protocol.py#L241-L244 `_VaexBuffer.__init__()` is private API, but affects interchange with different libraries as this is called when...
When introducing complex dtypes and updating/introducing related functions (#373), I wonder if we'd want to introduce a `cinfo()` function ala `iinfo()`/`finfo()`. What would its resulting info object look like? I...
Currently [`__getitem__()`](https://data-apis.org/array-api/latest/API_specification/generated/signatures.array_object.array.__getitem__.html#signatures.array_object.array.__getitem__)/[`__setitem__()`](https://data-apis.org/array-api/latest/API_specification/generated/signatures.array_object.array.__setitem__.html#signatures.array_object.array.__setitem__) accept `array` as keys, which implicitly has to be boolean arrays, or 0d integer arrays i.e. has a working [`__index__()`](https://data-apis.org/array-api/latest/API_specification/generated/signatures.array_object.array.__index__.html#signatures.array_object.array.__index__). The latter is not an obvious concept to...
Hello, thank you for writing this software and releasing the source code, as well as your blog post on it! It's been personally useful to see how you implemented `sts`...
WIP PR to resolve https://github.com/HypothesisWorks/hypothesis/issues/3422. That means 1) complex support 2) versioning namespaces. Not particularly looking for a thorough review just yet, but would of-course appreciate feedback and ideas. Prior...
Currently versioning in our docs works building pages for released versions (i.e. just `2021.12` for now) a final time, to be linked to later. So in the [`gh-pages` branch](https://github.com/data-apis/array-api/tree/gh-pages), you...
**PR which depends on #484** In yesterdays meeting @oleksandr-pavlyk bought up that NumPy's `iinfo()`/`finfo()` returns info objects with a `dtype` attribute. ~There seemed to be no objections, but it turns...
We currently have respective dunder methods for [bool](https://data-apis.org/array-api/draft/API_specification/generated/array_api.array.__bool__.html)/[ints](https://data-apis.org/array-api/draft/API_specification/generated/array_api.array.__int__.html)/[floats](https://data-apis.org/array-api/draft/API_specification/generated/array_api.array.__float__.html), so if just for consistency `x.__complex__()` seems nice. Personally I've found the other methods hella useful for `array-api-tests` and Hypothesis, so imagine...
Per discussion in #433 and yesterdays meeting, this PR makes `finfo()` support complex dtypes by returning information of its real-valued component dtype, e.g. ```python >>> xp.finfo(xp.complex64) finfo_object( bits=32, eps=1.1920928955078125e-07, max=3.4028234663852886e+38,...
`xp.__array_api_version__` has been specified in our [Versioning](https://data-apis.org/array-api/latest/future_API_evolution.html#versioning) section for a while now (~2yrs), but no such mention of it is found in the API specification section, which is probably why...