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
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
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
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
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:
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.
+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)
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
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(...,
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)
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
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
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
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
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
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,
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/
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
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
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.
20 matches
Mail list logo