A Thursday 05 March 2009, Dag Sverre Seljebotn escrigué:
But yes, to implement that one would need to reimplement parts of
NumPy to get it working. But because code would be generated
specifically for the situation inline, I think it would be more like
reimplementing Numexpr than
Francesc Alted wrote:
A Thursday 05 March 2009, Dag Sverre Seljebotn escrigué:
But yes, to implement that one would need to reimplement parts of
NumPy to get it working. But because code would be generated
specifically for the situation inline, I think it would be more like
reimplementing
A Thursday 05 March 2009, Dag Sverre Seljebotn escrigué:
At first sight, having a kind of Numexpr kernel inside Cython would
be great, but provided that you can already call Numexpr from both
Python/Cython, I wonder which would be the advantage to do so. As
I see it, it would be better to
A Thursday 05 March 2009, Francesc Alted escrigué:
Well, I suppose that, provided that Cython could perform the for-loop
transformation, giving support for strided arrays would be relatively
trivial, and the performance would be similar than numexpr in this
case.
Mmh, perhaps not so trivial,
On 3/5/2009 8:51 AM, Dag Sverre Seljebotn wrote:
What's your take on Blitz++? Around here when you say C++ and numerical
in the same sentence, Blitz++ is what they mean.
I have not looked at it for a long time (8 years or so). It is based on
profane C++ templates that makes debugging
Francesc Alted wrote:
A Thursday 05 March 2009, Francesc Alted escrigué:
Well, I suppose that, provided that Cython could perform the for-loop
transformation, giving support for strided arrays would be relatively
trivial, and the performance would be similar than numexpr in this
case.
Hi,
I have an indexing problem, and I know it's a bit lazy to ask the
list, sometime when people do interesting tricks come up so I hope no
one minds!
I have a 2D array X.shape = (a,b)
and I want to change it into new array which is shape (2,(a*b)) which
has the following form:
[ X[0,0],
Sturla Molden wrote:
Introducing this syntax would actually mean less time to focus on real
usability issues like that. OTOH, if the syntax I propose is superior,
it's better to introduce it early in a long-term perspective.
There is not much difference between
cdef int[:,:]
On Thu, Mar 5, 2009 at 10:40 AM, Robin robi...@gmail.com wrote:
Hi,
I have an indexing problem, and I know it's a bit lazy to ask the
list, sometime when people do interesting tricks come up so I hope no
one minds!
I have a 2D array X.shape = (a,b)
and I want to change it into new array
On 3/5/2009 10:11 AM, Dag Sverre Seljebotn wrote:
Cython can relatively easily transform things like
cdef int[:,:] a = ..., b = ...
c = a + b * b
Now you are wandering far into Fortran territory...
If a and b are declared as contiguous arrays and restrict, I suppose
the C compiler
On Thu, Mar 5, 2009 at 10:40 AM, Robin robi...@gmail.com wrote:
Hi,
I have an indexing problem, and I know it's a bit lazy to ask the
list, sometime when people do interesting tricks come up so I hope no
one minds!
I have a 2D array X.shape = (a,b)
and I want to change it into new array
On Thu, Mar 5, 2009 at 10:57 AM, Robin robi...@gmail.com wrote:
On Thu, Mar 5, 2009 at 10:40 AM, Robin robi...@gmail.com wrote:
Hi,
I have an indexing problem, and I know it's a bit lazy to ask the
list, sometime when people do interesting tricks come up so I hope no
one minds!
I have a 2D
Hi again
It turned out not to be quite good enough as is, as it requires unique
values for both arrays. Whereas this is often true for the second
argument, it is never true for the first argument in my use case, and
I struggled with that for some time until i realized I could use
unique1d with
Kim Hansen wrote:
Hi again
It turned out not to be quite good enough as is, as it requires unique
values for both arrays. Whereas this is often true for the second
argument, it is never true for the first argument in my use case, and
I struggled with that for some time until i realized I
A Thursday 05 March 2009, Dag Sverre Seljebotn escrigué:
No, one could do the same thing that NumPy does (I think, never
looked into it in detail), i.e:
decide on dimension to do innermost dynamically from strides and
sizes save the stride in that dimension for each array
for loop using
2009/3/5 Robert Cimrman cimrm...@ntc.zcu.cz:
I have added your implementation to
http://projects.scipy.org/numpy/ticket/1036 - is it ok with you to add
the function eventually into arraysetops.py, under the numpy (BSD) license?
cheers,
r.
Yes, that would be fine with me. In fact that would
Kim Hansen wrote:
2009/3/5 Robert Cimrman cimrm...@ntc.zcu.cz:
I have added your implementation to
http://projects.scipy.org/numpy/ticket/1036 - is it ok with you to add
the function eventually into arraysetops.py, under the numpy (BSD) license?
cheers,
r.
Yes, that would be fine with me.
2009/3/5 Robert Cimrman cimrm...@ntc.zcu.cz:
Great! It's a nice use case for return_inverse=True in unique1d().
I have fixed the formatting, but cannot remove the previous comment.
r.
;-)
Thank you for fixing the formatting,
--Kim
___
Francesc Alted wrote:
A Thursday 05 March 2009, Dag Sverre Seljebotn escrigué:
No, one could do the same thing that NumPy does (I think, never
looked into it in detail), i.e:
decide on dimension to do innermost dynamically from strides and
sizes save the stride in that dimension for each
A Thursday 05 March 2009, Dag Sverre Seljebotn escrigué:
Francesc Alted wrote:
A Thursday 05 March 2009, Dag Sverre Seljebotn escrigué:
No, one could do the same thing that NumPy does (I think, never
looked into it in detail), i.e:
decide on dimension to do innermost dynamically from
A Thursday 05 March 2009, Dag Sverre Seljebotn escrigué:
Good point. I was not aware of this subtlity. In fact, numexpr does
not get well with transposed views of NumPy arrays. Filed the bug in:
http://code.google.com/p/numexpr/issues/detail?id=18
Not sure whether it is possible with
Sturla Molden wrote:
The justification for Fortran ordering is in the mathematics. Say we have
a set of linear equations
A * X = B
and are going to solve for X, using some magical subroutine 'solve'. The
most efficient way to store these arrays becomes the Fortran ordering.
That is,
A Thursday 05 March 2009, David Cournapeau escrigué:
I don't understand your argument about Row vs Column matters: which
one is best depends on your linear algebra equations. You give an
example where Fortran is better, but I can find example where C order
will be more appropriate. Most of the
I apology for this off topic question:
I have a 2D FT of size N x N, and I would like to reconstruct the original
signal with a lower sampling frequency directly (without using an interpolation
procedure): Given M N the goal is to compute a M x M time domain signal.
In the case of 1D
It looks like the new system is failing to mail svn commit notifications...
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi Nadav.. if you want a lower resolution 2d function with the same
field of view (or whatever term is appropriate to your case), then in
principle you can truncate your higher frequencies and do this:
sig = ifft2_func(sig[N/2 - M/2:N/2 + M/2, N/2 - M/2:N/2+M/2])
I like to use an fft that
2009/3/5 M Trumpis mtrum...@berkeley.edu:
Hi Nadav.. if you want a lower resolution 2d function with the same
field of view (or whatever term is appropriate to your case), then in
principle you can truncate your higher frequencies and do this:
sig = ifft2_func(sig[N/2 - M/2:N/2 + M/2, N/2 -
On Mar 5, 2009, at 1:16 PM, Charles R Harris wrote:
It looks like the new system is failing to mail svn commit
notifications... Chuck
Thanks for the heads up; it should be fixed now.
-Peter
___
Numpy-discussion mailing list
On Thu, Mar 5, 2009 at 9:15 PM, Stéfan van der Walt ste...@sun.ac.za wrote:
Hi Robin
2009/3/5 Robin robi...@gmail.com:
On Thu, Mar 5, 2009 at 10:57 AM, Robin robi...@gmail.com wrote:
On Thu, Mar 5, 2009 at 10:40 AM, Robin robi...@gmail.com wrote:
Hi,
I have an indexing problem, and I know
I'm not receiving notifications of new/modified tickets. Anyone else having
this problem? ... Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
2009/3/6 Charles R Harris charlesr.har...@gmail.com:
I'm not receiving notifications of new/modified tickets. Anyone else having
this problem? ... Chuck
I haven't seen anything since 3rd March.
Cheers,
Scott
___
Numpy-discussion mailing list
On Thu, Mar 5, 2009 at 10:47 PM, Scott Sinclair scott.sinclair...@gmail.com
wrote:
2009/3/6 Charles R Harris charlesr.har...@gmail.com:
I'm not receiving notifications of new/modified tickets. Anyone else
having
this problem? ... Chuck
I haven't seen anything since 3rd March.
That was
2009/3/6 Charles R Harris charlesr.har...@gmail.com:
On Thu, Mar 5, 2009 at 10:47 PM, Scott Sinclair
scott.sinclair...@gmail.com wrote:
2009/3/6 Charles R Harris charlesr.har...@gmail.com:
I'm not receiving notifications of new/modified tickets. Anyone else
having
this problem? ...
33 matches
Mail list logo
