Mailman 3 November 2019 - NumPy-Discussion

[JOB] Software Engineer position for open source/development projects
by Nadia Dencheva Nov. 13, 2019

Nov. 13, 2019

Who we are: The Data Analysis Tools Branch (DATB) at the Space Telescope Science Institute (STScI) in Baltimore, MD, has an opening for a software engineer to work on community developed projects like astropy<https://github.com/astropy/astropy>, asdf<https://github.com/spacetelescope/asdf>, etc. DATB develops open source data-analysis tools for astronomy though some of them are general and used by other sciences. Contributions to numpy/scipy are possible. Skillset We are looking for someone with the following skillset * Proficient in Python and C/C++ . * Comfortable developing primarily in/for Linux/Unix environment. * Experience with software library development and library API design * Experience writing developer and user documentation. * Fluent with continuous integration, Git and common developer tools. * Skilled in testing tools * Familiarity with both binary data representation in CPU memory and with data serialization standards such as YAML, JSON and XML How to apply Please apply online at https://recruiting2.ultipro.com/SPA1004AURA/JobBoard/93330e50-7b3a-4ba8-94f… Starting date This position is available for immediate start.

1 0

Re: [Numpy-discussion] Transonic Vision: unifying Python-Numpy accelerators
by PIERRE AUGIER Nov. 12, 2019

Nov. 12, 2019

> Date: Wed, 6 Nov 2019 23:49:08 -0500 > From: Ralf Gommers <ralf.gommers(a)gmail.com> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Subject: Re: [Numpy-discussion] Transonic Vision: unifying > Python-Numpy accelerators > Message-ID: > <CABL7CQhr6ps25Yrp_pAF8vWVLS3_2=Mw4bCOXb0H1dvU9AjTMw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Mon, Nov 4, 2019 at 4:54 PM PIERRE AUGIER < > pierre.augier(a)univ-grenoble-alpes.fr> wrote: > >> Dear Python-Numpy community, >> >> Transonic is a pure Python package to easily accelerate modern >> Python-Numpy code with different accelerators (currently Cython, Pythran >> and Numba). >> >> I'm trying to get some funding for this project. The related work would >> benefit in particular to Cython, Numba, Pythran and Xtensor. >> >> To obtain this funding, we really need some feedback from some people >> knowing the subject of performance with Python-Numpy code. >> >> That's one of the reason why we wrote this long and serious text on >> Transonic Vision: http://tiny.cc/transonic-vision. We describe some >> issues (perf for numerical kernels, incompatible accelerators, community >> split between experts and simple users, ...) and possible improvements. >> > > Thanks Pierre, that's a very interesting vision paper. Thanks Ralf for this kind and interesting reply! > > In case you haven't seen it, there was a discussion on the pandas-dev > mailing list a couple of weeks ago about adopting Numba as a dependency > (and issues with that). > > Your comment on my assessment from 1.5 years ago being a little unfair to > Pythran may be true - not sure it was at the time, but Pythran seems to > mature nicely. > > The ability to switch between just-in-time and ahead-of-time compilation is > nice. One thing I noticed is that this actual switching is not completely > fluent: the jit and boost decorators have different signatures, and there's > no way to globally switch behavior (say with an env var, as for backend > selection). Yes, it seems evident now but I forgot to update the jit decorators when I was working on the boost decorator. My first "targets" for Transonic are packages for which the ahead-of-time mode seems more adapted. This incompatibility between the 2 main decorators used in Transonic will soon be fixed! Regarding the way to globally switch behavior, I'll open a dedicated issue. >> Help would be very much appreciated. >> > > I'd be interested to help think about adoption and/or funding. > > Cheers, > Ralf > As you've seen with the jit/boost incompatibility, I guess API design would be better if people knowing the subject could be included in some discussions. For example, I had to design the Python API for type declaration of arrays (see https://transonic.readthedocs.io/en/latest/generated/transonic.typing.html) since I didn't find anything adapted. My implementation is not great neither since types in transonic.typing and in `typing` are right now not compatible ! (However, it won't be difficult to fix that) Another API design that needs to be thought is about user-defined types in Transonic. This is for future because Pythran does not currently support that, but I think we will have to be able to support kind of dataclass, something like the equivalent of C struct (corresponding to Cython `cdef class` and Numba `jitclass`). A more theoretical subject that would be interesting to investigate is about the subset of Python-Numpy that can and should be implemented by accelerators. For example, I think a function having different branches with different types for the returned objects depending of runtime values cannot be rewritten as efficient modern C++. If you know people potentially interested to discuss about these subjects, please tell me. Cheers, Pierre

2 1

Code Review for the Two-Sided Geometric Distribution - PR 14890
by Andrew Reed Nov. 12, 2019

Nov. 12, 2019

All, I created a PR for the "two-sided geometric distribution": https://github.com/numpy/numpy/pull/14890 This is my first attempt at contributing to any sort of open source project, and I can already see that some of the post-commit checks have failed. I will try to dig into those. Also, I was unable to get Sphinx to build a reference to my added function, so I have not been able to verify if the docstring renders properly. Additional Notes: (1) The first paper that I reference presented this distribution as the "discrete Laplace distribution." This is also how the R programming language refers to this distribution. SciPy, however, appears to use a different distribution for what it calls the "discrete Laplacian distribution." Personally, I feel that referring to the version in my PR as the "two-sided geometric distribution" better conveys how it works. (2) I describe the parameter 'alpha' as the distribution's "rate of decay." I can see, though, that this may be an inaccurate way to describe 'alpha' since it doesn't work exactly like a "rate of decay" in the Physics sense. Perhaps I should have referred to it as the "distribution's constant ratio." Either way, I think the documentation should be clear enough that a user would not confuse 'alpha' with 'p' from the geometric function (caveat: once the distribution moves away from zero, alpha works like 1 - p). Respectfully, Andrew Reed

1 0

Disallow Accelerate as a LAPACK backend for NumPy
by Matti Picus Nov. 12, 2019

Nov. 12, 2019

Apple has dropped support for Accelerate. It has bugs that have not been fixed, and is closed source so we cannot fix them ourselves. We have been getting a handful of reports from users who end up building NumPy on macOS, and inadvertently link to Accelerate, then end up with wrong linalg results. In PR 14880 https://github.com/numpy/numpy/pull/14880 I propose to disallow finding it when building NumPy. At this time it will remain in distutils as one of the backends to support users, but how do people feel about a future PR to totally remove it? Matti

3 2

NumPy 1.17.4 release.
by Charles R Harris Nov. 10, 2019

Nov. 10, 2019

Hi All, On behalf of the NumPy team I am pleased to announce that NumPy 1.17.4 has been released. This is a bugfix release. The Python versions supported in this release are 3.5-3.8. Downstream developers should use Cython >= 0.29.13 for Python 3.8 support and OpenBLAS >= 3.7 to avoid wrong results on the Skylake architecture. The NumPy Wheels for this release can be downloaded from PyPI <https://pypi.org/project/numpy/1.17.4/>, source archives and release notes are available from Github <https://github.com/numpy/numpy/releases/tag/v1.17.4>. *Highlights* - Fixed `random.random_integers` biased generation of 8 and 16 bit integers. - Fixed `np.einsum` regression on Power9 and z/Linux. - Fixed histogram problem with signed integer arrays *Contributors* A total of 5 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Charles Harris - Chris Burr + - Matti Picus - Qiming Sun + - Warren Weckesser *Pull requests merged* A total of 8 pull requests were merged for this release. - gh-14758: BLD: Declare support for python 3.8 - gh-14781: BUG: Random: biased samples from integers() with 8 or 16 bit... - gh-14851: BUG: Fix `_ctypes` class circular reference. (gh-13808) - gh-14852: BLD: Add 'apt update' to shippable - gh-14855: BUG: Fix `np.einsum` errors on Power9 Linux and z/Linux - gh-14857: BUG: Fix histogram problem with signed integer arrays. - gh-14858: BLD: Prevent -flto from optimising long double representation... - gh-14866: MAINT: move buffer.h -> npy_buffer.h to avoid conflicts Cheers, Charles Harris

1 0

ANN: SciPy 1.3.2
by Tyler Reddy Nov. 9, 2019

Nov. 9, 2019

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, On behalf of the SciPy development team I'm pleased to announce the release of SciPy 1.3.2, a maintenance and bug fix release that adds support for Python 3.8. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.3.2 One of a few ways to install this release with pip: pip install scipy==1.3.2 ========================== SciPy 1.3.2 Release Notes ========================== SciPy 1.3.2 is a bug-fix and maintenance release that adds support for Python 3.8. Authors ======= * CJ Carey * Dany Vohl * Martin Gauch + * Ralf Gommers * Matt Haberland * Eric Larson * Nikolay Mayorov * Sam McCormack + * Andrew Nelson * Tyler Reddy * Pauli Virtanen * Huize Wang + * Warren Weckesser * Joseph Weston + A total of 14 people contributed to this release. People with a "+" by their names contributed a patch for the first time. This list of names is automatically generated, and may not be fully complete. Issues closed for 1.3.2 ------------------------------- * `#4915 <https://github.com/scipy/scipy/issues/4915>`__: Bug in unique_roots in scipy.signal.signaltools.py for roots... * `#5161 <https://github.com/scipy/scipy/issues/5161>`__: Optimizers reporting success when the minimum is NaN * `#5546 <https://github.com/scipy/scipy/issues/5546>`__: ValueError raised if scipy.sparse.linalg.expm recieves array... * `#10124 <https://github.com/scipy/scipy/issues/10124>`__: linprog(method='revised simplex') doctest bug * `#10609 <https://github.com/scipy/scipy/issues/10609>`__: Graph shortest path with Floyd-Warshall removes explicit zeros. * `#10658 <https://github.com/scipy/scipy/issues/10658>`__: BUG: stats: Formula for the variance of the noncentral F distribution... * `#10695 <https://github.com/scipy/scipy/issues/10695>`__: BUG: Assignation issues in csr_matrix with fancy indexing * `#10846 <https://github.com/scipy/scipy/issues/10846>`__: root_scalar fails when passed a function wrapped with functools.lru_cache * `#10902 <https://github.com/scipy/scipy/issues/10902>`__: CI: travis osx build failure * `#10967 <https://github.com/scipy/scipy/issues/10967>`__: macOS build failure in SuperLU on maintenance/1.3.x * `#10976 <https://github.com/scipy/scipy/issues/10976>`__: Typo in sp.stats.wilcoxon docstring Pull requests for 1.3.2 ------------------------------ * `#10498 <https://github.com/scipy/scipy/pull/10498>`__: TST: optimize: fixed \`linprog\` \`"disp": True\` bug * `#10536 <https://github.com/scipy/scipy/pull/10536>`__: CI: add 3.8-dev to travis * `#10671 <https://github.com/scipy/scipy/pull/10671>`__: BUG: stats: Fix the formula for the variance of the noncentral... * `#10693 <https://github.com/scipy/scipy/pull/10693>`__: BUG: ScalarFunction stores original array * `#10700 <https://github.com/scipy/scipy/pull/10700>`__: BUG: sparse: Loosen checks on sparse fancy assignment * `#10709 <https://github.com/scipy/scipy/pull/10709>`__: BUG: Fix floyd_warshall to support zero-weight edges * `#10756 <https://github.com/scipy/scipy/pull/10756>`__: BUG: optimize: ensure solvers exit with success=False for nan... * `#10833 <https://github.com/scipy/scipy/pull/10833>`__: BUG: Fix subspace_angles for complex values * `#10882 <https://github.com/scipy/scipy/pull/10882>`__: BUG: sparse/arpack: fix incorrect code for complex hermitian... * `#10891 <https://github.com/scipy/scipy/pull/10891>`__: BUG: make C-implemented root finders work with functools.lru_cache * `#10906 <https://github.com/scipy/scipy/pull/10906>`__: BUG: sparse/linalg: fix expm for np.matrix inputs * `#10917 <https://github.com/scipy/scipy/pull/10917>`__: CI: fix travis osx CI * `#10930 <https://github.com/scipy/scipy/pull/10930>`__: MAINT: Updates for 3.8 * `#10938 <https://github.com/scipy/scipy/pull/10938>`__: MAINT: Add Python 3.8 to pyproject.toml * `#10943 <https://github.com/scipy/scipy/pull/10943>`__: BLD: update Cython version to 0.29.13 * `#10961 <https://github.com/scipy/scipy/pull/10961>`__: BUG: Fix signal.unique_roots * `#10971 <https://github.com/scipy/scipy/pull/10971>`__: MAINT: use 3.8 stable in CI * `#10977 <https://github.com/scipy/scipy/pull/10977>`__: DOC: Fix typo in sp.stats.wilcoxon docsting * `#11025 <https://github.com/scipy/scipy/pull/11025>`__: Update _peak_finding.py Checksums ========= MD5 ~~~ 5acb33b69d73d369b05f10aaf24220c4 scipy-1.3.2-cp35-cp35m-macosx_10_6_intel.whl 2afea38680dc72f356965178c128747d scipy-1.3.2-cp35-cp35m-manylinux1_i686.whl 97d2aa748499111d348c283b4e435755 scipy-1.3.2-cp35-cp35m-manylinux1_x86_64.whl 22cbe9c7a2bef004cda3b18355b5d277 scipy-1.3.2-cp35-cp35m-win32.whl e6e3d77c7e7d92344263e55b7f7f14ba scipy-1.3.2-cp35-cp35m-win_amd64.whl 6abb6cdc43950ad31456559dc442571b scipy-1.3.2-cp36-cp36m-macosx_10_6_intel.whl 6ffd1eb60e209d1e329c65db9064ba01 scipy-1.3.2-cp36-cp36m-manylinux1_i686.whl 1c549d17701e2a42836857dfed876854 scipy-1.3.2-cp36-cp36m-manylinux1_x86_64.whl 89895563ebad22c42678002402d7f000 scipy-1.3.2-cp36-cp36m-win32.whl f1f19a0307fa1ce5e5e3fae288e6d317 scipy-1.3.2-cp36-cp36m-win_amd64.whl b12328c09d018bf0958096bd29e528a8 scipy-1.3.2-cp37-cp37m-macosx_10_6_intel.whl 6b268afa77f99fbdf02d43255365b6e7 scipy-1.3.2-cp37-cp37m-manylinux1_i686.whl 5a258b29cae36f2f35167b08c79a5b3c scipy-1.3.2-cp37-cp37m-manylinux1_x86_64.whl 2639b1c67a33c23ee5b0d4d3057106e2 scipy-1.3.2-cp37-cp37m-win32.whl 5201e48b5e3fca2e056fbe4e4b79f2c3 scipy-1.3.2-cp37-cp37m-win_amd64.whl 43087f7b2e363f8f953d037d608dd53f scipy-1.3.2-cp38-cp38-macosx_10_9_x86_64.whl 0a5444f72721ceaf1eb875ac9ac2b31f scipy-1.3.2-cp38-cp38-manylinux1_i686.whl 44372a0125d0e2d8a3041e89fe01a944 scipy-1.3.2-cp38-cp38-manylinux1_x86_64.whl 345c6459a52f81d2e3f3b490b932be4a scipy-1.3.2-cp38-cp38-win32.whl 8ff866aadbc56067c9d09551ce072d7f scipy-1.3.2-cp38-cp38-win_amd64.whl 019eabd9ef410bb7bf2e7eda09cefc4d scipy-1.3.2.tar.gz 742eb61ce825d8cb6a419e5d1dfd822c scipy-1.3.2.tar.xz b1ece516b97390ece5153dfc3dc4bc75 scipy-1.3.2.zip SHA256 ~~~~~~ 7a0477929e6f9d5928fe81fe75d00b7da9545a49109e66028d85848b18aeef99 scipy-1.3.2-cp35-cp35m-macosx_10_6_intel.whl 0f81e71149539ac09053a3f9165659367b060eceef3bbde11e6600e1c341f1f2 scipy-1.3.2-cp35-cp35m-manylinux1_i686.whl ecfd45ca0ce1d6c13bef17794b4052cc9a9574f4be8d44c9bcfd7e34294bd2d7 scipy-1.3.2-cp35-cp35m-manylinux1_x86_64.whl ee5888c62cd83c9bf9927ffcee08434e7d5c81a8f31e5b85af5470e511022c08 scipy-1.3.2-cp35-cp35m-win32.whl 07673b5b96dbe28c88f3a53ca9af67f802aa853de7402e31f473b4dd6501c799 scipy-1.3.2-cp35-cp35m-win_amd64.whl 2e4b5fdb635dd425bf46fbd6381612692d3c795f1eb6fe62410305a440691d46 scipy-1.3.2-cp36-cp36m-macosx_10_6_intel.whl 4ad7a3ae9831d2085d6f50b81bfcd76368293eafdf31f4ac9f109c6061309c24 scipy-1.3.2-cp36-cp36m-manylinux1_i686.whl df4dbd3d40db3f667e0145dba5f50954bf28b2dd5b8b400c79d5e3fe8cb67ce2 scipy-1.3.2-cp36-cp36m-manylinux1_x86_64.whl 470d8fc76ccab6cfff60a9de4ce316a23ee7f63615d948c7446dc7c1bb45042d scipy-1.3.2-cp36-cp36m-win32.whl f018892621b787b9abf76d51d1f0c21611c71752ebb1891ccf7992e0bf973708 scipy-1.3.2-cp36-cp36m-win_amd64.whl 34c48d922760782732d6f8f4532e320984d1280763c6787c6582021d34c8ad79 scipy-1.3.2-cp37-cp37m-macosx_10_6_intel.whl 33ac3213ee617bbc0eac84d02b130d69093ed7738afb281dfdeb12a9dbdf1530 scipy-1.3.2-cp37-cp37m-manylinux1_i686.whl 9c3221039da50f3b60da70b65d6b020ea26cefbb097116cfec696010432d1f6c scipy-1.3.2-cp37-cp37m-manylinux1_x86_64.whl 2dc26e5b3eb86b7adad506b6b04020f6a87e1102c9acd039e937d28bdcee7fa6 scipy-1.3.2-cp37-cp37m-win32.whl 0359576d8cc058bd615999cf985e2423dc6cc824666d60e8b8d4810569a04655 scipy-1.3.2-cp37-cp37m-win_amd64.whl e837c8068bd1929a533e9d51562faf6584ddb5303d9e218d8c11aa4719dcd617 scipy-1.3.2-cp38-cp38-macosx_10_9_x86_64.whl 61812a7db0d9bc3f13653e52b8ddb1935cf444ec55f39160fc2778aeb2719057 scipy-1.3.2-cp38-cp38-manylinux1_i686.whl 3f556f63e070e9596624e42e99d23b259d8f0fc63ec093bef97a9f1c579565b2 scipy-1.3.2-cp38-cp38-manylinux1_x86_64.whl 125aa82f7b3d4bd7f77fed6c3c6e31be47e33f129d829799569389ae59f913e7 scipy-1.3.2-cp38-cp38-win32.whl f2d5db81d90d14a32d4aff920f52fca5639bcaaaf87b4f61bce83a1d238f49fc scipy-1.3.2-cp38-cp38-win_amd64.whl a03939b431994289f39373c57bbe452974a7da724ae7f9620a1beee575434da4 scipy-1.3.2.tar.gz 1d2f09bcb6c4b66a65d9f49d21fa065f5396c940edac8285b87947b8d21b55f8 scipy-1.3.2.tar.xz aa18ee47e2e606ececc5b0df672705e0ee413d249bf9c129be2fd280dcd21a32 scipy-1.3.2.zip -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJdxx+LAAoJELD/41ZX0J71CooQAJwQGqTxyG0FCXNk5EffrRC0 CL+4nnD8eonzjZE+Oc7Lj4uiTITgJ+E7bd0WHhmaLAHZe2mGhZJlPS1c6Nb3nURB knJwKyIIgf2IAbnO+bBg7txosuU1RQidwq3xmofGJTXadUfVc1S1iEqnxpFN0GmN dlZcvuPMnWwMawM3ort+JVB01t338PlMso3bOdP4yUJXdaxUmj4TESbJV4gLUaHg e8s2i4ASKBz7GaJ4bkiKDgxJdP807gu6KEKqOQDLRYoN0kQ1yp+KaAcjEnTMSsPa 8mVa9R/CZF+J/YX1MxyITs7hr/czMPGRVHQbTDh3Lc0BqRJdidgswgQQ8IChhIEm lFW6PefS18Un9dHD9jTQ+GI4WCKBpsN08qeCpFn+cwBnL7bdloS3CcPV1JDChjdK SI56wCw9vwc+w7R3Rg4n+KO2UUoxar0jNJXU0wT6ZdbX0A367i/7XJ57ToWXI5ax DUchJNj9SIOKEzoPwO/XR16KeurLeJcoJbon4kj4JjfrNI7Z03sw0hn4ALLQpOP5 /l49Nwa5VJGxWvSJCNaLV9qPjhzbFDyG+adLxFiMDvbvFaNrnm7Zkp4vPCcjNe+m r+0k1bfUrzE1eyZCuHGU+e9Vz7nSPODqhuenxz3PWBnqVJSSaBtgDGEiNddjstbW YvhHlfbIYBst7HvxR7xQ =roJQ -----END PGP SIGNATURE-----

2 1

Re: [Numpy-discussion] Transonic Vision: unifying Python-Numpy accelerators
by PIERRE AUGIER Nov. 6, 2019

Nov. 6, 2019

Dear Python-Numpy community, Transonic is a pure Python package to easily accelerate modern Python-Numpy code with different accelerators (currently Cython, Pythran and Numba). I'm trying to get some funding for this project. The related work would benefit in particular to Cython, Numba, Pythran and Xtensor. To obtain this funding, we really need some feedback from some people knowing the subject of performance with Python-Numpy code. That's one of the reason why we wrote this long and serious text on Transonic Vision: http://tiny.cc/transonic-vision. We describe some issues (perf for numerical kernels, incompatible accelerators, community split between experts and simple users, ...) and possible improvements. Help would be very much appreciated. Now a coding riddle: import numpy as np from transonic import jit @jit(native=True, xsimd=True) def fxfy(ft, fn, theta): sin_theta = np.sin(theta) cos_theta = np.cos(theta) fx = cos_theta * ft - sin_theta * fn fy = sin_theta * ft + cos_theta * fn return fx, fy @jit(native=True, xsimd=True) def fxfy_loops(ft, fn, theta): n0 = theta.size fx = np.empty_like(ft) fy = np.empty_like(fn) for index in range(n0): sin_theta = np.sin(theta[index]) cos_theta = np.cos(theta[index]) fx[index] = cos_theta * ft[index] - sin_theta * fn[index] fy[index] = sin_theta * ft[index] + cos_theta * fn[index] return fx, fy How can be compared the performances of these functions with pure Numpy, Numba and Pythran ? You can find out the answer in our note http://tiny.cc/transonic-vision :-) Pierre > Message: 1 > Date: Thu, 31 Oct 2019 21:16:06 +0100 (CET) > From: PIERRE AUGIER <pierre.augier(a)univ-grenoble-alpes.fr> > To: numpy-discussion(a)python.org > Subject: [Numpy-discussion] Transonic Vision: unifying Python-Numpy > accelerators > Message-ID: > <1080118635.5930814.1572552966711.JavaMail.zimbra(a)univ-grenoble-alpes.fr> > > Content-Type: text/plain; charset=utf-8 > > Dear Python-Numpy community, > > Few years ago I started to use a lot Python and Numpy for science. I'd like to > thanks all people who contribute to this fantastic community. > > I used a lot Cython, Pythran and Numba and for the FluidDyn project, we created > Transonic, a pure Python package to easily accelerate modern Python-Numpy code > with different accelerators. We wrote a long and serious text to explain why we > think Transonic could have a positive impact on the scientific Python > ecosystem. > > Here it is: http://tiny.cc/transonic-vision > > Feedback and discussions would be greatly appreciated! > > Pierre > > -- > Pierre Augier - CR CNRS http://www.legi.grenoble-inp.fr > LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels > BP53, 38041 Grenoble Cedex, France tel:+33.4.56.52.86.16

2 1

[ANN] pvfactors: a view-factor network model for bifacial PV by SunPower
by Dr. Mark Alexander Mikofski PhD Nov. 6, 2019

Nov. 6, 2019

SunPower has just released the latest version of pvfactors (v1.3.0), a Python package for modeling the incident irradiance on bifacial photovoltaic (PV) using the network radiosity model. Bifacial PV are solar panels that can generate energy from both the front and back surfaces. PyPI: https://pypi.org/project/pvfactors/ GitHub: https://github.com/SunPower/pvfactors/releases Thanks SunPower! -- Mark Mikofski, PhD (2005) *Fiat Lux*

1 0

argmax() indexes to value
by Daniele Nicolodi Nov. 1, 2019

Nov. 1, 2019

Hello, this is a very basic question, but I cannot find a satisfying answer. Assume a is a 2D array and that I get the index of the maximum value along the second dimension: i = a.argmax(axis=1) Is there a better way to get the value of the maximum array entries along the second axis other than: v = a[np.arange(len(a)), i] ?? Thank you. Cheers, Daniele

6 10