Re: Proposal: Adding finfo support for user-defined DTypes

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]