On Mon, Aug 26, 2024 at 5:42 PM Sebastian Berg <sebast...@sipsolutions.net> wrote: > > 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 >
A namespace attached to the dtype to hold useful constants seems like a good approach. This could also be used to hold type-dependent constants such as `pi`, `e`, etc. for the real floating point types. Over in https://github.com/numpy/numpy/issues/9698, I suggested the name `constants` (https://github.com/numpy/numpy/issues/9698#issuecomment-2186653455). This would also be available for user-defined dtypes, where types such as `quaddtype` (https://github.com/numpy/numpy-user-dtypes/tree/main/quaddtype) , `mpfdtype` (https://github.com/numpy/numpy-user-dtypes/tree/main/mpfdtype), and `logfloat32` (https://github.com/WarrenWeckesser/numtypes) would make available their own representations of `pi`, `e`, etc. There will be some work required to define the semantics of the existing attributes. Not all attributes can be required for all data types. For example, a few considerations off the top of my head: * The `min` and `max` values for `datetime64` andf `timedelta64` would have values that depend on the time unit. * Floating point types that are not IEEE 754 such as IBM double-double wouldn't necessarily have all the attributes IEEE 754 float types have. * The StringDType has a well-defined `min` (the empty string), but not a `max`. Warren > > -- 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: warren.weckes...@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
