Closed
Description
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)
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
jakirkham commentedon May 16, 2022
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 commentedon May 17, 2022
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 commentedon May 17, 2022
Here's the results of an integer and floating point type from NumPy (line 1 was the
import
):Nearly all of the information is shared other than
resolution
. In factresolution
could even be specified for integers for simplicity (as it would just be1
).Anyways it's unclear why having one function would be challenging. Though please feel free to clarify
honno commentedon May 17, 2022
Ah
resolution=1
seems like a clean solution, although with the spec it's calledeps
(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 bothnp.finfo()
andxp.finfo()
share—is there a nice solution forsmallest_normal
here?leofang commentedon May 17, 2022
It's confusing, John, they have quite different attributes:
https://data-apis.org/array-api/latest/API_specification/generated/signatures.data_type_functions.iinfo.html
https://data-apis.org/array-api/latest/API_specification/generated/signatures.data_type_functions.finfo.html
jakirkham commentedon May 17, 2022
smallest_normal
could also be1
for integersWe could also make these things
None
if we prefer thatjakirkham commentedon May 17, 2022
Leo, those show the same attributes as the example above. All they add is
bits
(which they both have) andsmallest_normal
(which we are now discussing).leofang commentedon May 18, 2022
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:
eps
andresolution
have different meanings in NumPy.kgryte commentedon Jun 2, 2022
Not clear to me what info would belong on
cinfo
. For example, what shouldeps
be for complex numbers? What wouldmin
andmax
be given that complex numbers don't have a natural ordering? Same forsmallest_normal
?leofang commentedon Jun 6, 2022
I'd keep at least
bits
andeps
forcinfo
, but definitely excludemin
andmax
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 commentedon Jun 23, 2022
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
andcomponent_smallest_normal
.Both of those options do feel weird, but having an array library tell you the bounds can be pretty useful.
kgryte commentedon Jun 23, 2022
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 acinfo
object first, hence opening an issue on NumPy proposing the addition.cinfo()
for inspecting complex dtypes OR formalise/document complex dtype behaviour infinfo()
numpy/numpy#2226010 remaining items