Matthew Brett wrote:
> Hi,
>
>> The feature of compiling code for multiple types is somewhat orthogonal
>> to
>> ndarray support; better treat them seperately and take one at the time.
>
> Well, it's relevant to numpy because if you want to implement - for
> example - a numpy sort, then you've got
On Sat, Jun 21, 2008 at 18:45, Anne Archibald <[EMAIL PROTECTED]> wrote:
> 2008/6/21 Robert Kern <[EMAIL PROTECTED]>:
>> On Sat, Jun 21, 2008 at 17:08, Anne Archibald <[EMAIL PROTECTED]> wrote:
>>> My suggestion is this: allow negative indices, accepting the cost in
>>> tight loops. (If bounds chec
2008/6/21 Robert Kern <[EMAIL PROTECTED]>:
> On Sat, Jun 21, 2008 at 17:08, Anne Archibald <[EMAIL PROTECTED]> wrote:
>> My suggestion is this: allow negative indices, accepting the cost in
>> tight loops. (If bounds checking is enabled, the cost will be
>> negligible anyway.) Provide a #pragma all
On Sat, Jun 21, 2008 at 17:08, Anne Archibald <[EMAIL PROTECTED]> wrote:
> My suggestion is this: allow negative indices, accepting the cost in
> tight loops. (If bounds checking is enabled, the cost will be
> negligible anyway.) Provide a #pragma allowing the user to assert that
> a certain piece
Hi,
> The feature of compiling code for multiple types is somewhat orthogonal to
> ndarray support; better treat them seperately and take one at the time.
Well, it's relevant to numpy because if you want to implement - for
example - a numpy sort, then you've got to deal with an unspecified
number
Matthew Brett wrote:
> Hi,
>
>> Well... the Cython compiler definitely needs to know about which type it
>> is -- the array simply has a byte buffer, and one needs to know how to
>> interpret that (how many bytes per element etc.).
>
> It may be not practical, and, as I say, I haven't thought deepl
> I am very worried about the negative numbers issue. It's the sort of
> thing that will readily lead to errors, and that produces a
> significant difference between cython and python. I understand the
> performance issues that motivate it, but cython really needs to be
> easy to use or we might as
Anne Archibald wrote:
> 2008/6/21 Dag Sverre Seljebotn <[EMAIL PROTECTED]>:
>> Dag wrote:
>>> General feedback is welcome; in particular, I need more opinions about
>>> what syntax people would like. We seem unable to find something that we
>>> really like; this is the current best candidate (cdef
2008/6/21 Dag Sverre Seljebotn <[EMAIL PROTECTED]>:
> Dag wrote:
>> General feedback is welcome; in particular, I need more opinions about
>> what syntax people would like. We seem unable to find something that we
>> really like; this is the current best candidate (cdef is the way you
>> declare ty
Hi,
> Well... the Cython compiler definitely needs to know about which type it
> is -- the array simply has a byte buffer, and one needs to know how to
> interpret that (how many bytes per element etc.).
It may be not practical, and, as I say, I haven't thought deeply
enough about this to offer t
Hi Dag
2008/6/21 Dag Sverre Seljebotn <[EMAIL PROTECTED]>:
> However, I could make it so that if you left out the type, it would be
> auto-detected. I.e.:
>
> cdef np.ndarray[2] arr = ...
> cdef np.float64 x = arr[3,4]
Would it not be possible for Cython to make the necessary C-API calls
to query
Fernando Perez wrote:
> On Fri, Jun 20, 2008 at 11:50 PM, Dag Sverre Seljebotn
> <[EMAIL PROTECTED]> wrote:
>> Since there's been a lot of Cython discussion lately I thought I'd speak
>> up and start a thread specifically for my project.
>
> Thanks for coming over for the discussion!
>
>> The code
Joris De Ridder wrote:
> Hi Dag,
>
>> General feedback is welcome; in particular, I need more opinions about
>> what syntax people would like. We seem unable to find something that
>> we
>> really like; this is the current best candidate (cdef is the way you
>> declare types on variables in Cython)
On Fri, Jun 20, 2008 at 11:50 PM, Dag Sverre Seljebotn
<[EMAIL PROTECTED]> wrote:
> Since there's been a lot of Cython discussion lately I thought I'd speak
> up and start a thread specifically for my project.
Thanks for coming over for the discussion!
> The code above the under the hood acquires
Matthew Brett wrote:
> Hi,
>
> Thanks a lot for the email - it's an exciting project.
>
>> cdef int i = 4, j = 6
>> cdef np.ndarray[np.float64, 2] arr = np.zeros((10, 10),
>> dtype=np.float64)
>> arr[i, j] = 1
>
> I'm afraid I'm going to pitch into an area I'm ignorant of, and I'm
> sorry for that,
Hi,
Thanks a lot for the email - it's an exciting project.
> cdef int i = 4, j = 6
> cdef np.ndarray[np.float64, 2] arr = np.zeros((10, 10), dtype=np.float64)
> arr[i, j] = 1
I'm afraid I'm going to pitch into an area I'm ignorant of, and I'm
sorry for that, but do you think there is any way of
On Sat, Jun 21, 2008 at 08:59:25AM +0200, Dag Sverre Seljebotn wrote:
> The negative indices thing is potentially confusing to new users. Pex uses
> a different syntax (arr{i, j} for efficient array lookups) partly to make
> this fact very explicit. Thoughts?
I don't like the different syntax. I w
Hi Dag,
> General feedback is welcome; in particular, I need more opinions about
> what syntax people would like. We seem unable to find something that
> we
> really like; this is the current best candidate (cdef is the way you
> declare types on variables in Cython):
>
> cdef int i = 4, j = 6
>
Dag wrote:
> General feedback is welcome; in particular, I need more opinions about
> what syntax people would like. We seem unable to find something that we
> really like; this is the current best candidate (cdef is the way you
> declare types on variables in Cython):
>
> cdef int i = 4, j = 6
> c
Since there's been a lot of Cython discussion lately I thought I'd speak
up and start a thread specifically for my project.
We've just recently set a clear direction for my Google Summer of Code
project for integrating NumPy in a better way with Cython. What we ended
up with is that I will over th
20 matches
Mail list logo
