On Sun, 2019-06-02 at 08:38 +0200, Ralf Gommers wrote: > > > On Sun, Jun 2, 2019 at 3:18 AM Marten van Kerkwijk < > m.h.vankerkw...@gmail.com> wrote: > > > Our API is huge. A simple count: > > > main namespace: 600 > > > fft: 30 > > > linalg: 30 > > > random: 60 > > > ndarray: 70 > > > lib: 20 > > > lib.npyio: 35 > > > etc. (many more ill-thought out but not clearly private > > > submodules) > > > > > > > I would perhaps start with ndarray itself. Quite a lot seems > > superfluous > > > > Shapes: > > - need: shape, strides, reshape, transpose; > > - probably: ndim, size, T > > - less so: nbytes, ravel, flatten, squeeze, and swapaxes. > > > > Getting/setting: > > - need __getitem__, __setitem__; > > - less so: fill, put, take, item, itemset, repeat, compress, > > diagonal; > > > > Datatype/Copies/views/conversion > > - need: dtype, copy, view, astype, flags > > - less so: ctypes, dump, dumps, getfield, setfield, itemsize, > > byteswap, newbyteorder, resize, setflags, tobytes, tofile, tolist, > > tostring, > > > > Iteration > > - need __iter__ > > - less so: flat > > > > Numerics > > - need: conj, real, imag > > - maybe also: min, max, mean, sum, std, var, prod, partition, sort, > > tracet; > > - less so: the arg* ones, cumsum, cumprod, clip, round, dot, all, > > any, nonzero, ptp, searchsorted, > > choose. > > > > Exactly. This is great, thanks Marten. I agree with pretty much > everything in this list. >
It is a bit tricky. I dislike flat for example, but it does have occasional use cases. min/max, etc. are interesting, in that they are just aliases to minimum.reduce, and could be argued to be covered by the ufunc. For other projects, the list of actual usage statistics may almost be more interesting then what we can come up with. Although it depends a bit where the long haul goes (but it seems right now that is not the proposal). For example, we could actually mark all our functions, and then you could test SciPy for "numpy-core" compatible (i.e. test the users). We could also want to work towards reference tests at some point. It would be a huge amount of work, but if other projects would want to help maintain it, maybe it can safe work in the long run? One thing that I think may be interesting, would be to attempt to make a graph of what functions can be implemented using other functions. Example: transpose <-> swapaxes <-> moveaxis Indexing: delete, insert (+empty_like) reshape: atleast_Nd, ravel (+ensure/copy) (and then find a minimal set, etc.) Many of these have multiple possible implementations, though. But if we could create even an indea of such a dependency graph, it could be very cool to find "what is important". Much of this is trivial, but maybe it could help to get a picture of where things might go. Anyway, it seems like a good idea to do something, but what that something is and how difficult it would be seems hard to judge. But I guess that should not stop us from moving. Maybe information of usage and groupings/opinions on importance is already a lot. Best, Sebastian > Ralf > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
