> 2009/3/6 Charles R Harris :
> On Thu, Mar 5, 2009 at 10:47 PM, Scott Sinclair
> wrote:
>>
>> > 2009/3/6 Charles R Harris :
>> > I'm not receiving notifications of new/modified tickets. Anyone else
>> > having
>> > this problem? ... Chuck
>>
>> I haven't seen anything since 3rd March.
>
> That wa
On Thu, Mar 5, 2009 at 10:47 PM, Scott Sinclair wrote:
> > 2009/3/6 Charles R Harris :
> > 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 my original problem but it looks like it ha
> 2009/3/6 Charles R Harris :
> 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
Numpy-discussion@scipy.org
htt
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
On Thu, Mar 5, 2009 at 9:15 PM, Stéfan van der Walt wrote:
> Hi Robin
>
> 2009/3/5 Robin :
>> On Thu, Mar 5, 2009 at 10:57 AM, Robin wrote:
>>> On Thu, Mar 5, 2009 at 10:40 AM, Robin wrote:
Hi,
I have an indexing problem, and I know it's a bit lazy to ask the
list, sometime w
Hi Robin
2009/3/5 Robin :
> On Thu, Mar 5, 2009 at 10:57 AM, Robin wrote:
>> On Thu, Mar 5, 2009 at 10:40 AM, Robin 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!
>>
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
Numpy-discussion@scip
2009/3/5 M Trumpis :
> 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])
>
>
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 transfo
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
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 sig
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
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
> 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
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 dynam
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 dimensi
>2009/3/5 Robert Cimrman :
>
> 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
___
Numpy-discussion mailin
Kim Hansen wrote:
>> 2009/3/5 Robert Cimrman :
>> 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
>2009/3/5 Robert Cimrman :
> 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 be an honor!
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
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
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 the
On Thu, Mar 5, 2009 at 10:57 AM, Robin wrote:
> On Thu, Mar 5, 2009 at 10:40 AM, Robin 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,
On Thu, Mar 5, 2009 at 10:40 AM, Robin 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 which is s
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 compi
On Thu, Mar 5, 2009 at 10:40 AM, Robin 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 which is s
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
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], X[0,1]
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
>>
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 imposs
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 trivia
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 be
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
>> reimplemen
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 reimplemen
34 matches
Mail list logo
