Re: [Numpy-discussion] Bump warning stacklevel

2016-01-27 Thread Benjamin Root
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

Re: [Numpy-discussion] Bump warning stacklevel

2016-01-27 Thread Ralf Gommers
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

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

2016-01-27 Thread Derek Homeier
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

Re: [Numpy-discussion] Building Numpy with OpenBLAS

2016-01-27 Thread Carl Kleffner
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

[Numpy-discussion] Bump warning stacklevel

2016-01-27 Thread Sebastian Berg
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:

Re: [Numpy-discussion] Bump warning stacklevel

2016-01-27 Thread Ralf Gommers
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.

Re: [Numpy-discussion] Bump warning stacklevel

2016-01-27 Thread Nathaniel Smith
+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)

Re: [Numpy-discussion] Building Numpy with OpenBLAS

2016-01-27 Thread G Young
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

Re: [Numpy-discussion] Bump warning stacklevel

2016-01-27 Thread sebastian
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(...,

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

2016-01-27 Thread Nadav Horesh
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)

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

2016-01-27 Thread Sebastian Berg
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] Building Numpy with OpenBLAS

2016-01-27 Thread G Young
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

2016-01-27 Thread Ralf Gommers
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

Re: [Numpy-discussion] Building Numpy with OpenBLAS

2016-01-27 Thread Ralf Gommers
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

Re: [Numpy-discussion] Building Numpy with OpenBLAS

2016-01-27 Thread G Young
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

Re: [Numpy-discussion] Building Numpy with OpenBLAS

2016-01-27 Thread G Young
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,

Re: [Numpy-discussion] Building Numpy with OpenBLAS

2016-01-27 Thread Michael Sarahan
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

2016-01-27 Thread G Young
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

2016-01-27 Thread Michael Sarahan
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] Building Numpy with OpenBLAS

2016-01-27 Thread Ralf Gommers
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.