Re: [Numpy-discussion] Bump warning stacklevel

I like the idea of bumping the stacklevel in principle, but I am not sure it is all that practical. For example, if a warning came up when doing "x / y", I am assuming that it is emitted from within the ufunc np.divide(). So, you would need two stacklevels based on whether the entry point was the o

Re: [Numpy-discussion] Bump warning stacklevel

On Wed, Jan 27, 2016 at 11:02 PM, sebastian wrote: > On 2016-01-27 21:01, Ralf Gommers wrote: > >> >> One issue will be how to keep this consistent. `stacklevel` is used so >> rarely that new PRs will always omit it for new warnings. Will we just >> rely on code review, or would a private wrapper

Re: [Numpy-discussion] Bump warning stacklevel

On 2016-01-27 21:01, Ralf Gommers wrote: On Wed, Jan 27, 2016 at 7:26 PM, Sebastian Berg wrote: Hi all, in my PR about warnings suppression, I currently also have a commit which bumps the warning stacklevel to two (or three), i.e. use: warnings.warn(..., stacklevel=2) (almost) everywhere. T

Re: [Numpy-discussion] Building Numpy with OpenBLAS

That's great! I look forward to seeing that. Greg On Wed, Jan 27, 2016 at 6:27 PM, Carl Kleffner wrote: > In my timeplan the next mingwpy PR on numpy master is anticipated to take > place at the weekend, together with a build description. This PR is > targeted to build numpy with OpenBLAS. > >

Re: [Numpy-discussion] Bump warning stacklevel

+1 On Wed, Jan 27, 2016 at 10:26 AM, Sebastian Berg wrote: > Hi all, > > in my PR about warnings suppression, I currently also have a commit > which bumps the warning stacklevel to two (or three), i.e. use: > > warnings.warn(..., stacklevel=2) > > (almost) everywhere. This means that for example

Re: [Numpy-discussion] Bump warning stacklevel

On Wed, Jan 27, 2016 at 7:26 PM, Sebastian Berg wrote: > Hi all, > > in my PR about warnings suppression, I currently also have a commit > which bumps the warning stacklevel to two (or three), i.e. use: > > warnings.warn(..., stacklevel=2) > > (almost) everywhere. This means that for example (tak

Re: [Numpy-discussion] Building Numpy with OpenBLAS

In my timeplan the next mingwpy PR on numpy master is anticipated to take place at the weekend, together with a build description. This PR is targeted to build numpy with OpenBLAS. Carl 2016-01-27 16:01 GMT+01:00 Ralf Gommers : > > > On Wed, Jan 27, 2016 at 3:51 PM, G Young wrote: > >> I don't

[Numpy-discussion] Bump warning stacklevel

Hi all, in my PR about warnings suppression, I currently also have a commit which bumps the warning stacklevel to two (or three), i.e. use: warnings.warn(..., stacklevel=2) (almost) everywhere. This means that for example (take only the empty warning): np.mean([]) would not print: /usr/lib/py

Re: [Numpy-discussion] [SciPy-Dev] Numpy 1.11.0b1 is out

On 27 Jan 2016, at 2:58 AM, Charles R Harris wrote: > > FWIW, the maintenance/1.11.x branch (there is no tag for the beta?) builds > and passes all tests with Python 2.7.11 > and 3.5.1 on Mac OS X 10.10. > > > You probably didn't fetch the tags, if they can't be reached from the branch > hea

Re: [Numpy-discussion] Building Numpy with OpenBLAS

On Wed, Jan 27, 2016 at 3:51 PM, G Young wrote: > I don't need it at this point. I'm just going through the exercise for > purposes of updating building from source on Windows. But that's good to > know though. Thanks! > That effort is much appreciated by the way. Updating the build info on a

Re: [Numpy-discussion] Building Numpy with OpenBLAS

I don't need it at this point. I'm just going through the exercise for purposes of updating building from source on Windows. But that's good to know though. Thanks! Greg On Wed, Jan 27, 2016 at 2:48 PM, Ralf Gommers wrote: > > > On Wed, Jan 27, 2016 at 3:19 PM, G Young wrote: > >> NumPy wil

Re: [Numpy-discussion] Building Numpy with OpenBLAS

On Wed, Jan 27, 2016 at 3:19 PM, G Young wrote: > NumPy will "build" successfully, but then when I type "import numpy", it > cannot import the multiarray PYD file. > > I am using dependency walker, and that's how I know it's the > libopenblas.dll file that it's not linking to properly, hence my o

Re: [Numpy-discussion] Building Numpy with OpenBLAS

NumPy will "build" successfully, but then when I type "import numpy", it cannot import the multiarray PYD file. I am using dependency walker, and that's how I know it's the libopenblas.dll file that it's not linking to properly, hence my original question. Greg On Wed, Jan 27, 2016 at 1:58 PM, M

Re: [Numpy-discussion] Building Numpy with OpenBLAS

When you say find/use, can you please clarify whether you have completed the compilation/linking successfully? I'm not clear on exactly when you're having problems. What is the error output? One very helpful tool in diagnosing dll problems is dependency walker: http://www.dependencywalker.com/

Re: [Numpy-discussion] Building Numpy with OpenBLAS

I do have my site.cfg file pointing to my library which contains a .lib file along with the appropriate include_dirs parameter. However, NumPy can't seem to find / use the DLL file no matter where I put it (numpy/core, same directory as openblas.lib). By the way, I should mention that I am using

Re: [Numpy-discussion] Building Numpy with OpenBLAS

I'm not sure about the mingw tool chain, but usually on windows at link time you need a .lib file, called the import library. The .dll is used at runtime, not at link time. This is different from *nix, where the .so serves both purposes. The link you posted mentions import files, so I hope this

Re: [Numpy-discussion] Numpy 1.11.0b1 is out

On Mi, 2016-01-27 at 11:19 +, Nadav Horesh wrote: > Why the dot function/method is slower than @ on python 3.5.1? Tested > from the latest 1.11 maintenance branch. > The explanation I think is that you do not have a blas optimization. In which case the fallback mode is probably faster in the

Re: [Numpy-discussion] Numpy 1.11.0b1 is out

Why the dot function/method is slower than @ on python 3.5.1? Tested from the latest 1.11 maintenance branch. np.__version__ Out[39]: '1.11.0.dev0+Unknown' %timeit A @ c 1 loops, best of 3: 185 µs per loop %timeit A.dot(c) 1000 loops, best of 3: 526 µs per loop %timeit np.dot(A,c) 100

Re: [Numpy-discussion] Building Numpy with OpenBLAS

Hello all, I'm trying to update the documentation for building Numpy from source, and I've hit a brick wall in trying to build the library using OpenBLAS because I can't seem to link the libopenblas.dll file. I tried following the suggestion of placing the DLL in numpy/core as suggested here

Re: [Numpy-discussion] [SciPy-Dev] Numpy 1.11.0b1 is out

On Wed, Jan 27, 2016 at 4:47 AM, Charles R Harris wrote: > > > On Tue, Jan 26, 2016 at 7:45 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Tue, Jan 26, 2016 at 7:13 PM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> >>> >>> On Tue, Jan 26, 2016 at 6:58 PM