[Numpy-discussion] Re: Endorsing SPECs 1, 6, 7, and 8

[matti picus via NumPy-Discussion]

It seems to me that we should only endorse SPECs that we ourselves
implement, otherwise it is kind of "do as I say, not as I do". For
instance, it would be strange to endorse SPEC0 but stay with NEP 29.
If we are to endorse SPEC0 without changing our version end-of-life
timing, we should at least modify NEP 29 with some commentary about
why we chose not to implementing SPEC0.  If a SPEC is not relevant,
then I don't think the NumPy project (as a project) can have an
opinion on whether it is "good" for other projects. Individual
contributors can of course endorse whatever they want, but as a
project we should only weigh in when it is relevant to our community
experience
Matti

On Mon, Oct 7, 2024 at 1:04 PM Sebastian Berg
 wrote:
>
> Hi all,
>
> TL;DR: NumPy should endorse some or all of the new SPECs if we like
> them.  If you don't or do like them, please discuss, otherwise I
> suspect we will propose and endorsing them soon and do it if a few core
> maintainers agree.
> ...
> Cheers,
>
> Sebastian
___
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: I am getting an error in anaconda jupyter notebook, I am unable to solve. please help me.

[matti picus via NumPy-Discussion]

Your version of pandas is not compatible with your version of numpy.
Try reinstalling both of them.
Matti

On Tue, Oct 1, 2024 at 4:27 PM Usha Gayatri via NumPy-Discussion
 wrote:
>
> This is the error i am getting when trying to execute import numpy as np
> File E:\anaconda3\Lib\site-packages\pandas\_libs\interval.pyx:1, in init 
> pandas._libs.interval()
>
> ValueError: numpy.dtype size changed, may indicate binary incompatibility. 
> Expected 96 from C header, got 88 from PyObject
> ___
> 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: matti.pi...@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: help

[matti picus via NumPy-Discussion]

Maybe python is picking up some other versions of pandas and numpy. What do
you get when you check like this

import numpy
import pandas
print(f”{numpy.__version__=}”)
print(f”{pandas.__version__=}”)

Matti

On Wed, 2 Oct 2024 at 15:13, Usha Gayatri via NumPy-Discussion <
numpy-discussion@python.org> wrote:

> I am working on a Jupyter notebook in Anaconda Navigator. I have done some
> projects in 2021, 2022,2023 and 2024. When I run my old project which was
> created in 2021. it is giving errors.I am just testing import numpy as np
> import pandas as pd
> which is giving an error.
>
> File E:\anaconda3\Lib\site-packages\pandas\_libs\interval.pyx:1, in init 
> pandas._libs.interval()
> ValueError: numpy.dtype size changed, may indicate binary incompatibility. 
> Expected 96 from C header, got 88 from PyObject.
>
>
> I did uninstall numpy, pandas and again installed. even updated anaconda.
>
> Please help me. I am unable to run any program.
>
> Thank you.
>
> Usha
>
> ___
> 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: matti.pi...@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: Fixing definition of reduceat for Numpy 2.0?

[matti picus via NumPy-Discussion]

I am not sure how I feel about this. If I understand correctly, the
issue started as a corner case when the indices were incorrect, and
grew to dealing with initial values, and then added a desire for
piecewise reducat with multiple segements. Is that correct? Could you
give a better summary of the issue the PR is trying to solve? The
examples look magic to me, it took me a long time to understand that
the `[1, 3, 5]` correspond to start indices and `[2, -1, 0]`
correspond to stop indices. Perhaps we should require kwarg use
instead of positional to make the code more readable.
Matti

On Sun, Nov 24, 2024 at 3:13 AM Marten van Kerkwijk
 wrote:
>
> Hi All,
>
> This discussion about updating reduceat went silent, but recently I came
> back to my PR to allow `indices` to be a 2-dimensional array of start
> and stop values (or a tuple of separate start and stop arrays).  I
> thought a bit more about it and think it is the easiest way to extend
> the present definition.  So, I have added some tests and documentation
> and would now like to open it for proper discussion.  See
>
> https://github.com/numpy/numpy/pull/25476
>
> >From the examples there:
> ```
> a = np.arange(12)
> np.add.reduceat(a, ([1, 3, 5], [2, -1, 0]))
> # array([ 1, 52,  0])
> np.minimum.reduceat(a, ([1, 3, 5], [2, -1, 0]), initial=10)
> # array([ 1,  3, 10])
> np.minimum.reduceat(a, ([1, 3, 5], [2, -1, 0]))
> # ValueError: empty slice encountered with reduceat operation for 'minimum', 
> which does not have an identity. Specify 'initial'.
> ```
> Let me know what you all think,
>
> Marten
>
> p.s.  Rereading the thread, I see we discussed initial vs default values
> in some detail. This is interesting, but somewhat orthogonal to the PR,
> since it just copies behaviour already present for reduce.
> ___
> 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: matti.pi...@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: Proposing a flattening functionality for deeply nested lists in NumPy

[matti picus via NumPy-Discussion]

On Tue, 31 Dec 2024 at 06:41, Mark via NumPy-Discussion <
numpy-discussion@python.org> wrote:

> Hello all,
>
>
> Many people have asked how to flatten a nested
>

I think this is out of scope for NumPy. Our bar for adding functionality is
quite high. We are unlikely to consider generic routines that are not
directly connected to NumPy style homogenous ND arrays, and even then will
look first for consensus with the Data Array API standard. In truth, our
direction is to deprecate and remove parts of the library that are not
directly related to the Array API.

Matti

>
___
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] Build wheels for manylinux_2_24 instead of manylinux2014

[Matti Picus via NumPy-Discussion]

We are starting to discuss moving up from manylinux2104_manylinux_2_17 
for the next NumPy release in June 2025. It seems, looking at 
https://github.com/mayeut/pep600_compliance?tab=readme-ov-file#acceptable-distros-to-build-wheels 
, 
that the next step would be manylinux_2_24. Is there a demand to 
continue supporting EOL linux operating systems?


Matti

___
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: Exact representable difference between for two arrays.

[matti picus via NumPy-Discussion]

On Fri, Dec 20, 2024 at 4:48 AM Andrew Nelson via NumPy-Discussion
 wrote:

>
> Or is there a risk that the Python interpreter would prematurely optimize 
> that to give:
>
> ```
> dx = h
> ```
>
>
> --
> _
> Dr. Andrew Nelson


Wow, that would be a pretty serious optimization bug to override Kahan
summation. Are you speaking of some theoretical future version of the
interpreter, or of the current state of things?
Matti
___
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: Exact representable difference between for two arrays.

[matti picus via NumPy-Discussion]

The current CPython 3.13 version only has (as far as I know) two types
of code-rewriting optimizations:
- a rudimentary JIT[1] that replaces byte code with machine code,
without changing semantics
- a specializer[2] that will take things like a + b, and simplify the
byte code if both a and b are known types (int, float, string)

There is no higher-level optimizer to remove operations. Even PyPy is
very careful with rewriting code, and uses code verification to prove
the optimization rules [3].

[1] https://peps.python.org/pep-0744/
[2] https://peps.python.org/pep-0659/
[3] https://pypy.org/posts/2024/07/finding-simple-rewrite-rules-jit-z3.html
which is one of a series of blog posts
___
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: New GitHub issue UI

[Matti Picus via NumPy-Discussion]

On 14/01/2025 19:05, Nathan via NumPy-Discussion wrote:

GitHub now has support for "issue types".



I couldn't figure out how to customize the types, all I see are 'bug', 
'feature', 'task'


Matti

___
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] Fwd: [pypy-dev] Re: Better compatibility of the Python scientific/data stack with fast Python interpreters

[matti picus via NumPy-Discussion]

-- Forwarded message -
From: matti picus 
Date: Fri, May 2, 2025 at 11:05 AM
Subject: Re: [pypy-dev] Re: [Numpy-discussion] Better compatibility of
the Python scientific/data stack with fast Python interpreters
To: PyPy Developer Mailing List , Ralf Gommers
, hpy-dev 


On Wed, Apr 30, 2025 at 3:30 PM Michał Górny  wrote:
>
> Hello,
>
> I'd like to just add a few data points from my Gentoo experience.
> ...
> I'm sorry but I don't understand what you're referring to.  Sure, PyPy
> is not moving fast, but it definitely isn't dead.  Sure, it sucks that
> we're still stuck in Python 3.11 era, but that doesn't make PyPy EOL.
>
>
> --
> Best regards,
> Michał Górny
>

It does not appear there will be a PyPy 3.12. When NumPy drops support
for Python3.11 (Jan 2026), future versions based on the CPython C-API
will defacto no longer be relevant for PyPy3.11.  However, if HPy
succeeds, there is a chance that a NumPy "universal" HPy wheel will
still work on PyPy 3.11, as the API will be abstracted away from a
direct connection with the CPython C-API. This is one of the
attractions of HPy, that puts it in a different category than Cython
or nanobind: universal HPy binaries can run on any python interpreter
or version that supports the abstracted API.

With the current level of active contributions to PyPy, I am not
convinced we can help making HPy a reality, even though it is a very
well thought out solution to once and for all detaching third party
libraries from a tight integration with the CPython C-API. I agree HPy
would be advantageous to both the CPython core team and package
maintainers. The yearly churn of packages needing to update for new
CPython C-API would be localized in the HPy layer for the new CPython
(similar to Cython, nanobind, and PyO3), and the CPython maintainers
would be free to change more aspects of the CPython internals that
unintentionally impact the external C-API (which differentiates HPy
from Cython, nanobind, and PyO3). But not all good ideas get to win
out and become the popular, goto solution. PyPy itself is an example
that, unfortunately.
Matti
___
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: Beginners

[matti picus via NumPy-Discussion]

On Tue, Mar 11, 2025 at 8:00 PM Monkeysigh via NumPy-Discussion
 wrote:
>
> Do you know if beginners are invited to attend?

If you mean the community/triage/documentation/optimization team
meetings: they are all open for anyone to drop in. Of course the
meetings have their own cadence and subjects to discuss.
Matti
___
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: Bumping CPU baseline to x86-64-v2

[matti picus via NumPy-Discussion]

On Sun, May 18, 2025 at 10:39 AM Jerome Kieffer 
wrote:
>
> Hi,
>
> First I would like to highlight that "X86_V2" is very specific to the
> implementation in numpy, basically this implies the support of all 128
> bits SIMD extensions, i.e. SSE1,2,3&4, but does apparenty not requires
> any 256bit SIMD (AVX).
>
> Ralph, the stats you are using are made on end-user hardware which gets
> replaced much faster than servers, while numpy is very likely to be
> used on elder hardware, especially for CI where elder hardware still ok
> and often recycled. For example, we are still renting severs which is
> X86_V2 but not X86_V3 for  performing the CI/CD of our projects.
>
> Cheers,
>
> Jerome
>

> --
> Jérôme Kieffer
> ___

Interesting. Could you give some more information that might convince NumPy
to continue supporting these old machines? Renting implies you do not own
them and are paying for the service. Are the energy/speed tradeoffs worth
continuing with them, rather than asking the hosting service for a more
modern machine? Do they use Numpy2.x in the CI/CD pipeline?
Matti
___
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: we have a NumPy PyPI organization now

[matti picus via NumPy-Discussion]

On Mon, Jun 16, 2025 at 4:24 PM Ralf Gommers via NumPy-Discussion
 wrote:
>
> Hi all,
>
> Now that PyPI has organizations and they came out of beta and the application 
> queue cleared, I applied for a NumPy organization and that just came through 
> (https://pypi.org/org/numpy/). We can start moving projects under that now, 
> so it'll look more like https://pypi.org/org/scipy/.

Nice. For instance, it would be nice if scipy-openblas32 and
scipy-openblas64 could become either as scipy org or numpy org
projects.
Matti
___
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: NumPy security roadmap proposal

[matti picus via NumPy-Discussion]

On Fri, Jun 13, 2025 at 9:40 AM Ralf Gommers via NumPy-Discussion
 wrote:
>
> ...
> For 2FA and repository/PyPI access, we'll start making changes soon. Note 
> that GitHub has recently made changes to its 2FA settings that ask for action 
> from many people: on https://github.com/orgs/numpy/people you can see that 
> under "Two-factor authentication" the options increased; there is now a 
> Secure/Insecure distinction instead of only Enabled/Disabled. If you want to 
> move yourself from Insecure to Secure, you have to disable the SMS/mobile 
> recovery option in your personal settings under "Password and 
> authentication". A large majority of the 94 people with permissions are 
> currently marked as Insecure.
>
> Cheers,
> Ralf
>

You may need member acess to see the "Two-factor authentication"
dropdown selector, but in any case it seems disabling the SMS/mobile
recovery option is now recommended practice. Be sure to download and
keep your recovery codes safe, as that will now be the only accepted
mode to regain access if you loose your 2fa access (i.e. loose or
change your phone number).
___
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