mdhaber / mparray Goto Github PK

@seberg I'm trying to create an Array API-compliant collection for arbitrary precision floats (e.g. those of mpmath). The main use case I have in mind is the new univariate statistical distributions (gh-15928), which we'll design to accept any Array API-compliant type. (Full functionality will also need array-specific implementations of special functions, which we'll also provide here.) Besides allowing users to use statistical distributions with high precision, these will serve as a backup when straightforward implementations run into numerical issues, and they will help us test and benchmark the accuracy of the distribution functions when evaluated with np.float64.

As someone with a good overview of this stuff, I was hoping you could offer some insight.

1. Does this approach seem crazy?
   The basic idea is to stitch together existing NumPy object array and mpmath features in an Array API compliant way.

• mparray is a subclass of ndarray because it has most of the private methods we need and already works quite well with underlying mpmath context objects (with object dtype). The hope is that we can just override some things and add some new methods to be Array API compliant.
• mparray.broadcast_to and many other functions are just aliases for the equivalents from NumPy. We'll add wrappers of other NumPy functions as needed to provide all the required functions.
• mparray.sin and many other functions are just np.vectorized functions from mpmath.

2. Can we take advantage of some of the dtype stuff you've worked on so that these are not just object dtype? I'm not sure that the behavior needs to be any different than that of object arrays that refer to mpmath objects, but I wonder if there are any features of the new dtype system that would be helpful so that this works with the system rather than around it.

3. For all the Array API-required types (e.g. bool) for which mpmath offers no advantages, should we just use the existing NumPy types, and then mpmath objects would just be extra dtypes? Or could we implement our own float64 using, say, fp objects? I tend toward the latter, because I'd like to just run the standard Array API test suite to check the basic behavior of these things. (Higher-precision contexts would not really need complete tests separately .)

@asmeurer CCing you here because you already know what I'm trying to do - do the questions above make sense?