Re: [Numpy-discussion] Disallow Accelerate as a LAPACK backend for NumPy
On 12 Nov 2019, at 3:27 am, Ian Henriksen wrote: > > Extra data point here: SciPy already dropped support for Accelerate as of > version 1.2.0. > > Best, > > Ian Henriksen > > > On Mon, Nov 11, 2019 at 6:40 PM Matti Picus wrote: > 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? +1 from this side - when switching the packaged version of Scipy to OpenBLAS (already taking Numpy along the way) I noticed barely any performance penalties (if - with some benchmarks - it wasn’t actually faster than Accelerate). Cheers, Derek ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Code Review for the Two-Sided Geometric Distribution - PR 14890
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 ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Transonic Vision: unifying Python-Numpy accelerators
> Date: Wed, 6 Nov 2019 23:49:08 -0500 > From: Ralf Gommers > To: Discussion of Numerical Python > Subject: Re: [Numpy-discussion] Transonic Vision: unifying > Python-Numpy accelerators > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > On Mon, Nov 4, 2019 at 4:54 PM PIERRE AUGIER < > pierre.aug...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Transonic Vision: unifying Python-Numpy accelerators
On Tue, Nov 12, 2019 at 1:09 PM PIERRE AUGIER < pierre.aug...@univ-grenoble-alpes.fr> wrote: > > > Date: Wed, 6 Nov 2019 23:49:08 -0500 > > From: Ralf Gommers > > To: Discussion of Numerical Python > > Subject: Re: [Numpy-discussion] Transonic Vision: unifying > > Python-Numpy accelerators > > Message-ID: > >mw4bcoxb0h1dvu9aj...@mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > On Mon, Nov 4, 2019 at 4:54 PM PIERRE AUGIER < > > pierre.aug...@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. This is indeed interesting, I've been thinking about this a lot and have a very rough first cut at what should be included ( https://github.com/Quansight-Labs/rnumpy). That should be redone next year with a better basis for decision-making of what should and should not be in it. 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++. > Agreed. That's anyway due to sub-optimal design decisions long ago in most cases. Cheers, Ralf > If you know people potentially interested to discuss about these subjects, > please tell me. > > Cheers, > Pierre > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
