On Mon, 2024-08-26 at 11:26 -0400, Marten van Kerkwijk wrote: > I think a NEP is a good idea. It would also seem to make sense to > consider how the dtype itself can hold/calculate this type of > information, since that will be the only way a generic ``info()`` > function can get information for a user-defined dtype. Indeed, > taking > that further, might a method or property on the dtype itself be > the cleaner interface? I.e., one would do ``dtype.info().min`` or > ``dtype.info.min``. >
I agree, I think it should be properties/attributes (I don't think it needs to be a function, it should be cheap?) Now it might also be that `np.finfo()` could keep working via `dtype.finfo` or a dunder if we want to hide it. In general, I would lean towards some form of attributes, even if I am not sure if they should be `.info`, `.finfo`, or even directly on the dtype. (`.info.min` seems tricky, because I am not sure it is clear whether inf or the minimum finite value is "min".) A (potentially very short) NEP would probably help to get momentum on making a decision. I certainly would like to see this being worked on! - Sebastian > -- Marten > > Nathan <nathan.goldb...@gmail.com> writes: > > > 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: sebast...@sipsolutions.net _______________________________________________ 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
