On Thu, 2025-09-18 at 09:55 -0400, Marten van Kerkwijk via NumPy- Discussion wrote: > Hi Swayam, > > If we have a slot, I'd prefer it to be more general. However, also > two > other thoughts:
More general may indeed be nice. My biggest question is still a bit how much we care about having some of this available in C nicely, but it may be overloaded. (In C, we mainly need things like "zero" and "one" for np.zeros/np.ones.) > > 1) Might it be possible to do this via subclassing? I.e., if one > creates > a floating type, one subclasses a FloatingDTypeMeta that has some > slots particularly logical for floats, such as the .finfo > information > (it could then be numbers rather than a function), and perhaps > also > how NaN (and +/-inf?) are encoded? Having a superclass (DType subclass) that adds a `.finfo` property seems nice, the question becomes a bit, if this isn't C-side important, there is really a question whether we don't just add it to the class without involving NumPy at all. (Adding a property in C is no harder than adding the slot.) I don't have a strong opinion on it though, I just like the idea of having `.finfo`. > > 2) In a different direction, might it be worthwile considering going > the > other way, for a DType to register a function that provides the > required information with `np.finfo`? That avoids increasing > number > of slots on the DType, and is similar to how a DType also has to > register itself for the casting, ufuncs, etc. (I've been > suggesting Actually, casts *are* stored on the DType (opaquely). On this I disagree, unlike ufuncs, this type of information is directly tied to the DType and I think it is easier to just pass it on at DType registration (that doesn't mean it has to live there forever, that part is opaque). I don't see why to split it out when you would always write it in the same place, basically. Slots are convenient and it is OK if they are a bit of a jungle (better than a jungle of functions IMO). UFuncs are different, they are a mass and they be defined outside of NumPy. They are not closely tied to the DType and it would be inconvenient to expect the DType to provide all UFunc implementations. - Sebastian > that similarly for (arg)sort we don't add slots but rather a > registration mechanism; see discussion in > https://github.com/numpy/numpy/pull/29737). Conceptually, this > could > be as simple as adding to a `dict` keyed by dtype with the value > being another dict that gives `precision`, `eps`, etc. > > All the best, > > Marten > > Swayam Singh via NumPy-Discussion <[email protected]> > writes: > > > Hi all, > > > > Following recent discussion, I wanted to summarize the current > > status of extending `np.finfo` to user-defined DTypes. > > > > At present, there is no way for user DTypes to provide their own > > `finfo` information (e.g., precision, bits, eps) [issue > > #27231](https://github.com/numpy/numpy/issues/27231). > > To address this, [PR > > #29763](https://github.com/numpy/numpy/pull/29763) proposes adding > > a new `NPY_DT_get_finfo` slot so that user-defined floating DTypes > > can expose this metadata. > > One open question from review is whether this should remain > > specific to `finfo`, or if we should generalize the mechanism so > > that other numeric types (e.g., integers via `iinfo`) could also > > expose their own limits. > > > > I’d appreciate feedback on whether we should: > > > > * start with `finfo` support for floating user DTypes only, or > > * aim for a more general interface covering both `finfo`, `iinfo`, > > and potentially other numeric limits. > > > > Best, > > Swayam Singh > > _______________________________________________ > > NumPy-Discussion mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > https://mail.python.org/mailman3//lists/numpy-discussion.python.org > > Member address: [email protected] > _______________________________________________ > NumPy-Discussion mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3//lists/numpy-discussion.python.org > Member address: [email protected] _______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: [email protected]
