Mailman 3 August 2022 - NumPy-Discussion

should random.standard_t allow df=inf?
by Sam Mason Aug. 12, 2022

Aug. 12, 2022

Hi, I've just stumbled across a somewhat strange behaviour when I evaluated: np.random.standard_t(np.inf) and got NaN back. The limit of df going to infinity in Student's t-distribution is a Gaussian, so I'd expect a Gaussian variate back (but I suppose a warning or error could be argued to be valid). Note that R explicitly supports this[1] and results in Gaussian behaviour[2]. It looks relatively easy to modify random_standard_t (in distributions.c) to get similar behaviour, but wanted to check if this behaviour was deliberate before opening an issue. In fact it looks like the precision of doubles limit df > ~1e35 to be Gaussian[3], which might compile down to something smaller than a call to isfinite() as well as catching more cases[4]. Thanks! Sam [1] https://search.r-project.org/R/refmans/stats/html/TDist.html [2] R source, src/nmath/rt.c, src/nmath/dt.c, etc. [3] np.random.gamma(1e35, size=100) - 1e35 [4] https://godbolt.org/z/KcvY8sKd3

1 0

I need help on the issue of replacing the original C math library with an external C math library
by 454626566＠qq.com Aug. 12, 2022

Aug. 12, 2022

Hello developers, The external math library contains some dynamic link libraries of C language (.so files) and some C header files (.h files), I am tring to link my custom library to NumPy and replace the original bottom math library. I need to add several compile options to the C compiler (gcc etc.), but I have not found the corrosponding part of NumPy source code. Merely modifying 'site.cfg' does not work at all, and then adding lib and include directory to '~/numpy/distutils/system_info.py' still does not work. When compiling NumPy source code, it gives a fatal error: myBLAS.h: No such file or directory. My doubts: Which code file should I focus on? How to modify configurations and add compile options like '-I /path/to/includes -L /path/to/libs -lmyBLAS'? Could you please give me a hint? Looking forward to your reply. Thanks!

2 1

Request to review a PR
by Ivan Tsybulin Aug. 9, 2022

Aug. 9, 2022

Hello, I kindly ask someone to join as a reviewer to my PR https://github.com/numpy/numpy/pull/21814 about handling np.float32 arrays in ma.mean and ma.std functions. The PR is aimed to fix different behaviour between np.core and ma variants of these functions. -- Ivan Tsybulin

1 0

Python 3.11.0rc1 is out
by Charles R Harris Aug. 8, 2022

Aug. 8, 2022

Hi All, Just to note that Python 3.11.0rc1 has been released. I plan to make a NumPy 1.23.2 release with support for that as soon as it is available on our build platforms. Chuck

1 0

Additional aliases for MaskedArray
by Matti Picus Aug. 8, 2022

Aug. 8, 2022

PR 21998 [0] adds methods "ones_like", "zeros_like", "dsplit","split", and "vsplit" for MaskedArrays. The motivation was to clean up broken documentation links, and it seemed logical to add the interfaces. As far as I can tell we do not have users asking for these methods. Should we add them (expanding the np.ma namespace) or find another way to fix the broken documentation links? Matti [0] https://github.com/numpy/numpy/pull/21998

2 1

aarch64 wheels on github actions
by Andrew Nelson Aug. 7, 2022

Aug. 7, 2022

At the moment Linux aarch64 wheels are being made in a TravisCI job. I've been experimenting recently about making scipy wheels for that target on Github Actions. cibuildwheel + github actions does quite well for that purpose. It takes around 2 hours for scipy wheels to be created (but not tested). I would expect numpy wheels to take less time to build. I think it would be a relatively minor modification of the .github/workflows/wheels script. cheers, Andrew. -- _____________________________________ Dr. Andrew Nelson _____________________________________

2 1

generate a random sample based on independent priors in `random.choice` #22082
by Rodo-Singh Aug. 4, 2022

Aug. 4, 2022

Proposed new feature or change: Objective: Sample elements from the given iterator (a list, a numpy array, etc.) based upon pre-defined probabilities associated with each element which may not sums upto 1. Overview * In the numpy.random.choice function the cases where we're explicitly providing the list of probabilistic values for an input sample, the requirement expects the sum of the whole list to be 1. This makes sense when all the elements are possible observation for a single random variable whose pmf(probability mass function) is nothing but the p list. * But when every element in that list can be regarded as observation of separate independent Bernoulli r.v. (random variable), then the problem falls into the category of multi-label. Intuitively speaking, for each element in the list or array given to us, we'll toss a coin (may be biased or unbiased) ~B(p) (i.e., follows Bernoulli with p as success probability for head). * The output array or list would probably be a proper subset or can be a full list or can be an empty one. * Plus, here the argument size should automatically get shut down as we just want which all elements got selected into the output list after n coin tossess (where len(list) = n). Also it may happen that each element is independent as argued above, but the sum(p) = 1. Then we can probably put an extra argument independence = True or independence = False.

3 2

Speedup NumPy conjugate,square and CPU cache
by tim-berberich＠arcor.de Aug. 4, 2022

Aug. 4, 2022

Hi all, I hope this is the right place to ask my questions. Recently I did some simple benchmarks on the numpy.conjugate routine for an 128 MB array, lets call it 'A'. It turned out that on my test machines there is a speed up of around 2.5 times if instead of simply calling A.conj() one loops over sub-matrices that fit into L1 cache of my CPU, like: for i in range(0,A.shape[0],size): A[i:i+size].conj() such that each A[i:i+size] fits into L1 cache. I posted example code and some graphs over at stackoverflow (https://stackoverflow.com/questions/73209565/strange-behaviour-during-multi…) I quickly checked and found a similar behavior for numpy.square. Now for my questions. 1. Is this a known/expected behavior of NumPy ? 2. Would it be possible/sensible to make simple numerical operations like numpy.conjugate & numpy.square cache aware ? Best, Tim

1 0