[Numpy-discussion] Re: ndarray typing advise

[Vincent Schut]

Sorry to bump my own issue, but I wonder if just no-one knows, or if it 
has been overlooked, or maybe I did not explain my questions right? 
Should I rather ask this on SO? Or should I just be more patient...?


Thanks!
Vincent.

On 1/13/22 11:43, Vincent Schut wrote:

Hi,

I'm having a hard(ish) time adding the right type annotations to some 
numpy-using code. I hope someone more knowledgeable can give me some 
advise.


Specifically, the following questions pop up:

- How do I correctly type a ndarray as being an array of float64, such 
that mypy can infer that when I index this array, the result is 
actually a float (currently I consistently get "Any" after indexing)?


- How can I get compatibility between np.floating and builtin.float? 
Currently, some numpy functions are typed to return np.floating[Any] 
(e.g. np.linalg.norm). When I feed this result into something that is 
supposed to receive a builtin.float, mypy complains. Is an explicit 
cast(float, ) the prefered way to gain 
compatibility here?


versions:
numpy: 1.22.0
python: 3.8.10 (unfortunately we're limited to this version)
mypy: 0.931

Thanks!
Vincent.


--



Vincent Schut

Remote Sensing Software Engineer

+31 302272679 ~ Maliebaan 22 | 3581CP | Utrecht | Netherlands

Linkedin ~ 
satelligence.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: ndarray typing advise

[bas van beek]

Hi Vincent,

To answer your two questions:

  *   The problem with indexing is that whether you got a scalar or an array 
thereof is dependent on the dimensionality of the array. While shape-typing is 
something that's being worked on (see PEP 646), we're not quite there yet and 
for the mean time we're stuck with returning Any​.
  *   What is the "best" solution here is honestly a bit of an open question. 
With the exception of np.str_​ and np.bytes_​ none of numpy's scalar-types 
inherit from their stdlib counterpart (float64​ and complex128​ do inherit 
during runtime, but this is unfortunately not possible to express in the 
annotations as they're not typed as proper (complex​)floating​ subclasses). A 
while ago there was some discussion about adding them as baseclasses while 
static type checking (numpy/numpy#17105), but the responses back then were 
lukewarm. This might be worthwhile to revisit at some point in the future 
though, be it either in the stub-files proper or via a mypy plugin.
  *   What doesn't help here either is that the duck-typing of (numerical) 
scalar types is currently in a poor state. This would alleviate some/all of the 
headache here, but the numbers-based ABCs are downright useless for static 
typing in their current state.

  *

Regards,
Bas van Beek

From: Vincent Schut 
Sent: 18 January 2022 12:39
To: numpy-discussion@python.org 
Subject: [Numpy-discussion] Re: ndarray typing advise

Sorry to bump my own issue, but I wonder if just no-one knows, or if it has 
been overlooked, or maybe I did not explain my questions right? Should I rather 
ask this on SO? Or should I just be more patient...?

Thanks!
Vincent.

On 1/13/22 11:43, Vincent Schut wrote:
Hi,

I'm having a hard(ish) time adding the right type annotations to some 
numpy-using code. I hope someone more knowledgeable can give me some advise.

Specifically, the following questions pop up:

- How do I correctly type a ndarray as being an array of float64, such that 
mypy can infer that when I index this array, the result is actually a float 
(currently I consistently get "Any" after indexing)?

- How can I get compatibility between np.floating and builtin.float? Currently, 
some numpy functions are typed to return np.floating[Any] (e.g. 
np.linalg.norm). When I feed this result into something that is supposed to 
receive a builtin.float, mypy complains. Is an explicit cast(float, ) the prefered way to gain compatibility here?

versions:
numpy: 1.22.0
python: 3.8.10 (unfortunately we're limited to this version)
mypy: 0.931

Thanks!
Vincent.

--


[https://lh6.googleusercontent.com/t1GD8ftw5REdi0_kM1UjrXeX-Y-jF5xKxDqUGLsLKzftVahqw_CWQhqciHkLLYkldd9pcYmNd-pmzNnY1fc93vYpJ0Q0P-O1VC51jsTJUy-yhjF4ioK2hGq156_JYVROec9im6tW]

Vincent Schut

Remote Sensing Software Engineer

[https://lh5.googleusercontent.com/H6PdQi9jrkkJRWy7wGQ92waInTqhh3atodO0R0CNgKm2YooJBK2vOEU2M7t5HB5FMJyOUhyFxsTqtEnqLi3zXnRbPNJEvoEyr9RyBFKKHUjT8py8Pu92ga3Urmp_zARoHqtNFY6K]

+31 302272679 ~ Maliebaan 22 | 3581CP | Utrecht | Netherlands

Linkedin ~ 
satelligence.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] advice for using datetime64 in C binding

[Benoit Gschwind]

Hello,

I using the following code:

if (PyArray_TYPE(arr1) == NPY_DATETIME) {
// Ensure datetime64[ms]
auto tmp = 
reinterpret_cast(PyObject_CallMethod(reinterpret_cast(arr1),
 "astype", "(s)", "datetime64[ms]"));
std::swap(arr1, tmp);
Py_XDECREF(tmp);
// Ensure integer
tmp = 
reinterpret_cast(PyObject_CallMethod(reinterpret_cast(arr1),
 "astype", "(s)", "i8"));
std::swap(arr1, tmp);
Py_XDECREF(tmp);
tmp = reinterpret_cast(PyArray_FromArray(arr1, 
PyArray_DescrFromType(NPY_INT64), NPY_ARRAY_IN_ARRAY));
std::swap(arr1, tmp);
Py_XDECREF(tmp);
}

First, if something is wrong with my code let me known. Then I wonder
if I can have a safe shortcut to avoid converting datetime64 to i8. I
guess the internal data of datetime64[ms] is i8 thus copying and
casting the array may be avoided.

Thanks by advance
Best regards.


___
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: ndarray typing advise

[Ricky Teachey]

Related: can someone point to a somewhat definitive help article on the
current state of typing for ndarrays? I am interested in this too.

Of late my experience has been trying to straddle the web and scientific
computing worlds (I have been writing a scientific/engineering based web
app), and while typing is incredibly useful for the web (fastapi and
pydantic, I LOVE YOU), it has been an endless source of frustration in
scientific computing. It would be great to be pointed to something current
that will help gain a thorough understanding of what we can do with typing
in numpy these days.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler


On Tue, Jan 18, 2022 at 7:26 AM bas van beek 
wrote:

> Hi Vincent,
>
> To answer your two questions:
>
>- The problem with indexing is that whether you got a scalar or an
>array thereof is dependent on the dimensionality of the array. While
>shape-typing is something that's being worked on (see PEP 646), we're not
>quite there yet and for the mean time we're stuck with returning Any​.
>- What is the "best" solution here is honestly a bit of an open
>question. With the exception of np.str_​ and np.bytes_​ none of
>numpy's scalar-types inherit from their stdlib counterpart (float64​
>and complex128​ do inherit during runtime, but this is unfortunately
>not possible to express in the annotations as they're not typed as proper (
>complex​)floating​ subclasses). A while ago there was some discussion
>about adding them as baseclasses while static type checking
>(numpy/numpy#17105), but the responses back then were lukewarm. This might
>be worthwhile to revisit at some point in the future though, be it either
>in the stub-files proper or via a mypy plugin.
>- What doesn't help here either is that the duck-typing of (numerical)
>scalar types is currently in a poor state. This would alleviate some/all of
>the headache here, but the numbers-based ABCs are downright useless for
>static typing in their current state.
>
>
>-
>
> Regards,
> Bas van Beek
> --
> *From:* Vincent Schut 
> *Sent:* 18 January 2022 12:39
> *To:* numpy-discussion@python.org 
> *Subject:* [Numpy-discussion] Re: ndarray typing advise
>
> Sorry to bump my own issue, but I wonder if just no-one knows, or if it
> has been overlooked, or maybe I did not explain my questions right? Should
> I rather ask this on SO? Or should I just be more patient...?
>
> Thanks!
> Vincent.
>
> On 1/13/22 11:43, Vincent Schut wrote:
>
> Hi,
>
> I'm having a hard(ish) time adding the right type annotations to some
> numpy-using code. I hope someone more knowledgeable can give me some
> advise.
>
> Specifically, the following questions pop up:
>
> - How do I correctly type a ndarray as being an array of float64, such
> that mypy can infer that when I index this array, the result is actually a
> float (currently I consistently get "Any" after indexing)?
>
> - How can I get compatibility between np.floating and builtin.float?
> Currently, some numpy functions are typed to return np.floating[Any] (e.g.
> np.linalg.norm). When I feed this result into something that is supposed to
> receive a builtin.float, mypy complains. Is an explicit cast(float,  np.floating[Any] thing>) the prefered way to gain compatibility here?
>
> versions:
> numpy: 1.22.0
> python: 3.8.10 (unfortunately we're limited to this version)
> mypy: 0.931
>
> Thanks!
> Vincent.
>
>
> --
>
> Vincent Schut
>
> Remote Sensing Software Engineer
>
> +31 302272679 ~ Maliebaan 22 | 3581CP | Utrecht | Netherlands
> Linkedin  ~
> satelligence.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: ri...@teachey.org
>
___
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 1.22.1 failed with "RuntimeError: Setuptools version is '60.5.0', version < '60.0.0' is required."

[s . srigowthami]

Hi,

We are using Openstack zuul ( Openstack CI ) to deploy devstack on IBM PPC64el 
hardware

In 
https://review.opendev.org/c/openstack/requirements/+/824810/2/upper-constraints.txt#124
 commit
the numpy package version is updated from 1.22.0 to 1.22.1

When the version 1.22.0 of numpy was used setuptools-60.5.0 has successfully 
deployed.

where as with the latest numpy 1.22.1 the setuptools package installation is 
failing with the below runtime error.

Error:
2022-01-18 12:17:18.663446 | devstack-focal-newcloud | Collecting numpy
2022-01-18 12:17:18.763054 | devstack-focal-newcloud |   Downloading 
numpy-1.22.1.zip (11.4 MB)
2022-01-18 12:17:24.048280 | devstack-focal-newcloud |   Installing build 
dependencies: started
2022-01-18 12:17:32.883181 | devstack-focal-newcloud |   Installing build 
dependencies: finished with status 'done'
2022-01-18 12:17:32.890122 | devstack-focal-newcloud |   Getting requirements 
to build wheel: started
2022-01-18 12:17:33.282029 | devstack-focal-newcloud |   Getting requirements 
to build wheel: finished with status 'error'
2022-01-18 12:17:33.282475 | devstack-focal-newcloud |   ERROR: Command errored 
out with exit status 1:
2022-01-18 12:17:33.282499 | devstack-focal-newcloud |command: 
/usr/bin/python3.8 
/usr/local/lib/python3.8/dist-packages/pip/_vendor/pep517/in_process/_in_process.py
 get_requires_for_build_wheel /tmp/tmpkr3xl1i_
2022-01-18 12:17:33.282529 | devstack-focal-newcloud |cwd: 
/tmp/pip-install-c1eqnkjm/numpy_7e0d04ecfb1b47af806fb5707c655744
...
2022-01-18 12:17:33.283155 | devstack-focal-newcloud |   RuntimeError: 
Setuptools version is '60.5.0', version < '60.0.0' is required. See 
pyproject.toml
...

2022-01-18 12:17:49.575387 | devstack-focal-newcloud |
2022-01-18 12:17:49.575401 | devstack-focal-newcloud | The conflict is caused 
by:
2022-01-18 12:17:49.575422 | devstack-focal-newcloud | websockify 0.10.0 
depends on numpy
2022-01-18 12:17:49.575450 | devstack-focal-newcloud | The user requested 
(constraint) numpy===1.22.1

numpy: 1.22.1
ubuntu: Focal
python : 3.8

Could someone help me with a way forward.

Thanks
Gowthami
___
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] Benefits Of Candle Boxes Wholesale

[makitech07]

Packaging is an important part of the marketing mix for candles. It is the 
first opportunity to make an impression on the consumer and can be used to 
create a sense of excitement and anticipation. Candle boxes wholesale also help 
protect the candle from damage and make it easier to store and transport.

Why Are Candle Boxes Wholesale Important?

Candles Are Fragile: 

One of the main reasons candle packaging is important is that candles are 
fragile. They can easily get damaged if not packaged properly. This can lead to 
a loss in sales for businesses as consumers will not purchase them in their 
original condition. In addition, it can also damage the reputation of a 
business as customers will think that the products are not being handled with 
care.

Candles Are Expensive: 

Another reason why candle packaging is important is that candles are expensive. 
They are not something that people buy every day. This means that consumers 
will have high expectations of your product. If they are not packaged properly, 
most people will complain and even file a lawsuit against the store or supplier 
if the candles arrive damaged.

Different Types Of Candle Boxes:

Various candle boxes are available in the market, such as gift candle boxes, 
paperboard candle boxes, clear acrylic cases (candle container), PVC candle 
bags, etc.

Gift Candle Boxes: 

Gift candle boxes are also known as gift packaging boxes used for packing not 
only candles but also other items like wall clocks and vases. Many more with 
different shapes and sizes. You can choose this gift packaging box according to 
your desired size and shape. Quality-wise these gift candle boxes are made with 
very fine quality material. That's why these boxes are available at different 
prices.

Paperboard Candle Box: 

These candle boxes are best for personal usage, this paperboard candle box will 
give you an additional feature to your product, and it is easy to carry these 
boxes due to their structure. Moreover, this box is lightly weighted too.

Clear Acrylic Case (Candle Container): 

This type of candle packaging allows customers to see the actual product inside 
to grasp what they will be purchasing immediately. It also comes with a silver 
or gold base to put the candles.

Pvc Candle Bag: 

Some people prefer having soft candle bags that look more beautiful than other 
boxes. PVC candle bags comes with a transparent front, and you can see the 
product without removing it from the bag.
So, these are some of the things you need to keep in mind when looking for a 
supplier of candle packaging. We hope this article was helpful. For more 
helpful tips on candle packaging, you can read more articles at Candle Package 
Design.

Custom Candle Boxes Increase Brand Awareness: 

Promotion is not an easy task, and it requires a lot of hard work and effort. 
But what if we could make things easier by using multiple marketing methods for 
our brands? This is where branding comes into play.
Branding means creating a unique identity for your company or business which 
customers can remember and associate with that particular company. There are 
many ways to do that, such as catchy logos, corporate identities, etc.
Another way of branding is through attractive candle packaging boxes that 
accompany each product when someone buys them. Like a brand logo, a unique 
candle package will help increase awareness about your brand and make customers 
more familiar with it.

Candle Boxes Help In Creating Brand Loyalty: 

When you have successfully created a positive image about your brand in 
people's minds, loyal customers will start coming to you naturally. These are 
the kind of customers who buy from you again and again just because they trust 
your products and services.
You can also build customer loyalty by providing exclusive discounts or offers 
that only preferred customers enjoy. This is yet another effective marketing 
strategy that can help increase sales figures for businesses using attractive 
candle packages for their candles.
So, these were some of how creative candle packaging can create brand awareness 
and increase your sales figures. We hope you found this article useful!

How To Get Candle Boxes Wholesale?

If you're looking to get candle boxes wholesale, there are a few things you 
need to keep in mind.
Firstly, not all suppliers offer the same type of packaging, so it's important 
to do your research and find a supplier who offers high-quality products that 
fit your needs.
Secondly, pricing is also an important factor to consider. It's important to 
find a supplier who offers competitive prices without compromising quality.
Finally, customer service is another important factor to consider. It's 
important to work with a responsive supplier and provide excellent customer 
service. So, these are some of the things you need to keep in mind when looking 
for a supplier of candle packaging.

Get Candle Boxes In Multiple Dimensions:

Candle Packaging is used

[Numpy-discussion] Re: Benefits Of Candle Boxes Wholesale

[Inessa Pawson]

My apologies, the message was approved in error. 

Kind regards,
Inessa
___
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 1.22.1 failed with "RuntimeError: Setuptools version is '60.5.0', version < '60.0.0' is required."

[Ralf Gommers]

On Tue, Jan 18, 2022 at 3:33 PM  wrote:

> Hi,
>
> We are using Openstack zuul ( Openstack CI ) to deploy devstack on IBM
> PPC64el hardware
>
> In
> https://review.opendev.org/c/openstack/requirements/+/824810/2/upper-constraints.txt#124
> commit
> the numpy package version is updated from 1.22.0 to 1.22.1
>
> When the version 1.22.0 of numpy was used setuptools-60.5.0 has
> successfully deployed.
>
> where as with the latest numpy 1.22.1 the setuptools package installation
> is failing with the below runtime error.
>
> Error:
> 2022-01-18 12:17:18.663446 | devstack-focal-newcloud | Collecting numpy
> 2022-01-18 12:17:18.763054 | devstack-focal-newcloud |   Downloading
> numpy-1.22.1.zip (11.4 MB)
> 2022-01-18 12:17:24.048280 | devstack-focal-newcloud |   Installing build
> dependencies: started
> 2022-01-18 12:17:32.883181 | devstack-focal-newcloud |   Installing build
> dependencies: finished with status 'done'
> 2022-01-18 12:17:32.890122 | devstack-focal-newcloud |   Getting
> requirements to build wheel: started
> 2022-01-18 12:17:33.282029 | devstack-focal-newcloud |   Getting
> requirements to build wheel: finished with status 'error'
> 2022-01-18 12:17:33.282475 | devstack-focal-newcloud |   ERROR: Command
> errored out with exit status 1:
> 2022-01-18 12:17:33.282499 | devstack-focal-newcloud |command:
> /usr/bin/python3.8
> /usr/local/lib/python3.8/dist-packages/pip/_vendor/pep517/in_process/_in_process.py
> get_requires_for_build_wheel /tmp/tmpkr3xl1i_
> 2022-01-18 12:17:33.282529 | devstack-focal-newcloud |cwd:
> /tmp/pip-install-c1eqnkjm/numpy_7e0d04ecfb1b47af806fb5707c655744
> ...
> 2022-01-18 12:17:33.283155 | devstack-focal-newcloud |   RuntimeError:
> Setuptools version is '60.5.0', version < '60.0.0' is required. See
> pyproject.toml
> ...
>
> 2022-01-18 12:17:49.575387 | devstack-focal-newcloud |
> 2022-01-18 12:17:49.575401 | devstack-focal-newcloud | The conflict is
> caused by:
> 2022-01-18 12:17:49.575422 | devstack-focal-newcloud | websockify
> 0.10.0 depends on numpy
> 2022-01-18 12:17:49.575450 | devstack-focal-newcloud | The user
> requested (constraint) numpy===1.22.1
>
> numpy: 1.22.1
> ubuntu: Focal
> python : 3.8
>
> Could someone help me with a way forward.
>

Please do what the error message says and use setuptools <60.0 (59.8.0 is
the highest version that works).

If there's a real problem with getting an older version of setuptools
(which seems unlikely, it's pure Python), then you can try removing that
check in numpy and adding SETUPTOOLS_USE_DISTUTILS=stdlib (which is already
default in OpenStack it looks like:
https://opendev.org/openstack/devstack/commit/4b1885bef6766c0bbc20db851b19a83844103c89).
No guarantees that that will work and remain working though, it's untested.

Cheers,
Ralf
___
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: advice for using datetime64 in C binding

[Sebastian Berg]

On Tue, 2022-01-18 at 14:56 +0100, Benoit Gschwind wrote:
> Hello,
> 
> I using the following code:
> 
> if (PyArray_TYPE(arr1) == NPY_DATETIME) {
> // Ensure datetime64[ms]
> auto tmp =
> reinterpret_cast(PyObject_CallMethod(reinterpret_cast
> (arr1), "astype", "(s)", "datetime64[ms]"));
> std::swap(arr1, tmp);
> Py_XDECREF(tmp);
> // Ensure integer
> tmp =
> reinterpret_cast(PyObject_CallMethod(reinterpret_cast
> (arr1), "astype", "(s)", "i8"));
> std::swap(arr1, tmp);
> Py_XDECREF(tmp);
> tmp =
> reinterpret_cast(PyArray_FromArray(arr1,
> PyArray_DescrFromType(NPY_INT64), NPY_ARRAY_IN_ARRAY));
> std::swap(arr1, tmp);
> Py_XDECREF(tmp);
> }
> 
> First, if something is wrong with my code let me known. Then I wonder
> if I can have a safe shortcut to avoid converting datetime64 to i8. I
> guess the internal data of datetime64[ms] is i8 thus copying and
> casting the array may be avoided.

Yes, you can assume datetime64 is stored as an i8 with the unit and
possible byteswapping.  Both of which, your initial cast will ensure.

The internal data is i8, except for the special NaT value.

Code-wise, you can avoid calling `astype`, but if you do (also in
python), I suggest to pass `copy=False`, so that it does not copy if it
clearly is not necessary (I am hoping to improve on the "clearly" here
at some point).

The last call again seems to be a no-op?  Just the last call with the
correct `datetime64[ms]` descriptor could be enough.

Cheers,

Sebastian
 

> 
> Thanks by advance
> Best regards.
> 
> 
> ___
> 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
> 



signature.asc
Description: This is a digitally signed message part
___
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 1.22.1 has been released.

[Peter Cock]

Dear Charles,

Thank you for your work on the numpy releases, including v1.22.1.

I noticed that for Windows Python 3.10, there is only a 64-bit wheel:

numpy-1.22.1-cp310-cp310-win_amd64.whl

That is true both on PyPI and in the list of checksums here:

https://github.com/numpy/numpy/releases/tag/v1.22.1

However, for older versions of Python there are also 32-bit Windows wheels,
e.g.

numpy-1.22.1-cp39-cp39-win32.whl
numpy-1.22.1-cp39-cp39-win_amd64.whl

numpy-1.22.1-cp38-cp38-win32.whl
numpy-1.22.1-cp38-cp38-win_amd64.whl

Is this expected? My interest is in building Windows Wheels for packages
compiling against NumPy.

Thank you,

Peter

On Fri, Jan 14, 2022 at 8:29 PM Charles R Harris 
wrote:

> Hi All,
>
> On behalf of the NumPy team, I'm pleased to announce the release of NumPy
> 1.22.1. NumPy 1.22.1 fixes several bugs discovered after the 1.22.0
> release. Notable fixes are:
>
>- Fix for f2PY docstring problems (SciPy)
>- Fix for reduction type problems (AstroPy)
>- Fixes for various typing bugs.
>
> The Python versions supported in this release are 3.8-3.10.  Wheels can be
> downloaded from PyPI ; source
> archives, release notes, and wheel hashes are available on Github
> . Linux users will
> need pip >= 0.19.3 in order to install the manylinux2014 wheels. A recent
> version of pip is needed to install the universal2 macos wheels.
>
> *Contributors*
>
> A total of 14 people contributed to this release.  People with a "+" by
> their
> names contributed a patch for the first time.
>
>- Arryan Singh
>- Bas van Beek
>- Charles Harris
>- Denis Laxalde
>- Isuru Fernando
>- Kevin Sheppard
>- Matthew Barber
>- Matti Picus
>- Melissa Weber Mendonça
>- Mukulika Pahari
>- Omid Rajaei +
>- Pearu Peterson
>- Ralf Gommers
>- Sebastian Berg
>
>
> *Pull requests merged*
> A total of 20 pull requests were merged for this release.
>
>- #20702: MAINT, DOC: Post 1.22.0 release fixes.
>- #20703: DOC, BUG: Use pngs instead of svgs.
>- #20704: DOC: Fixed the link on user-guide landing page
>- #20714: BUG: Restore vc141 support
>- #20724: BUG: Fix array dimensions solver for multidimensional
>arguments...
>- #20725: TYP: change type annotation for ``__array_namespace__`` to
>ModuleType
>- #20726: TYP, MAINT: Allow ``ndindex`` to accept integer tuples
>- #20757: BUG: Relax dtype identity check in reductions
>- #20763: TYP: Allow time manipulation functions to accept ``date``
>and ``timedelta``...
>- #20768: TYP: Relax the type of ``ndarray.__array_finalize__``
>- #20795: MAINT: Raise RuntimeError if setuptools version is too
>recent.
>- #20796: BUG, DOC: Fixes SciPy docs build warnings
>- #20797: DOC: fix OpenBLAS version in release note
>- #20798: PERF: Optimize array check for bounded 0,1 values
>- #20805: BUG: Fix that reduce-likes honor out always (and live in
>the...
>- #20806: BUG: ``array_api.argsort(descending=True)`` respects
>relative...
>- #20807: BUG: Allow integer inputs for pow-related functions in
>``array_api``
>- #20814: DOC: Refer to NumPy, not pandas, in main page
>- #20815: DOC: Update Copyright to 2022 [License]
>- #20819: BUG: Return correctly shaped inverse indices in array_api
>set...
>
> 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: p.j.a.c...@googlemail.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: advice for using datetime64 in C binding

[Benoit Gschwind]

Hello Sebastian,

Thanks for detail.

The last call has the NPY_ARRAY_C_CONTIGUOUS and NPY_ARRAY_ALIGNED,
thus I guess it can be no-op most of the time but for some unknown case
it's may be safer ?

Best regards

On Tue, 2022-01-18 at 09:22 -0600, Sebastian Berg wrote:
> On Tue, 2022-01-18 at 14:56 +0100, Benoit Gschwind wrote:
> > Hello,
> > 
> > I using the following code:
> > 
> > if (PyArray_TYPE(arr1) == NPY_DATETIME) {
> > // Ensure datetime64[ms]
> > auto tmp =
> > reinterpret_cast(PyObject_CallMethod(reinterpret_ca
> > st
> > (arr1), "astype", "(s)", "datetime64[ms]"));
> > std::swap(arr1, tmp);
> > Py_XDECREF(tmp);
> > // Ensure integer
> > tmp =
> > reinterpret_cast(PyObject_CallMethod(reinterpret_ca
> > st
> > (arr1), "astype", "(s)", "i8"));
> > std::swap(arr1, tmp);
> > Py_XDECREF(tmp);
> > tmp =
> > reinterpret_cast(PyArray_FromArray(arr1,
> > PyArray_DescrFromType(NPY_INT64), NPY_ARRAY_IN_ARRAY));
> > std::swap(arr1, tmp);
> > Py_XDECREF(tmp);
> > }
> > 
> > First, if something is wrong with my code let me known. Then I
> > wonder
> > if I can have a safe shortcut to avoid converting datetime64 to i8.
> > I
> > guess the internal data of datetime64[ms] is i8 thus copying and
> > casting the array may be avoided.
> 
> Yes, you can assume datetime64 is stored as an i8 with the unit and
> possible byteswapping.  Both of which, your initial cast will ensure.
> 
> The internal data is i8, except for the special NaT value.
> 
> Code-wise, you can avoid calling `astype`, but if you do (also in
> python), I suggest to pass `copy=False`, so that it does not copy if
> it
> clearly is not necessary (I am hoping to improve on the "clearly"
> here
> at some point).
> 
> The last call again seems to be a no-op?  Just the last call with the
> correct `datetime64[ms]` descriptor could be enough.
> 
> Cheers,
> 
> Sebastian
>  
> 
> > 
> > Thanks by advance
> > Best regards.
> > 
> > 
> > ___
> > 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: gschw...@gnu-log.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: advice for using datetime64 in C binding

[Sebastian Berg]

On Tue, 2022-01-18 at 18:29 +0100, Benoit Gschwind wrote:
> Hello Sebastian,
> 
> Thanks for detail.
> 
> The last call has the NPY_ARRAY_C_CONTIGUOUS and NPY_ARRAY_ALIGNED,
> thus I guess it can be no-op most of the time but for some unknown
> case
> it's may be safer ?

Ah, yes, you are right, and it should indeed by very quick, anyway.  My
guess is, that you can do _only_ the last call with the appropriate
`datetime64[ms]` descriptor passed in.
(Since whatever C-code that follows is allowed to work with datetime64
as if it were int64.)

Cheers,

Sebastian


> 
> Best regards
> 
> On Tue, 2022-01-18 at 09:22 -0600, Sebastian Berg wrote:
> > On Tue, 2022-01-18 at 14:56 +0100, Benoit Gschwind wrote:
> > > Hello,
> > > 
> > > I using the following code:
> > > 
> > > if (PyArray_TYPE(arr1) == NPY_DATETIME) {
> > > // Ensure datetime64[ms]
> > > auto tmp =
> > > reinterpret_cast(PyObject_CallMethod(reinterpret_
> > > ca
> > > st
> > > (arr1), "astype", "(s)", "datetime64[ms]"));
> > > std::swap(arr1, tmp);
> > > Py_XDECREF(tmp);
> > > // Ensure integer
> > > tmp =
> > > reinterpret_cast(PyObject_CallMethod(reinterpret_
> > > ca
> > > st
> > > (arr1), "astype", "(s)", "i8"));
> > > std::swap(arr1, tmp);
> > > Py_XDECREF(tmp);
> > > tmp =
> > > reinterpret_cast(PyArray_FromArray(arr1,
> > > PyArray_DescrFromType(NPY_INT64), NPY_ARRAY_IN_ARRAY));
> > > std::swap(arr1, tmp);
> > > Py_XDECREF(tmp);
> > > }
> > > 
> > > First, if something is wrong with my code let me known. Then I
> > > wonder
> > > if I can have a safe shortcut to avoid converting datetime64 to
> > > i8.
> > > I
> > > guess the internal data of datetime64[ms] is i8 thus copying and
> > > casting the array may be avoided.
> > 
> > Yes, you can assume datetime64 is stored as an i8 with the unit and
> > possible byteswapping.  Both of which, your initial cast will
> > ensure.
> > 
> > The internal data is i8, except for the special NaT value.
> > 
> > Code-wise, you can avoid calling `astype`, but if you do (also in
> > python), I suggest to pass `copy=False`, so that it does not copy
> > if
> > it
> > clearly is not necessary (I am hoping to improve on the "clearly"
> > here
> > at some point).
> > 
> > The last call again seems to be a no-op?  Just the last call with
> > the
> > correct `datetime64[ms]` descriptor could be enough.
> > 
> > Cheers,
> > 
> > Sebastian
> >  
> > 
> > > 
> > > Thanks by advance
> > > Best regards.
> > > 
> > > 
> > > ___
> > > 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: gschw...@gnu-log.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: sebast...@sipsolutions.net



signature.asc
Description: This is a digitally signed message part
___
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 1.22.1 has been released.

[Matti Picus]

On 18/1/22 5:37 pm, Peter Cock wrote:


Dear Charles,

Thank you for your work on the numpy releases, including v1.22.1.

I noticed that for Windows Python 3.10, there is only a 64-bit wheel:


...

Is this expected? My interest is in building Windows Wheels for 
packages compiling against NumPy.


Thank you,

Peter




Hi Peter. This is intentional, as our wheel building system is based on 
Azure CI, and they did not provide 32-bit python for 3.10 for windows. 
We decided to "solve" this and other wheel building issues by moving to 
cibuildwheel in github actions in the main repo (building on travis-ci 
for the aarch64 wheels) [1] for the 1.23 release. Digging around in the 
azure image repo issues, I see they may have restored 32-bit python [2] 
in mid Nov 2021, when we were already well into the 1.22 release cycle. 
I guess we could try to see if it works now. A PR to modify the azure 
pipelines yml would move us in this direction. I don't know that even if 
the PR is successful if we would put the wheels up on PyPI, that 
decision is up to the release manager.


Matti


[1] https://github.com/numpy/numpy/issues/20277

[2] https://github.com/actions/virtual-environments/issues/4400

[3] https://github.com/MacPython/numpy-wheels/blob/main/azure-pipelines.yml


___
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] next NumPy Community meeting – January 19th at 18:00 (6 pm) UTC

[Inessa Pawson]

Our next NumPy Community meeting is scheduled for tomorrow, Wednesday, January 
19th at 18:00 (6 pm) UTC.*

Join us via Zoom: https://berkeley.zoom.us/j/762261535
As always, everyone is welcome and encouraged to attend.

To add to the meeting agenda the topics you’d like to discuss, follow the link: 
https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both

*PLEASE NOTE that the schedule has slightly changed: starting tomorrow, we will 
be meeting an hour earlier.
To convert the start time to the local time of the area you are in, use the 
following link: 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Newcomers%27+Hour&iso=20220119T18&p1=1440&ah=1

Cheers,
Inessa

Inessa Pawson
Contributor Experience Lead | NumPy
___
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 1.22.1 has been released.

[Peter Cock]

That's helpful and informative, thank you Matti.

It will also be interesting to see how many calls you get for the
missing wheel (if any). I note that the Python.org download
page says quite clearly that the 64-bit Windows installer is
recommended.

Kind regards,

Peter

On Tue, Jan 18, 2022 at 7:24 PM Matti Picus  wrote:

> On 18/1/22 5:37 pm, Peter Cock wrote:
>
> > Dear Charles,
> >
> > Thank you for your work on the numpy releases, including v1.22.1.
> >
> > I noticed that for Windows Python 3.10, there is only a 64-bit wheel:
> >
> >
> > ...
> >
> > Is this expected? My interest is in building Windows Wheels for
> > packages compiling against NumPy.
> >
> > Thank you,
> >
> > Peter
> >
> >
>
> Hi Peter. This is intentional, as our wheel building system is based on
> Azure CI, and they did not provide 32-bit python for 3.10 for windows.
> We decided to "solve" this and other wheel building issues by moving to
> cibuildwheel in github actions in the main repo (building on travis-ci
> for the aarch64 wheels) [1] for the 1.23 release. Digging around in the
> azure image repo issues, I see they may have restored 32-bit python [2]
> in mid Nov 2021, when we were already well into the 1.22 release cycle.
> I guess we could try to see if it works now. A PR to modify the azure
> pipelines yml would move us in this direction. I don't know that even if
> the PR is successful if we would put the wheels up on PyPI, that
> decision is up to the release manager.
>
> Matti
>
>
> [1] https://github.com/numpy/numpy/issues/20277
>
> [2] https://github.com/actions/virtual-environments/issues/4400
>
> [3]
> https://github.com/MacPython/numpy-wheels/blob/main/azure-pipelines.yml
>
>
> ___
> 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: p.j.a.c...@googlemail.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: call for contributions – content writers for the NumPy newsletter

[rajasekaran86]

Respected madam,

   I would like to contribute to the Numpy documentation team.I am a beginner 
in contributing to open source community.So Please guide me on how to get 
started in contributing to the Numpy documentation team.I am very eager to 
start my contributions as soon as possible.Please let me know.

  Thanking you.

Yours respectively,

K.Rajasekaran
___
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: call for contributions – content writers for the NumPy newsletter

[Inessa Pawson]

K. Rajasekaran, hello and welcome!

We have quite a few options for you. We always welcome educational content 
(tutorials, how-tos, etc.). If you are interested in technical writing from the 
development point of view, there are plenty of documentation issues in our 
GitHub repo: https://github.com/numpy/numpy/labels/04%20-%20Documentation. Let 
us know what you’d like to take on, and we will send you more info about it.

If you would like to connect with other NumPy contributors, consider attending 
one of our virtual community events. To keep track of them, I recommend 
subscribing to the NumPy community Google calendar: 
https://calendar.google.com/calendar/r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20
 or joining our #events channel on the NumPy Slack.

Cheers,
Inessa

Inessa Pawson
Contributor Experience Lead | NumPy
email: ine...@albuscode.org
___
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 Newcomers Hour – Thursday, January 13th

[Inessa Pawson]

Ganesh Kathiresan's presentation for the latest Newcomers Hour has been posted 
on the NumPy YouTube channel: https://youtu.be/VXxa3G4BtEc

P.S. Don't forget to subscribe!

Cheers,
Inessa

Inessa Pawson
Contributor Experience Lead | NumPy
___
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] Performance mystery

[Warren Weckesser]

In the script below, the evaluation of the expression `z.real**2 +
z.imag**2` is timed using the `timeit` module. `z` is a 1D array of
random samples with dtype `np.complex128` and with length 25.

The mystery is the change in performance of the calculation from the
first array to which it is applied to the second.  The output of the
script is

```
numpy version 1.23.0.dev0+460.gc30876f64

 619.7096 microseconds
 625.3833 microseconds
 634.8389 microseconds

 137.0659 microseconds
 137.5231 microseconds
 137.5582 microseconds
```

Each batch of three timings corresponds to repeating the timeit
operation three times on the same random array `z`; i.e. a new array
`z` is generated for the second batch.  The question is why is does it
take so much longer to evaluate the expression the first time?

Some other details:

* If I change the expression to, say, `'z.real + z.imag'`, the huge
disparity disappears.
* If I generate more random `z` arrays, the performance remains at the
level of approximately 140 usec.
* I used the main branch of numpy for the above output, but the same
thing happens with 1.20.3, so this is not the result of a recent
change.
* So far, when I run the script, I always see output like that shown
above: the time required for the first random array is typically four
times that required for the second array.  If I run similar commands
in ipython, I have seen the slow case repeated several times (with
newly generated random arrays), but eventually the time drops down to
140 usec (or so), and I don't see the slow case anymore.
* I'm using a 64 bit Linux computer:
  ```
  $ uname -a
  Linux pop-os 5.15.8-76051508-generic
#202112141040~1639505278~21.10~0ede46a SMP Tue Dec 14 22:38:29 U
x86_64 x86_64 x86_64 GNU/Linux
  ```

Any ideas?

Warren

Here's the script:

```
import timeit
import numpy as np


def generate_sample(n, rng):
return rng.normal(scale=1000, size=2*n).view(np.complex128)


print(f'numpy version {np.__version__}')
print()

rng = np.random.default_rng()
n = 25
timeit_reps = 1

expr = 'z.real**2 + z.imag**2'

z = generate_sample(n, rng)
for _ in range(3):
t = timeit.timeit(expr, globals=globals(), number=timeit_reps)
print(f"{1e6*t/timeit_reps:9.4f} microseconds")
print()

z = generate_sample(n, rng)
for _ in range(3):
t = timeit.timeit(expr, globals=globals(), number=timeit_reps)
print(f"{1e6*t/timeit_reps:9.4f} microseconds")
print()
```
___
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: Performance mystery

[Stefan van der Walt]

On Tue, Jan 18, 2022, at 21:55, Warren Weckesser wrote:
> expr = 'z.real**2 + z.imag**2'
>
> z = generate_sample(n, rng)

🤔 If I duplicate the `z = ...` line, I get the fast result throughout.  If, 
however, I use `generate_sample(1, rng)` (or any other value than `n`), it does 
not improve matters.

Could this be a memory caching issue?

Stéfan
___
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: Performance mystery

[Andrew Nelson]

Might be a 'warmup' of the timeit module?
___
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