8000 ENH: `cinfo()` for inspecting complex dtypes OR formalise/document complex dtype behaviour in `finfo()` · Issue #22260 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

ENH: cinfo() for inspecting complex dtypes OR formalise/document complex dtype behaviour in finfo() #22260

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
honno opened this issue Sep 14, 2022 · 3 comments
Closed

ENH: cinfo() for inspecting complex dtypes OR formalise/document complex dtype behaviour in finfo() #22260

honno opened this issue Sep 14, 2022 · 3 comments

Comments

@honno
Copy link
Contributor
honno commented Sep 14, 2022 •
edited
Loading

Proposed new feature or change:

Currently we can use finfo() to get useful information for a single component (i.e. real or imag).

>>> 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)

A downside is this feels a bit too implicit, but maybe more importantly is that this isn't documented behaviour (see finfo docs).

For ints we have iinfo() and floats we have finfo(), so how about a cinfo() for complex dtypes? There's an issue for the Array API for such a feature, which has some discussion on what the return info object could actually look like data-apis/array-api#433.

I think the biggest question with a "complex info object" is if it were to have separate attributes per real and imaj components, or just attributes which pertain to both. As the components should always work the same, I would prefer attributes that pertain to both... but as it'd look identical to an finfo()-returned object, personally I'd prefer just having document support of complex dtypes in finfo().

In any case, a formal way of finding info about the real/imag components of complex dtypes would be nice. I came across this need recently when experimenting with complex number support for hypothesis.extra.array_api, where we could easily grab useful info for ints and floats but not for complex numbers, resulting in an preliminary step to infer the relevant float representation of the complex components

if dtype == np.complex64:
    info = np.finfo(np.float32)
else:  # dtype == np.complex128
    info = np.finfo(np.float64)

... I mean not the worst thing in the world, but just didn't feel good! 😅
This was referenced Sep 14, 2022
Closed
Merged
@MatteoRaso
Copy link
Contributor

Like @kgryte said in the issue that you linked, it doesn't make sense to have a max, min, or eps for a complex number. Having a max or min for the real and imaginary components wouldn't work either, since the max and min are the same for both components. Changing the docs would probably be better.

@WarrenWeckesser
Copy link
Member

cinfo() does not sound very useful to me. Complex types are a composite type, composed of two instances of a real type. When I try to think of actual use-cases for cinfo(), I end up wanting the information of the underlying real type. So I think the current behavior of finfo() is reasonable, and makes cinfo() unnecessary. Of course, this behavior of finfo() should be documented. The description in the numpy.finfo docstring could be expanded to something like

    Machine limits for floating point types.  For complex types, the limits
    for the underlying real type are returned.

MatteoRaso added a commit to MatteoRaso/numpy that referenced this issue Sep 14, 2022
@MatteoRaso
DOC: Clarified how finfo works with complex numbers (numpy#22260)
e792e6c 
There was some confusion about how finfo works with complex numbers,
leading to an issue being made requesting that numpy either adds a
cinfo function or changes the documentation of finfo. The submitter of
that issue also linked to an issue for a seperate repository, which also
included conversation about the proposed change. (github.com/data-apis/array-api/issues/433)
In both discussions, there was a general concensus that it would be better
to change the documentation to explain how finfo works instead of
creating a cinfo function.

Since this is just a small documentation change, there's no need
to run the normal checks.

[skip ci]
mattip added a commit that referenced this issue Sep 18, 2022
@mattip
Merge pull request #22263 from MatteoRaso/finfo_complex
d6586b9 
DOC: Clarified how finfo works with complex numbers (#22260)
@honno
Copy link
Contributor Author
honno commented Sep 19, 2022

Closing as #22263 (comment) has been merged, which documents complex dtype behaviour in finfo() 🎉

@honno honno closed this as completed Sep 19, 2022
@honno honno mentioned this issue Sep 23, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@WarrenWeckesser @honno @MatteoRaso
0