Thanks for all the points Marten and Sebastian, I appreciate the inputs. So as a quick update, we made its functionality more general and allowing to expose any kind of relevant DType info which can be used inside NumPy as needed. Please take a look here https://github.com/numpy/numpy/pull/29763
> 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 + > 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`. This should be doable but require some work like registering an abstract `MachArLike` object and might be other things because even subclassing to float, I wasn't able to generate the np.finfo object. > and perhaps also, how NaN (and +/-inf?) are encoded? Their representation follows standard rules irrespective of bit-width so operations are compatible, we do have an internal representation as `QUAD_NAN` and `QUAD_INF` which we often return within C for some ufunc operation. Thanks, Swayam On Thu, Sep 18, 2025 at 8:39 PM Sebastian Berg <[email protected]> wrote: > 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] >
_______________________________________________ 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]
