Skip to content

Mechanism to find complex dtype info #433

Closed
@honno

Description

@honno
Member

When introducing complex dtypes and updating/introducing related functions (#373), I wonder if we'd want to introduce a cinfo() function ala iinfo()/finfo(). What would its resulting info object look like?

I don't see any array/tensor library which implements exactly cinfo(), although there might be an equivalent I'm missing. For say NumPy, was there just not demand for such a function, and/or such a need was somewhat served with finfo()?

>>> np.finfo(np.complex64)
finfo(resolution=1e-06, min=-3.4028235e+38, max=3.4028235e+38, dtype=float32)
>>> assert np.finfo(np.complex64) == np.finfo(np.float32)

Activity

jakirkham

jakirkham commented on May 16, 2022

@jakirkham
Member

Sorry if this is a bit off topic, but I wonder if instead of having different functions like this, we could have just one function that was type agnostic like tinfo or similar. This would save needing to check type and call the right one when determining things like the range of values or similar.

honno

honno commented on May 17, 2022

@honno
MemberAuthor

Sorry if this is a bit off topic, but I wonder if instead of having different functions like this, we could have just one function that was type agnostic like tinfo or similar. This would save needing to check type and call the right one when determining things like the range of values or similar.

My impression is this would be awkward as float and complex dtypes have additional information to ints, so if you don't want polymorphic returns from a universal function (previous unique discussions suggest a hard no), you might want a function (or separate functions) dedicated for bounds and bit-size. Personally whenever I've wanted to know bounds/size for code that deals with both ints and floats, I'm often writing additional logic for float scenarios (NaN branches 🙃), so would be checking dtype family anyway.

jakirkham

jakirkham commented on May 17, 2022

@jakirkham
Member

Here's the results of an integer and floating point type from NumPy (line 1 was the import):

In [2]: np.iinfo(np.int32)
Out[2]: iinfo(min=-2147483648, max=2147483647, dtype=int32)

In [3]: np.finfo(np.float32)
Out[3]: finfo(resolution=1e-06, min=-3.4028235e+38, max=3.4028235e+38, dtype=float32)

Nearly all of the information is shared other than resolution. In fact resolution could even be specified for integers for simplicity (as it would just be 1).

Anyways it's unclear why having one function would be challenging. Though please feel free to clarify

honno

honno commented on May 17, 2022

@honno
MemberAuthor

Nearly all of the information is shared other than resolution. In fact resolution could even be specified for integers for simplicity (as it would just be 1).

Ah resolution=1 seems like a clean solution, although with the spec it's called eps (still feels correct, just not as semantically nice).

Note the np.finfo() repr hides a lot of additional info NumPy finds, although most of that we can ignore. smallest_normal however is an attribute that both np.finfo() and xp.finfo() share—is there a nice solution for smallest_normal here?

jakirkham

jakirkham commented on May 17, 2022

@jakirkham
Member

smallest_normal could also be 1 for integers

We could also make these things None if we prefer that

jakirkham

jakirkham commented on May 17, 2022

@jakirkham
Member

Leo, those show the same attributes as the example above. All they add is bits (which they both have) and smallest_normal (which we are now discussing).

leofang

leofang commented on May 18, 2022

@leofang
Contributor

OK perhaps I should've linked to the corresponding NumPy pages? My point is the returned attributes could increase and further diverge in the future, just like the status quo in NumPy. I feel this unifying discussion would make our life harder when it comes to extensibility in the future.

btw, to clarify:

Ah resolution=1 seems like a clean solution, although with the spec it's called eps (still feels correct, just not as semantically nice).

eps and resolution have different meanings in NumPy.

kgryte

kgryte commented on Jun 2, 2022

@kgryte
Contributor

Not clear to me what info would belong on cinfo. For example, what should eps be for complex numbers? What would min and max be given that complex numbers don't have a natural ordering? Same for smallest_normal?

leofang

leofang commented on Jun 6, 2022

@leofang
Contributor

I'd keep at least bits and eps for cinfo, but definitely exclude min and max because we don't wanna follow NumPy to define some awkward comparison/sort capabilities over complex-valued arrays (IIRC it's discussed long time ago in one of the threads).

honno

honno commented on Jun 23, 2022

@honno
MemberAuthor

How about we have bound-y attributes per component, i.e. {real/imag}_{min/max}, {real/imag}_eps and {real/imag}_smallest_normal? Or just attributes for both the real and imag components (which should be the same), i.e. component_{min/max}, component_eps and component_smallest_normal.

Both of those options do feel weird, but having an array library tell you the bounds can be pretty useful.

kgryte

kgryte commented on Jun 23, 2022

@kgryte
Contributor

Based on feedback in the most recent consortium meeting (2022-06-23), the plan is to open an issue on the NumPy issue tracker to gauge appetite there before moving forward adding cinfo to the specification.

The main argument for adding cinfo to the standard is consistency and thoroughness. However, hard to justify adding to spec atm without having any real-world array library implementations. We'd like to see an array library add a cinfo object first, hence opening an issue on NumPy proposing the addition.

10 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @rgommers@kgryte@jakirkham@leofang@honno

        Issue actions

          Mechanism to find complex dtype info · Issue #433 · data-apis/array-api