[Numpy-discussion] ANN: NumExpr 2.7.2

[Robert McLeod]

Announcing NumExpr 2.7.2


Hi everyone,

It's been awhile since the last update to NumExpr, mostly as the existing
scientific
Python tool chain for building wheels on PyPi became defunct and we have
had to
redevelop a new one based on `cibuildwheel` and GitHub Actions. This
release also
brings us support (and wheels for) Python 3.9.

There have been a number of changes to enhance how NumExpr works when NumPy
uses MKL as a backend.

Project documentation is available at:

http://numexpr.readthedocs.io/

Changes from 2.7.1 to 2.7.2
---

- Support for Python 2.7 and 3.5 is deprecated and will be discontinued
when
  `cibuildwheels` and/or GitHub Actions no longer support these versions.
- Wheels are now provided for Python 3.7, 3.5, 3.6, 3.7, 3.8, and 3.9 via
  GitHub Actions.
- The block size is now exported into the namespace as
`numexpr.__BLOCK_SIZE1__`
  as a read-only value.
- If using MKL, the number of threads for VML is no longer forced to 1 on
loading
  the module. Testing has shown that VML never runs in multi-threaded mode
for
  the default BLOCKSIZE1 of 1024 elements, and forcing to 1 can have
deleterious
  effects on NumPy functions when built with MKL. See issue #355 for
details.
- Use of `ndarray.tostring()` in tests has been switch to
`ndarray.tobytes()`
  for future-proofing deprecation of `.tostring()`, if the version of NumPy
is
  greater than 1.9.
- Added a utility method `get_num_threads` that returns the (maximum)
number of
  threads currently in use by the virtual machine. The functionality of
  `set_num_threads` whereby it returns the previous value has been
deprecated
  and will be removed in 2.8.X.

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
robbmcl...@gmail.com
robert.mcl...@hitachi-hhtc.ca
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Help needed GDB

[Amardeep Singh]

Hi All,

I am trying to debug c code of numpy via gdb.Can someone help me with this?
i am getting " Python scripting is not supported in this copy of GDB". How
to install python supported gdb on win10?


https://numpy.org/doc/stable/dev/development_environment.html

I am following the steps in the docs. machine is windows 10.

Debugging


Another frequently asked question is “How do I debug C code inside NumPy?”.
First, ensure that you have gdb installed on your system with the Python
extensions (often the default on Linux). You can see which version of
Python is running inside gdb to verify your setup:

(gdb) python>import
sys>print(sys.version_info)>endsys.version_info(major=3, minor=7,
micro=0, releaselevel='final', serial=0)




$ gdb -v
GNU gdb (GDB) 7.6.1
This GDB was configured as "mingw32".

$ gdb
(gdb) python
>import sys
>print(sys.version_info)
>end
(gdb) Python scripting is not supported in this copy of GDB.
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Addition of new distributions: Polya-gamma

[Robert Kern]

My view is that we will not add more non-uniform distribution (i.e. "named"
statistical probability distributions like Polya-Gamma) methods to
`Generator`. I think that we might add a couple more methods to handle some
more fundamental issues (like sampling from the unit interval with control
over whether each boundary is open or closed, maybe one more variation on
shuffling) that helps write randomized algorithms. Now that we have the C
and Cython APIs which allow one to implement non-uniform distributions in
other packages, we strongly encourage that.

As I commented on the linked PR, `scipy.stats` would be a reasonable place
for a Polya-Gamma sampling function, even if it's not feasible to implement
an `rv_continuous` class for it. You have convinced me that the nature of
the Polya-Gamma distribution warrants this. The only issue is that scipy
still depends on a pre-`Generator` version of numpy. So I recommend
implementing this function in your own package with an eye towards
contributing it to scipy later.

On Sun, Dec 27, 2020 at 6:05 AM Zolisa Bleki  wrote:

> Hi All,
>
> I would like to know if Numpy accepts addition of new distributions since
> the implementation of the Generator interface. If so, what is the criteria
> for a particular distribution to be accepted? The reason why i'm asking is
> because I would like to propose adding the Polya-gamma distribution to
> numpy, for the following reasons:
>
> 1) Polya-gamma random variables are commonly used as auxiliary variables
> during data augmentation in Bayesian sampling algorithms, which have
> wide-spread usage in Statistics and recently, Machine learning.
> 2) Since this distribution is mostly useful for random sampling, it since
> appropriate to have it in numpy and not projects like scipy [1].
> 3) The only python/C++ implementation of the sampler available is licensed
> under GPLv3 which I believe limits copying into packages that choose to use
> a different license [2].
> 4) Numpy's random API makes adding the distribution painless.
>
> I have done preliminary work on this by implementing the distribution
> sampler as decribed in [3]; see:
> https://github.com/numpy/numpy/compare/master...zoj613:polyagamma .
> There is a more efficient sampling algorithm described in a later paper
> [4], but I chose not to start with that one unless I know it is worth
> investing time in.
>
> I would appreciate your thoughts on this proposal.
>
> Regards,
> Zolisa
>
>
> Refs:
> [1] https://github.com/scipy/scipy/issues/11009
> [2] https://github.com/slinderman/pypolyagamma
> [3] https://arxiv.org/pdf/1205.0310v1.pdf
> [4] https://arxiv.org/pdf/1405.0506.pdf
>
>
>
> Disclaimer - University of Cape Town This email is subject to UCT policies
> and email disclaimer published on our website at
> http://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650
> 9111. If this email is not related to the business of UCT, it is sent by
> the sender in an individual capacity. Please report security incidents or
> abuse via https://csirt.uct.ac.za/page/report-an-incident.php.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>


-- 
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion