Jack Howarth wrote:
> What is the correct coding to eliminate this error? I have found some
> threads which seems to suggest that PyArray_DATA is still available in
> numpy 1.9 as an inline but I haven't found any examples of projects
> patching their code to convert to that usage.
In the deprec
On Wed, Dec 10, 2014 at 8:40 PM, Sturla Molden
wrote:
> > I haven't managed to trigger a segfault yet but it sure looks like I
> > could...
>
> You can also trigger random errors. If the array is small, Python's memory
> mamager might keep the memory in the heap for reuse by PyMem_Malloc. And
> t
On Thu, Dec 11, 2014 at 8:17 AM, Sebastian Berg
wrote:
> One option
> would also be to have something like:
>
> np.common_shape(*arrays)
> np.broadcast_to(array, shape)
> # (though I would like many arrays too)
>
> and then broadcast_ar rays could be implemented in terms of these two.
>
It looks
On 11.12.2014 19:01, Jose Guzman wrote:
> On 11/12/14 09:54, Pierre Haessig wrote:
>> The basic idea is to enable the user to select the exact range of lags
>> he wants. Unfortunately I didn't take the time to go further than the
>> specification above...
>
> I would be particularly interested in
On 11/12/14 09:54, Pierre Haessig wrote:
> The basic idea is to enable the user to select the exact range of lags
> he wants. Unfortunately I didn't take the time to go further than the
> specification above...
I would be particularly interested in computing cross-correlations in a
range of +-400
Hi,
On Monday, December 8, 2014, Pierre Haessig
wrote:
> Hi,
>
> Le 07/12/2014 08:10, Stephan Hoyer a écrit :
> > In [5]: %timeit xray.core.utils.as_shape(x, y.shape)
> > 10 loops, best of 3: 17 µs per loop
> >
> > Would this be a welcome addition to numpy's lib.stride_tricks? If so,
> > I w
On Sunday, December 7, 2014, Stephan Hoyer wrote:
> I recently wrote function to manually broadcast an ndarray to a given
> shape according to numpy's broadcasting rules (using strides):
>
> https://github.com/xray/xray/commit/7aee4a3ed2dfd3b9aff7f3c5c6c68d51df2e3ff3
>
> The same functionality ca
Using
http://nbviewer.ipython.org/url/refreweb.phys.ethz.ch/hope/notebooks/native_cpp_gen.ipynb
as an example, I have found that the error using
-DNPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION is suppressed with the
change...
--- pymol-1.7.4.0/layer0/Field.cpp.orig 2014-12-11 10:46:41.0 -0
I am trying to patch pymol to avoid the warnings...
/sw/lib/python2.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2:
warning: "Using deprecated NumPy API, disable it by " "#defining
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-W#warnings]
#warning "Using deprecated NumPy
On Thu, Dec 11, 2014 at 4:17 PM, Sebastian Berg
wrote:
>
> On Do, 2014-12-11 at 16:56 +0100, Pierre Haessig wrote:
> > Le 11/12/2014 16:52, Robert Kern a écrit :
> > >
> > > And we already have a numpy.broadcast() function.
> > >
> > >
http://docs.scipy.org/doc/numpy/reference/generated/numpy.broa
On Do, 2014-12-11 at 16:56 +0100, Pierre Haessig wrote:
> Le 11/12/2014 16:52, Robert Kern a écrit :
> >
> > And we already have a numpy.broadcast() function.
> >
> > http://docs.scipy.org/doc/numpy/reference/generated/numpy.broadcast.html
> True, I once read the docstring of this function. but nev
On Thu, Dec 11, 2014 at 4:55 PM, Robert Kern wrote:
> On Thu, Dec 11, 2014 at 3:53 PM, Eric Moore
> wrote:
> >
> > On Thu, Dec 11, 2014 at 10:41 AM, Todd wrote:
>
> >> I recently became aware of another C-library for doing FFTs (and other
> things):
> >>
> >> https://github.com/arrayfire/arrayf
Le 11/12/2014 16:52, Robert Kern a écrit :
>
> And we already have a numpy.broadcast() function.
>
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.broadcast.html
True, I once read the docstring of this function. but never used it though.
Pierre
_
On Thu, Dec 11, 2014 at 3:53 PM, Eric Moore wrote:
>
> On Thu, Dec 11, 2014 at 10:41 AM, Todd wrote:
>> I recently became aware of another C-library for doing FFTs (and other
things):
>>
>> https://github.com/arrayfire/arrayfire
>>
>> They claim to have comparable FFT performance to MKL when run
On Thu, Dec 11, 2014 at 10:41 AM, Todd wrote:
> On Tue, Oct 28, 2014 at 5:28 AM, Nathaniel Smith wrote:
>
>> On 28 Oct 2014 04:07, "Matthew Brett" wrote:
>> >
>> > Hi,
>> >
>> > On Mon, Oct 27, 2014 at 8:07 PM, Sturla Molden
>> wrote:
>> > > Sturla Molden wrote:
>> > >
>> > >> If we really ne
On Thu, Dec 11, 2014 at 2:47 PM, Nathaniel Smith wrote:
>
> On 11 Dec 2014 14:31, "Pierre Haessig" wrote:
> >
> >
> > Le 11/12/2014 01:00, Nathaniel Smith a écrit :
> > > Seems like a useful addition to me -- I've definitely wanted this in
> > > the past. I agree with Stephan that reshape() might
On Tue, Oct 28, 2014 at 5:28 AM, Nathaniel Smith wrote:
> On 28 Oct 2014 04:07, "Matthew Brett" wrote:
> >
> > Hi,
> >
> > On Mon, Oct 27, 2014 at 8:07 PM, Sturla Molden
> wrote:
> > > Sturla Molden wrote:
> > >
> > >> If we really need a
> > >> kick-ass fast FFT we need to go to libraries lik
Le 11/12/2014 15:39, Julian Taylor a écrit :
> previously numpy called dot for the convolution part, this is fine for
> large convolutions as dot goes out to BLAS which is superfast.
> For small convolutions unfortunately it is terrible as generic dot in
> BLAS libraries have enormous overheads th
On 11 Dec 2014 14:31, "Pierre Haessig" wrote:
>
>
> Le 11/12/2014 01:00, Nathaniel Smith a écrit :
> > Seems like a useful addition to me -- I've definitely wanted this in
> > the past. I agree with Stephan that reshape() might not be the best
> > place, though; I wouldn't think to look for it the
On 12/11/2014 03:24 PM, Pierre Haessig wrote:
> Le 11/12/2014 11:19, Julian Taylor a écrit :
>> Also on a side note, in 1.10 np.convolve/correlate has been
>> significantly speed up if one of the sequences is less than 12 elements
> Interesting! What is the origin of this speed up, and why a magic
Le 11/12/2014 01:00, Nathaniel Smith a écrit :
> Seems like a useful addition to me -- I've definitely wanted this in
> the past. I agree with Stephan that reshape() might not be the best
> place, though; I wouldn't think to look for it there.
>
> Two API ideas, which are not mutually exclusive:
>
Le 11/12/2014 11:19, Julian Taylor a écrit :
> Also on a side note, in 1.10 np.convolve/correlate has been
> significantly speed up if one of the sequences is less than 12 elements
Interesting! What is the origin of this speed up, and why a magic number 12?
--
Pierre
_
I think it is a good time to discuss/implement further correlate
improvements.
I kind of favor the mode=(tuple of integers) api for your proposed change.
Concerning the C-API we probably need to add a new wrapper function but
thats ok, the C-API does not need to be as nice as the python API as it
h
As a side note, I've still in mind the proposal I made back in 2013 to
make np.correlate faster
http://numpy-discussion.10968.n7.nabble.com/another-discussion-on-numpy-correlate-and-convolution-td32925.html
The basic idea is to enable the user to select the exact range of lags
he wants. Unfortu
24 matches
Mail list logo
