[Numpy-discussion] Which generation of s390x CPU and how to change it?
Hello, As a maintainer of Python packages for openSUSE/SUSE, I would like to ask for help with our bug https://bugzilla.suse.com/1221902. It seems to us that the latest version of NumPy suddenly requires z15 CPU generation, although it used to be OK with z13+ before, and unfortunately that is the level of the CPU support we standardize in openSUSE. Is it true? If so, when this change happened and why? How could we push numpy to work with older processors? Is there anything more to do than just switch of particular features in `--cpu-dispatch`? Thank you for any reply, Matěj Cepl -- http://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 I was quite depressed two weeks ago when I spent an afternoon at Brentano's Bookshop in New York and was looking at the kind of books most people read. Once you see that you lose all hope. -- Friedrich August von Hayek E09FEF25D96484AC.asc Description: application/pgp-keys signature.asc Description: PGP signature ___ 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: Automatic Clipping of array to upper / lower bounds of dtype
Many thanks! Just one more inquiry along those lines, if I may. The code asserts that clip should outpace np.maximum(mp.minumum(arr, max), min). Despite this: *time a = np.arange(100)it.clip(4, 20)# 8.48 µs %timeit np.maximum(np.minimum(a, 20), 4)2.09 nanoseconds Will this be the norm? ___ 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: Automatic Clipping of array to upper / lower bounds of dtype
On Mon, 2024-03-25 at 13:49 +, percynichols...@gmail.com wrote: > Many thanks! > > Just one more inquiry along those lines, if I may. The code asserts > that clip should outpace np.maximum(mp.minumum(arr, max), min). > Despite this: > *time a = np.arange(100)it.clip(4, 20) # 8.48 µs > %timeit np.maximum(np.minimum(a, 20), 4) 2.09 nanoseconds > Will this be the norm? There some slow paths necessary due to NaN handling and a deprecation in `np.clip`. You should try with an up to date NumPy version. That was a known issue, but not much to do about it. You shouldn't really see much of a difference on up to date NumPy versions. - 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: 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] Re: Which generation of s390x CPU and how to change it?
On Mon, Mar 25, 2024 at 2:24 PM Matěj Cepl wrote: > Hello, > > As a maintainer of Python packages for openSUSE/SUSE, > I would like to ask for help with our bug > https://bugzilla.suse.com/1221902. It seems to us that the latest > version of NumPy suddenly requires z15 CPU generation, although > it used to be OK with z13+ before, and unfortunately that is the > level of the CPU support we standardize in openSUSE. > > Is it true? If so, when this change happened and why? How > could we push numpy to work with older processors? I think that is true. https://numpy.org/neps/nep-0054-simd-cpp-highway.html#supported-features-targets mentions support for Z14/Z15, and https://github.com/numpy/numpy/pull/25563#issuecomment-1889798367 touches on Z14 support having an issue. So I think Z14 is the minimum. > Is there anything more to do than just switch of particular features in > `--cpu-dispatch`? > I suspect not, assuming that that works. If Z13 support is an important use case where the performance difference matters a lot, maybe you can bring up getting partial or even full support back in NumPy. Most NumPy maintainers won't know much/anything about s390x though, so that may require contributions and be nontrivial. Another, more feasible option would be to auto-disable the SIMD features, emit a warning, and then continue rather than fail the NumPy build on Z13 by default. Cheers, Ralf > > Thank you for any reply, > > Matěj Cepl > > -- > http://matej.ceplovi.cz/blog/, @mcepl@floss.social > GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 > > I was quite depressed two weeks ago when I spent an afternoon at > Brentano's Bookshop in New York and was looking at the kind of > books most people read. Once you see that you lose all hope. > -- Friedrich August von Hayek > > ___ > 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: ralf.gomm...@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] Polyfit error in displacement
Hello in a vb program they use 3rd degree approx and get this value including displacement:(SC) [image: image.png] Ii think that i'm doing the same with numpy but I get different value does anyone can help me please radious = [1821, 1284, 957, 603,450, 245] y = [6722, 6940, 7227, 7864,8472, 10458] p = np.polyfit(radious, y, 3,) t = np.polyval(p, radious) [ 6703.33694696 7061.23784145 7051.49974149 7838.84623289 8654.47847319 10373.60076402] You can see polyval is difference from the sc. of the table Any help is really appreciated ___ 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: Polyfit error in displacement
Hello Luca, I am a bit confused by the output of VB script. Equation is: y = f(x), where x is in the order of 0-2K y is in the order of 5-10K The output of fitted polynomial is in y-space, thus I would expect fitted values to be similar to those of Y. Now, sc values are very small and alternating sign. I would suspect that vb script is doing something else than 3-rd degree polynomial fitting. I would suggest producing scatter plots with fitted lines so you can inspect situation visually. This is all I can say without inspecting VB code. Correct me, if I am missing something obvious - this does happen. Regards, dgpb > On 25 Mar 2024, at 18:04, Luca Bertolotti wrote: > > Hello > in a vb program they use 3rd degree approx and get this value including > displacement:(SC) > > > Ii think that i'm doing the same with numpy but I get different value does > anyone can help me please > > radious = [1821, 1284, 957, 603,450, 245] > y = [6722, 6940, 7227, 7864,8472, 10458] > p = np.polyfit(radious, y, 3,) > t = np.polyval(p, radious) > [ 6703.33694696 7061.23784145 7051.49974149 7838.84623289 > 8654.47847319 10373.60076402] > You can see polyval is difference from the sc. of the table > Any help is really appreciated > > ___ > 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: dom.grigo...@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: Polyfit error in displacement
On Mon, Mar 25, 2024 at 11:28 AM Luca Bertolotti < luca72.bertolo...@gmail.com> wrote: > Hello > in a vb program they use 3rd degree approx and get this value including > displacement:(SC) > [image: image.png] > > Ii think that i'm doing the same with numpy but I get different value does > anyone can help me please > > radious = [1821, 1284, 957, 603,450, 245] > y = [6722, 6940, 7227, 7864,8472, 10458] > p = np.polyfit(radious, y, 3,) > t = np.polyval(p, radious) > [ 6703.33694696 7061.23784145 7051.49974149 7838.84623289 > 8654.47847319 10373.60076402] > You can see polyval is difference from the sc. of the table > Any help is really appreciated > What is sc? Chuck ___ 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: Polyfit error in displacement
On Mon, 25 Mar 2024 at 20:09, Charles R Harris
wrote:
>
>
> On Mon, Mar 25, 2024 at 11:28 AM Luca Bertolotti <
> luca72.bertolo...@gmail.com> wrote:
>
>> Hello
>> in a vb program they use 3rd degree approx and get this value including
>> displacement:(SC)
>> [image: image.png]
>>
>> Ii think that i'm doing the same with numpy but I get different value
>> does anyone can help me please
>>
>> radious = [1821, 1284, 957, 603,450, 245]
>> y = [6722, 6940, 7227, 7864,8472, 10458]
>> p = np.polyfit(radious, y, 3,)
>> t = np.polyval(p, radious)
>> [ 6703.33694696 7061.23784145 7051.49974149 7838.84623289
>> 8654.47847319 10373.60076402]
>> You can see polyval is difference from the sc. of the table
>> Any help is really appreciated
>>
>
> What is sc?
>
At the beginning I thought it was the difference between the fitted y and
the measured y, but of course that is not the case.
For what is worth, doing it in Excel using LINEST:
*=LINEST(A2:A7, B2:B7^{1,2,3})*
And then back-calculating the results of the fit I get this for the
"fitted" y:
6703.34, 7061.24, 7051.50, 7838.85, 8654.48, 10373.60
Which are indeed the same numbers obtained by numpy polyfit. Also get the
same if you use the automatic line fitting in an Excel graph.
Not that I trust Excel with anything, it was just for fun.
Not entirely clear what the OP is doing with VB, but either we are missing
a crucial piece of information or the VB code is incorrect.
Andrea.
___
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 2.0.x has been branched.
On Sat, 9 Mar 2024 at 10:16, Ralf Gommers wrote: > > On Sat, Mar 9, 2024 at 2:03 AM Oscar Benjamin > wrote: >> >> On Sat, 9 Mar 2024 at 00:44, Charles R Harris >> wrote: >> > >> > About a month from now. >> >> What will happen about a month from now? It might seem obvious to you >> but I can interpret this in different ways. >> >> To be clear numpy 2.0 is expected to be released in full to the public >> in about one month's time from today? > > Let me give the optimistic and pessimistic timelines. Optimistic: > > - 2.0.0b1 later today > - 2.0.0rc1 (ABI stable) in 7-10 days > - 2.0.0 final release in 1 month > > Pessimistic: > > - 2.0.0b1 within a few days > - 2.0.0rc1 (ABI stable) in 2 weeks > - 2.0.0rc2 in 4 weeks > - 2.0.0rc3 in 6 weeks > - 2.0.0 final release in 8 weeks Thanks Ralf and Chuck. Sorry, I meant to reply to this earlier but got distracted with other things. We are now 16 days into the future so NumPy 2.0 would be 2 weeks time for the optimistic timescale. I assume that now the beta release is out the intention is no further breaking changes. Then if SymPy master is currently compatible with NumPy 2.0.0b1 a good time for a SymPy release with accumulated fixes is... ASAP! Presumably now that NumPy 2.0 is branched downstream projects should test in CI against the prereleases (pip install --pre numpy) rather than the nightly wheels. (SymPy does not usually test against the nightly wheels. I added that for NumPy 2.0 but maybe we should keep it...) -- Oscar ___ 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 2.0.x has been branched.
On Mon, Mar 25, 2024 at 5:54 PM Oscar Benjamin wrote: > On Sat, 9 Mar 2024 at 10:16, Ralf Gommers wrote: > > > > On Sat, Mar 9, 2024 at 2:03 AM Oscar Benjamin < > oscar.j.benja...@gmail.com> wrote: > >> > >> On Sat, 9 Mar 2024 at 00:44, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> > > >> > About a month from now. > >> > >> What will happen about a month from now? It might seem obvious to you > >> but I can interpret this in different ways. > >> > >> To be clear numpy 2.0 is expected to be released in full to the public > >> in about one month's time from today? > > > > Let me give the optimistic and pessimistic timelines. Optimistic: > > > > - 2.0.0b1 later today > > - 2.0.0rc1 (ABI stable) in 7-10 days > > - 2.0.0 final release in 1 month > > > > Pessimistic: > > > > - 2.0.0b1 within a few days > > - 2.0.0rc1 (ABI stable) in 2 weeks > > - 2.0.0rc2 in 4 weeks > > - 2.0.0rc3 in 6 weeks > > - 2.0.0 final release in 8 weeks > > Thanks Ralf and Chuck. Sorry, I meant to reply to this earlier but got > distracted with other things. > > We are now 16 days into the future so NumPy 2.0 would be 2 weeks time > for the optimistic timescale. > > I assume that now the beta release is out the intention is no further > breaking changes. Then if SymPy master is currently compatible with > NumPy 2.0.0b1 a good time for a SymPy release with accumulated fixes > is... ASAP! > > Presumably now that NumPy 2.0 is branched downstream projects should > test in CI against the prereleases (pip install --pre numpy) rather > than the nightly wheels. (SymPy does not usually test against the > nightly wheels. I added that for NumPy 2.0 but maybe we should keep > it...) > > The rc1 release is now waiting on pybind11, so there is an (uncertain) delay. Chuck ___ 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
