That seems reasonable to me on its face. There are some corner cases to work out though.
Swayam is tinkering with a quad precision dtype written using rhe new DType API and just ran into the fact that finfo doesn’t support user dtypes: https://github.com/numpy/numpy/issues/27231 IMO any new feature along these lines should have some thought in the design about how to handle user-defined data types. Another thing to consider is that data types can be non-numeric (things like categories) or number-like but not really just a number like a quantity with a physical unit. That means you should also think about what to do where fields like min and max don’t make any sense or need to be a generic python object rather than a numeric type. I think if someone proposed a NEP that fully worked this out it would be welcome. My understanding is that the array API consortium prefers to standardize on APIs that gain tractions in libraries rather than inventing APIs and telling libraries to adopt them, so I think a NEP is the right first step, rather than trying to standardize something in the array API. On Mon, Aug 26, 2024 at 8:06 AM Lucas Colley <lucas.coll...@gmail.com> wrote: > Or how about `np.dtype_info(dt)`, which could return an object with > attributes like `min` and `max`. Would that be possible? > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: nathan12...@gmail.com >
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
