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 "
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 "hints" to Cython for
optimization. My
23 matches
Mail list logo
