Thanks for comments, I've fixed the named issues.
Code is python2&3 compatible, I aliased numpy and used better inversion.
Specially thanks for pointing at histogram equalization - I've added
example for images.
Probably some other 'visual' examples would help - I'll try to invent
something to
On Tue, Oct 6, 2015 at 1:04 PM, Nathaniel Smith wrote:
> On Tue, Oct 6, 2015 at 11:52 AM, David Cournapeau
> wrote:
> >
> >
> > On Tue, Oct 6, 2015 at 7:30 PM, Nathaniel Smith wrote:
> >>
> >> [splitting this off into a new thread]
> >>
> >> On Tue, Oct 6, 2015 at 3:00 AM, David Cournapeau
> >
On Tue, Oct 6, 2015 at 11:52 AM, David Cournapeau wrote:
>
>
> On Tue, Oct 6, 2015 at 7:30 PM, Nathaniel Smith wrote:
>>
>> [splitting this off into a new thread]
>>
>> On Tue, Oct 6, 2015 at 3:00 AM, David Cournapeau
>> wrote:
>> [...]
>> > I also agree the current situation is not sustainable
On Tue, Oct 6, 2015 at 7:30 PM, Nathaniel Smith wrote:
> [splitting this off into a new thread]
>
> On Tue, Oct 6, 2015 at 3:00 AM, David Cournapeau
> wrote:
> [...]
> > I also agree the current situation is not sustainable -- as we discussed
> > privately before, cythonizing numpy.core is made
[splitting this off into a new thread]
On Tue, Oct 6, 2015 at 3:00 AM, David Cournapeau wrote:
[...]
> I also agree the current situation is not sustainable -- as we discussed
> privately before, cythonizing numpy.core is made quite more complicated by
> this. I have myself quite a few issues w/
On Tue, Oct 6, 2015 at 6:18 PM, David Cournapeau wrote:
>
>
> On Tue, Oct 6, 2015 at 6:14 PM, Nathaniel Smith wrote:
>
>> On Tue, Oct 6, 2015 at 10:10 AM, David Cournapeau
>> wrote:
>> >
>> >
>> > On Tue, Oct 6, 2015 at 6:07 PM, Nathaniel Smith wrote:
>> >>
>> >> On Tue, Oct 6, 2015 at 10:00 A
On Tue, 6 Oct 2015 10:07:13 -0700
Nathaniel Smith wrote:
>
> And how are you getting at them? Are you just relying the way that on
> ELF systems, if two libraries are loaded into the same address space
> then they automatically get access to each other's symbols, even if
> they aren't linked to e
On Tue, Oct 6, 2015 at 6:14 PM, Nathaniel Smith wrote:
> On Tue, Oct 6, 2015 at 10:10 AM, David Cournapeau
> wrote:
> >
> >
> > On Tue, Oct 6, 2015 at 6:07 PM, Nathaniel Smith wrote:
> >>
> >> On Tue, Oct 6, 2015 at 10:00 AM, Antoine Pitrou
> >> wrote:
> >> > On Tue, 6 Oct 2015 09:40:43 -0700
On Tue, Oct 6, 2015 at 10:10 AM, David Cournapeau wrote:
>
>
> On Tue, Oct 6, 2015 at 6:07 PM, Nathaniel Smith wrote:
>>
>> On Tue, Oct 6, 2015 at 10:00 AM, Antoine Pitrou
>> wrote:
>> > On Tue, 6 Oct 2015 09:40:43 -0700
>> > Nathaniel Smith wrote:
>> >>
>> >> If you need some npy_* function it
On Tue, Oct 6, 2015 at 6:07 PM, Nathaniel Smith wrote:
> On Tue, Oct 6, 2015 at 10:00 AM, Antoine Pitrou
> wrote:
> > On Tue, 6 Oct 2015 09:40:43 -0700
> > Nathaniel Smith wrote:
> >>
> >> If you need some npy_* function it'd be much better to let us know
> >> what it is and let us export it in
On Tue, Oct 6, 2015 at 9:51 AM, David Cournapeau wrote:
>
> On Tue, Oct 6, 2015 at 5:44 PM, Nathaniel Smith wrote:
>>
>> On Tue, Oct 6, 2015 at 4:46 AM, David Cournapeau
>> wrote:
>> > The npy_ functions in npymath were designed to be exported. Those would
>> > stay
>> > that way.
>>
>> If we wa
On Tue, Oct 6, 2015 at 5:58 PM, Nathaniel Smith wrote:
> On Tue, Oct 6, 2015 at 9:51 AM, David Cournapeau
> wrote:
> >
> > On Tue, Oct 6, 2015 at 5:44 PM, Nathaniel Smith wrote:
> >>
> >> On Tue, Oct 6, 2015 at 4:46 AM, David Cournapeau
> >> wrote:
> >> > The npy_ functions in npymath were des
On Tue, Oct 6, 2015 at 10:00 AM, Antoine Pitrou wrote:
> On Tue, 6 Oct 2015 09:40:43 -0700
> Nathaniel Smith wrote:
>>
>> If you need some npy_* function it'd be much better to let us know
>> what it is and let us export it in an intentional way, instead of just
>> relying on whatever stuff we ac
On Tue, 6 Oct 2015 09:40:43 -0700
Nathaniel Smith wrote:
>
> If you need some npy_* function it'd be much better to let us know
> what it is and let us export it in an intentional way, instead of just
> relying on whatever stuff we accidentally exposed?
Ok, we seem to be using only the complex m
On Tue, Oct 6, 2015 at 9:51 AM, David Cournapeau wrote:
>
> On Tue, Oct 6, 2015 at 5:44 PM, Nathaniel Smith wrote:
>>
>> On Tue, Oct 6, 2015 at 4:46 AM, David Cournapeau
>> wrote:
>> > The npy_ functions in npymath were designed to be exported. Those would
>> > stay
>> > that way.
>>
>> If we wa
On Tue, Oct 6, 2015 at 5:51 PM, David Cournapeau wrote:
>
>
> On Tue, Oct 6, 2015 at 5:44 PM, Nathaniel Smith wrote:
>
>> On Tue, Oct 6, 2015 at 4:46 AM, David Cournapeau
>> wrote:
>> > The npy_ functions in npymath were designed to be exported. Those would
>> stay
>> > that way.
>>
>> If we wa
On Tue, Oct 6, 2015 at 5:44 PM, Nathaniel Smith wrote:
> On Tue, Oct 6, 2015 at 4:46 AM, David Cournapeau
> wrote:
> > The npy_ functions in npymath were designed to be exported. Those would
> stay
> > that way.
>
> If we want to export these then I vote that we either:
> - use the usual API exp
On Tue, Oct 6, 2015 at 4:07 AM, Antoine Pitrou wrote:
> On Tue, 6 Oct 2015 11:00:30 +0100
> David Cournapeau wrote:
>>
>> Assuming one of the rumour is related to some comments I made some time
>> (years ?) earlier, the context was the ability to hide exported symbols. As
>> you know, the issue i
On Tue, Oct 6, 2015 at 4:46 AM, David Cournapeau wrote:
> The npy_ functions in npymath were designed to be exported. Those would stay
> that way.
If we want to export these then I vote that we either:
- use the usual API export mechanism, or else
- provide a static library for people to link to,
Sebastian Berg wrote:
> On Di, 2015-10-06 at 07:53 -0400, Neal Becker wrote:
>> 1 test failure:
>>
>> FAIL: test_blasdot.test_blasdot_used
>> --
>> Traceback (most recent call last):
>> File "/usr/lib/python2.7/site-packages/no
I don't get any failures on Fedora 22. I have installed it with pip,
setting my CFLAGS to "-march=core-avx-i -O2 -pipe -mtune=native" and
linking against openblas.
With the new Numpy, Scipy full suite shows two errors, I am sorry I didn't
think of running that in the RC phase:
===
On Di, 2015-10-06 at 07:53 -0400, Neal Becker wrote:
> 1 test failure:
>
> FAIL: test_blasdot.test_blasdot_used
> --
> Traceback (most recent call last):
> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTe
1 test failure:
FAIL: test_blasdot.test_blasdot_used
--
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
File "/home/nbecker/.local/lib/pyth
On Tue, Oct 6, 2015 at 12:07 PM, Antoine Pitrou wrote:
> On Tue, 6 Oct 2015 11:00:30 +0100
> David Cournapeau wrote:
> >
> > Assuming one of the rumour is related to some comments I made some time
> > (years ?) earlier, the context was the ability to hide exported symbols.
> As
> > you know, the
Are extra_compile_args actually used in all compile steps?
I set:
extra_compile_args = -march=native -O3
On some compile steps, it echos:
compile options: '-DHAVE_CBLAS -Inumpy/core/include -Ibuild/src.linux-
x86_64-2.7/numpy/core/include/numpy -Inumpy/core/src/private -
Inumpy/core/src -Inumpy/c
lots of warning with openblas
python setup.py build
Running from numpy source directory.
/usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown
distribution option: 'test_suite'
warnings.warn(msg)
blas_opt_info:
blas_mkl_info:
libraries mkl,vml,guide not found in ['/usr/local/lib64
On Tue, 6 Oct 2015 11:00:30 +0100
David Cournapeau wrote:
>
> Assuming one of the rumour is related to some comments I made some time
> (years ?) earlier, the context was the ability to hide exported symbols. As
> you know, the issue is not to build extensions w/ multiple compilation
> units, but
Hi all,
Thanks Jon and Ryan for the suggestions. Both asanyarray() or
atleast_1d() sound good.
There's the technical detail that Cython needs to know the object type
(e.g. in the parameters to quartic_z_array()), so I think atleast_1d()
may be safer. I've taken this option for now.
This si
On Mon, Oct 5, 2015 at 11:26 PM, Nathaniel Smith wrote:
> Hi all,
>
> For a long time, NumPy has supported two different ways of being compiled:
>
> "Separate compilation" mode: like most C projects, each .c file gets
> compiled to a .o file, and then the .o files get linked together to
> make a
On Tue, Oct 6, 2015 at 1:14 AM, Daπid wrote:
> One idea: what about creating a "parallel numpy"? There are a few
> algorithms that can benefit from parallelisation. This library would mimic
> Numpy's signature, and the user would be responsible for choosing the
> single threaded or the parallel o
On 30 September 2015 at 18:20, Nathaniel Smith wrote:
> - parallel code in general is not very composable. If someone is calling a
> numpy operation from one thread, great, transparently using multiple
> threads internally is a win. If they're exploiting some higher-level
> structure in their pro
31 matches
Mail list logo