2009/3/5 Francesc Alted :
> 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
>> c
Hi,
> The idea behind the current syntax was to keep things as close as
> possible to Python/NumPy, and only provide some "hints" to Cython for
> optimization. My problem with this now is that a) it's too easy to get
> non-optimized code without a warning by letting in untyped indices, b) I
> thin
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
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
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
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
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
Andrew Straw wrote:
> Dag Sverre Seljebotn wrote:
>> This is NOT yet discussed on the Cython list; I wanted to check with
>> more numerical users to see if the issue should even be brought up there.
>>
>> The idea behind the current syntax was to keep things as close as
>> possible to Python/NumP
Sturla Molden wrote:
>> arr = np.zeros(..)
>> cdef int[:,:] buf = arr # 2D buffer
>>
>> Here, buf would be something else than arr; it is a seperate view to the
>> array for low-level purposes.
>
> I like your proposal. The reason we use Fortran for numerical computing is
> that Fortran makes it e
Stéfan van der Walt wrote:
> Hi Dag
>
> 2009/3/5 Dag Sverre Seljebotn :
>> More details: http://wiki.cython.org/enhancements/buffersyntax
>
> Interesting proposal! Am I correct in thinking that you'd have to
> re-implement a lot of NumPy yourself to get this working? Or are you
> planning to bu
Hi Dag
2009/3/5 Dag Sverre Seljebotn :
> More details: http://wiki.cython.org/enhancements/buffersyntax
Interesting proposal! Am I correct in thinking that you'd have to
re-implement a lot of NumPy yourself to get this working? Or are you
planning to build on NumPy + C-API?
Cheers
Stéfan
_
> arr = np.zeros(..)
> cdef int[:,:] buf = arr # 2D buffer
>
> Here, buf would be something else than arr; it is a seperate view to the
> array for low-level purposes.
I like your proposal. The reason we use Fortran for numerical computing is
that Fortran makes it easy to manipulate arrays. C or
Dag Sverre Seljebotn wrote:
> This is NOT yet discussed on the Cython list; I wanted to check with
> more numerical users to see if the issue should even be brought up there.
>
> The idea behind the current syntax was to keep things as close as
> possible to Python/NumPy, and only provide some "
22 matches
Mail list logo
