Mailman 3 March 2021 - NumPy-Discussion

String accessor methods
by Todd March 7, 2021

March 7, 2021

Currently. working with strings in numpy is not very convenient. You have to use a separate set of functions in a separate namespace, and those functions are relatively limited and poorly-documented. A solution several other projects, including pandas [0] and xarray [1], have found are string accessor methods. These are a set of methods attached to a `str` attribute of the class. These have the advantage that they are always available and have a well-defined object they operate on. On non-str dtypes, it would raise an exception. This would also provide a standardized set of methods and behaviors that are part of the numpy api that other classes could depend on. An example would be something like this: >>> mystr = np.array(["test first", "test second", "test third"]) >>> mystr.str.title() array(['Test First', 'Test Second', 'Test Third'], dtype='<U11') [0] https://pandas.pydata.org/pandas-docs/stable/user_guide/text.html#string-me… [1] https://xarray.pydata.org/en/stable/generated/xarray.core.accessor_str.Stri…

4 4

Development branches renamed
by Stefan van der Walt March 4, 2021

March 4, 2021

Hi everyone, The development branches of most of the repositories on github.com/numpy have been renamed to `main` (this is the GitHub default for newly created repositories). The move has not yet been made for sub-projects such as `numpydoc` or `numpy.org`, but those should follow soon. We were able to preserve all PRs, other than those for which the original branches have been deleted. You can update your locally cloned repository to have a `main` branch as follows: git branch -m master main git fetch <YOUR_UPSTREAM_REMOTE> git branch -u <YOUR_UPSTREAM_REMOTE>/main main (where YOUR_UPSTREAM_REMOTE is typically called `upstream` or `origin`) If you have any trouble, let us know. Best regards, Stéfan

2 1

ANN: NumExpr 2.7.3
by Robert McLeod March 3, 2021

March 3, 2021

======================== Announcing NumExpr 2.7.3 ======================== Hi everyone, This is a maintenance release to make use of the oldest supported NumPy version when building wheels, in an effort to alleviate issues seen on Windows machines that do not have the latest Windows MSVC runtime installed. It also adds wheels built via GitHub Actions for ARMv8 platforms. Project documentation is available at: http://numexpr.readthedocs.io/ Changes from 2.7.2 to 2.7.3 --------------------------- - Pinned Numpy versions to minimum supported version in an effort to alleviate issues seen in Windows machines not having the same Windows SDK installed as was used to build the wheels. - ARMv8 wheels are now available, thanks to `odidev` for the pull request. What's Numexpr? --------------- Numexpr is a fast numerical expression evaluator for NumPy. With it, expressions that operate on arrays (like "3*a+4*b") are accelerated and use less memory than doing the same calculation in Python. It has multi-threaded capabilities, as well as support for Intel's MKL (Math Kernel Library), which allows an extremely fast evaluation of transcendental functions (sin, cos, tan, exp, log...) while squeezing the last drop of performance out of your multi-core processors. Look here for a some benchmarks of numexpr using MKL: https://github.com/pydata/numexpr/wiki/NumexprMKL Its only dependency is NumPy (MKL is optional), so it works well as an easy-to-deploy, easy-to-use, computational engine for projects that don't want to adopt other solutions requiring more heavy dependencies. Where I can find Numexpr? ------------------------- The project is hosted at GitHub in: https://github.com/pydata/numexpr You can get the packages from PyPI as well (but not for RC releases): http://pypi.python.org/pypi/numexpr Documentation is hosted at: http://numexpr.readthedocs.io/en/latest/ Share your experience --------------------- Let us know of any bugs, suggestions, gripes, kudos, etc. you may have. Enjoy data! -- Robert McLeod robbmcleod(a)gmail.com robert.mcleod(a)hitachi-hhtc.ca

1 0

Possible
by Michal Radwanski Feb. 28, 2021

Feb. 28, 2021

Hello, I'm not sure if it's expected behaviour or a bug, so I decided to write here. First an example: In [4]: array([2**63]) Out[4]: array([9223372036854775808], dtype=uint64) In [5]: array([2**63-1, 2**63]) Out[5]: array([9.22337204e+18, 9.22337204e+18]) The docs for `numpy.array` mention, that: dtype : data-type, optional The desired data-type for the array. If not given, then the type will be determined as the minimum type required to hold the objects in the sequence. I understand the type promotions here, but I believe that the documentation is wrong in this case. Indeed, the minumum type in the latter case would be 'uint64'. Is it a bug worth submitting/fixing? -- Z wyrazami szacunku Michał Radwański With kind regards Michał Radwański

2 2