[Numpy-discussion] Re: ENH: Uniform interface for accessing minimum or maximum value of a dtype

[Lucas Colley]

Or how about `np.dtype_info(dt)`, which could return an object with attributes 
like `min` and `max`. Would that be possible?
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: ENH: Uniform interface for accessing minimum or maximum value of a dtype

[Nathan]

That seems reasonable to me on its face. There are some corner cases to
work out though.

Swayam is tinkering with a quad precision dtype written using rhe new DType
API and just ran into the fact that finfo doesn’t support user dtypes:

https://github.com/numpy/numpy/issues/27231

IMO any new feature along these lines should have some thought in the
design about how to handle user-defined data types.

Another thing to consider is that data types can be non-numeric (things
like categories) or number-like but not really just a number like a
quantity with a physical unit.  That means you should also think about what
to do where fields like min and max don’t make any sense or need to be a
generic python object rather than a numeric type.

I think if someone proposed a NEP that fully worked this out it would be
welcome. My understanding is that the array API consortium prefers to
standardize on APIs that gain tractions in libraries rather than inventing
APIs and telling libraries to adopt them, so I think a NEP is the right
first step, rather than trying to standardize something in the array API.

On Mon, Aug 26, 2024 at 8:06 AM Lucas Colley 
wrote:

> Or how about `np.dtype_info(dt)`, which could return an object with
> attributes like `min` and `max`. Would that be possible?
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: nathan12...@gmail.com
>
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: ENH: Uniform interface for accessing minimum or maximum value of a dtype

[Marten van Kerkwijk]

I think a NEP is a good idea.  It would also seem to make sense to
consider how the dtype itself can hold/calculate this type of
information, since that will be the only way a generic ``info()``
function can get information for a user-defined dtype.  Indeed, taking
that further, might a method or property on the dtype itself be
the cleaner interface?  I.e., one would do ``dtype.info().min`` or
``dtype.info.min``.

-- Marten

Nathan  writes:

> That seems reasonable to me on its face. There are some corner cases to work 
> out though.
>
> Swayam is tinkering with a quad precision dtype written using rhe new DType 
> API and just ran into the
> fact that finfo doesn’t support user dtypes: 
>
> https://github.com/numpy/numpy/issues/27231
>
> IMO any new feature along these lines should have some thought in the design 
> about how to handle
> user-defined data types.
>
> Another thing to consider is that data types can be non-numeric (things like 
> categories) or number-like
> but not really just a number like a quantity with a physical unit.  That 
> means you should also think
> about what to do where fields like min and max don’t make any sense or need 
> to be a generic python
> object rather than a numeric type.
>
> I think if someone proposed a NEP that fully worked this out it would be 
> welcome. My understanding
> is that the array API consortium prefers to standardize on APIs that gain 
> tractions in libraries rather
> than inventing APIs and telling libraries to adopt them, so I think a NEP is 
> the right first step, rather
> than trying to standardize something in the array API.
>
> On Mon, Aug 26, 2024 at 8:06 AM Lucas Colley  wrote:
>
>  Or how about `np.dtype_info(dt)`, which could return an object with 
> attributes like `min` and `max
>  `. Would that be possible?
>  ___
>  NumPy-Discussion mailing list -- numpy-discussion@python.org
>  To unsubscribe send an email to numpy-discussion-le...@python.org
>  https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
>  Member address: nathan12...@gmail.com
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: ENH: Uniform interface for accessing minimum or maximum value of a dtype

[Sebastian Berg]

On Mon, 2024-08-26 at 11:26 -0400, Marten van Kerkwijk wrote:
> I think a NEP is a good idea.  It would also seem to make sense to
> consider how the dtype itself can hold/calculate this type of
> information, since that will be the only way a generic ``info()``
> function can get information for a user-defined dtype.  Indeed,
> taking
> that further, might a method or property on the dtype itself be
> the cleaner interface?  I.e., one would do ``dtype.info().min`` or
> ``dtype.info.min``.
> 

I agree, I think it should be properties/attributes (I don't think it
needs to be a function, it should be cheap?)
Now it might also be that `np.finfo()` could keep working via
`dtype.finfo` or a dunder if we want to hide it.

In general, I would lean towards some form of attributes, even if I am
not sure if they should be `.info`, `.finfo`, or even directly on the
dtype.
(`.info.min` seems tricky, because I am not sure it is clear whether
inf or the minimum finite value is "min".)

A (potentially very short) NEP would probably help to get momentum on
making a decision.  I certainly would like to see this being worked on!

- Sebastian


> -- Marten
> 
> Nathan  writes:
> 
> > That seems reasonable to me on its face. There are some corner
> > cases to work out though.
> > 
> > Swayam is tinkering with a quad precision dtype written using rhe
> > new DType API and just ran into the
> > fact that finfo doesn’t support user dtypes: 
> > 
> > https://github.com/numpy/numpy/issues/27231
> > 
> > IMO any new feature along these lines should have some thought in
> > the design about how to handle
> > user-defined data types.
> > 
> > Another thing to consider is that data types can be non-numeric
> > (things like categories) or number-like
> > but not really just a number like a quantity with a physical unit. 
> > That means you should also think
> > about what to do where fields like min and max don’t make any sense
> > or need to be a generic python
> > object rather than a numeric type.
> > 
> > I think if someone proposed a NEP that fully worked this out it
> > would be welcome. My understanding
> > is that the array API consortium prefers to standardize on APIs
> > that gain tractions in libraries rather
> > than inventing APIs and telling libraries to adopt them, so I think
> > a NEP is the right first step, rather
> > than trying to standardize something in the array API.
> > 
> > On Mon, Aug 26, 2024 at 8:06 AM Lucas Colley <
> > lucas.coll...@gmail.com> wrote:
> > 
> >  Or how about `np.dtype_info(dt)`, which could return an object
> > with attributes like `min` and `max
> >  `. Would that be possible?
> >  ___
> >  NumPy-Discussion mailing list -- numpy-discussion@python.org
> >  To unsubscribe send an email to numpy-discussion-le...@python.org
> >  
> > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> >  Member address: nathan12...@gmail.com
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: sebast...@sipsolutions.net


___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] NumPy 2.0.2 released

[Charles R Harris]

Hi All

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
2.0.2. NumPy 2.0.2 is a maintenance release that fixes bugs and regressions
discovered after the 2.0.1 release. This release supports Python 3.9-3.12.
Wheels can be downloaded from PyPI
; source
archives, release notes, and wheel hashes are available on Github
.


*Contributors*

A total of 13 people contributed to this release.  People with a "+" by
their
names contributed a patch for the first time.

   - Bruno Oliveira +
   - Charles Harris
   - Chris Sidebottom
   - Christian Heimes +
   - Christopher Sidebottom
   - Mateusz Sokół
   - Matti Picus
   - Nathan Goldbaum
   - Pieter Eendebak
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Sebastian Berg
   - Yair Chuchem +


*Pull requests merged*

A total of 19 pull requests were merged for this release.

   - #27000: REL: Prepare for the NumPy 2.0.1 release [wheel build]
   - #27001: MAINT: prepare 2.0.x for further development
   - #27021: BUG: cfuncs.py: fix crash when sys.stderr is not available
   - #27022: DOC: Fix migration note for ``alltrue`` and ``sometrue``
   - #27061: BUG: use proper input and output descriptor in
   array_assign_subscript...
   - #27073: BUG: Mirror VQSORT_ENABLED logic in Quicksort
   - #27074: BUG: Bump Highway to latest master
   - #27077: BUG: Off by one in memory overlap check
   - #27122: BUG: Use the new ``npyv_loadable_stride_`` functions for ldexp
   and...
   - #27126: BUG: Bump Highway to latest
   - #27128: BUG: add missing error handling in public_dtype_api.c
   - #27129: BUG: fix another cast setup in array_assign_subscript
   - #27130: BUG: Fix building NumPy in FIPS mode
   - #27131: BLD: update vendored Meson for cross-compilation patches
   - #27146: MAINT: Scipy openblas 0.3.27.44.4
   - #27151: BUG: Do not accidentally store dtype metadata in ``np.save``
   - #27195: REV: Revert undef I and document it
   - #27213: BUG: Fix NPY_RAVEL_AXIS on backwards compatible NumPy 2 builds
   - #27279: BUG: Fix array_equal for numeric and non-numeric scalar types


Cheers,

Charles Harris
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: ENH: Uniform interface for accessing minimum or maximum value of a dtype

[Warren Weckesser]

On Mon, Aug 26, 2024 at 5:42 PM Sebastian Berg
 wrote:
>
> On Mon, 2024-08-26 at 11:26 -0400, Marten van Kerkwijk wrote:
> > I think a NEP is a good idea.  It would also seem to make sense to
> > consider how the dtype itself can hold/calculate this type of
> > information, since that will be the only way a generic ``info()``
> > function can get information for a user-defined dtype.  Indeed,
> > taking
> > that further, might a method or property on the dtype itself be
> > the cleaner interface?  I.e., one would do ``dtype.info().min`` or
> > ``dtype.info.min``.
> >
>
> I agree, I think it should be properties/attributes (I don't think it
> needs to be a function, it should be cheap?)
> Now it might also be that `np.finfo()` could keep working via
> `dtype.finfo` or a dunder if we want to hide it.
>
> In general, I would lean towards some form of attributes, even if I am
> not sure if they should be `.info`, `.finfo`, or even directly on the
> dtype.
> (`.info.min` seems tricky, because I am not sure it is clear whether
> inf or the minimum finite value is "min".)
>
> A (potentially very short) NEP would probably help to get momentum on
> making a decision.  I certainly would like to see this being worked on!
>
> - Sebastian
>

A namespace attached to the dtype to hold useful constants seems like
a good approach.

This could also be used to hold type-dependent constants such as `pi`,
`e`, etc. for the real floating point types.  Over in
https://github.com/numpy/numpy/issues/9698, I suggested the name
`constants` 
(https://github.com/numpy/numpy/issues/9698#issuecomment-2186653455).
This would also be available for user-defined dtypes, where types such
as  `quaddtype`
(https://github.com/numpy/numpy-user-dtypes/tree/main/quaddtype) ,
`mpfdtype` (https://github.com/numpy/numpy-user-dtypes/tree/main/mpfdtype),
and `logfloat32` (https://github.com/WarrenWeckesser/numtypes) would
make available their own representations of `pi`, `e`, etc.

There will be some work required to define the semantics of the
existing attributes.  Not all attributes can be required for all data
types.  For example, a few considerations off the top of my head:

* The `min` and `max` values for `datetime64` andf `timedelta64` would
have values that depend on the time unit.
* Floating point types that are not IEEE 754 such as IBM double-double
wouldn't necessarily have all the attributes IEEE 754 float types
have.
* The StringDType has a well-defined `min` (the empty string), but not a `max`.

Warren


> > -- Marten
> >
> > Nathan  writes:
> >
> > > That seems reasonable to me on its face. There are some corner
> > > cases to work out though.
> > >
> > > Swayam is tinkering with a quad precision dtype written using rhe
> > > new DType API and just ran into the
> > > fact that finfo doesn’t support user dtypes:
> > >
> > > https://github.com/numpy/numpy/issues/27231
> > >
> > > IMO any new feature along these lines should have some thought in
> > > the design about how to handle
> > > user-defined data types.
> > >
> > > Another thing to consider is that data types can be non-numeric
> > > (things like categories) or number-like
> > > but not really just a number like a quantity with a physical unit.
> > > That means you should also think
> > > about what to do where fields like min and max don’t make any sense
> > > or need to be a generic python
> > > object rather than a numeric type.
> > >
> > > I think if someone proposed a NEP that fully worked this out it
> > > would be welcome. My understanding
> > > is that the array API consortium prefers to standardize on APIs
> > > that gain tractions in libraries rather
> > > than inventing APIs and telling libraries to adopt them, so I think
> > > a NEP is the right first step, rather
> > > than trying to standardize something in the array API.
> > >
> > > On Mon, Aug 26, 2024 at 8:06 AM Lucas Colley <
> > > lucas.coll...@gmail.com> wrote:
> > >
> > >  Or how about `np.dtype_info(dt)`, which could return an object
> > > with attributes like `min` and `max
> > >  `. Would that be possible?
> > >  ___
> > >  NumPy-Discussion mailing list -- numpy-discussion@python.org
> > >  To unsubscribe send an email to numpy-discussion-le...@python.org
> > >
> > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > >  Member address: nathan12...@gmail.com
> > ___
> > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > To unsubscribe send an email to numpy-discussion-le...@python.org
> > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > Member address: sebast...@sipsolutions.net
>
>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: warren.weckes...@gm