Zaur Shibzukhov, 01.03.2013 08:37:
> unicode_slice.h
> -
>
> #include "unicodeobject.h"
>
> static inline PyObject* unicode_slice(
> PyObject* text, Py_ssize_t start, Py_ssize_t stop);
>
> /// PyUnicode_Substring ///
>
> /* CURRENT */
>
>
2013/3/1 ZS :
> 2013/3/1 Stefan Behnel :
>> ZS, 28.02.2013 21:07:
>>> 2013/2/28 Stefan Behnel:
> This allows to write unicode text parsing code almost at C speed
> mostly in python (+ .pxd defintions).
I suggest simply adding a constant flag argument to the existing function
On Thu, Feb 28, 2013 at 11:12 AM, Nathaniel Smith wrote:
> On Thu, Feb 28, 2013 at 5:50 PM, Robert Bradshaw wrote:
>> On Thu, Feb 28, 2013 at 7:13 AM, Sebastian Berg
>> wrote:
>>> Hey,
>>>
>>> Maybe someone here already saw it (I don't have a track account, or I
>>> would just create a ticket),
>>>
>>> I think you could even pass in two flags, one for wraparound and one for
>>> boundscheck, and then just evaluate them appropriately in the existing "if"
>>> tests above. That should allow both features to be supported independently
>>> in a fast way.
>>>
>> Intresting, could C compilers in
ZS, 01.03.2013 07:43:
> 2013/3/1 Stefan Behnel:
>> ZS, 28.02.2013 21:07:
>>> 2013/2/28 Stefan Behnel:
> This allows to write unicode text parsing code almost at C speed
> mostly in python (+ .pxd defintions).
I suggest simply adding a constant flag argument to the existing functio
2013/3/1 Stefan Behnel :
> ZS, 28.02.2013 21:07:
>> 2013/2/28 Stefan Behnel:
This allows to write unicode text parsing code almost at C speed
mostly in python (+ .pxd defintions).
>>>
>>> I suggest simply adding a constant flag argument to the existing function
>>> that states if checking
2013/3/1 Stefan Behnel :
> ZS, 28.02.2013 21:07:
>> 2013/2/28 Stefan Behnel:
This allows to write unicode text parsing code almost at C speed
mostly in python (+ .pxd defintions).
>>>
>>> I suggest simply adding a constant flag argument to the existing function
>>> that states if checking
ZS, 28.02.2013 21:07:
> 2013/2/28 Stefan Behnel:
>>> This allows to write unicode text parsing code almost at C speed
>>> mostly in python (+ .pxd defintions).
>>
>> I suggest simply adding a constant flag argument to the existing function
>> that states if checking should be done or not. Inlining
2013/2/28 Stefan Behnel :
>> This allows to write unicode text parsing code almost at C speed
>> mostly in python (+ .pxd defintions).
>
> I suggest simply adding a constant flag argument to the existing function
> that states if checking should be done or not. Inlining will let the C
> compiler dr
ZS, 28.02.2013 19:31:
> 2013/2/28 ZS:
>> Looking into IndexNode class in ExprNode.py I have seen a possibility
>> for addition of more fast code path for unicode[index] as it done in
>> method `generate_setitem_code` in case of lists.
>>
>> This is files for evaluation of performance difference:
>
On Thu, Feb 28, 2013 at 5:50 PM, Robert Bradshaw wrote:
> On Thu, Feb 28, 2013 at 7:13 AM, Sebastian Berg
> wrote:
>> Hey,
>>
>> Maybe someone here already saw it (I don't have a track account, or I
>> would just create a ticket), but it would be nice if Cython was more
>> forgiving about contigu
Hey Yury:
Yes, you are right. I was thinking this was a function and not a method.
As an even ickier workaround:
#define TokenStack_top_p(token_stack) &token_stack->top()
cdef extern from "":
Token* TokenStack_top_p(TokenStack*) except +
cdef Token* tok = TokenStack_top_p(sel
2013/2/28 ZS :
> Looking into IndexNode class in ExprNode.py I have seen a possibility
> for addition of more fast code path for unicode[index] as it done in
> method `generate_setitem_code` in case of lists.
>
> This is files for evaluation of performance difference:
>
> unicode_index.h
>
>
Hi Brad,
On Thu, 2013-02-28 at 08:01 -0800, Bradley M. Froehle wrote:
>
> cdef extern from "test.h":
> int* foo2ptr "&foo" ()
>
> cdef int *x = foo2ptr()
Thank you for this interesting suggestion, but I must be missing
something, because when I do the following:
cdef extern from "token
On Thu, Feb 28, 2013 at 7:13 AM, Sebastian Berg
wrote:
> Hey,
>
> Maybe someone here already saw it (I don't have a track account, or I
> would just create a ticket), but it would be nice if Cython was more
> forgiving about contiguous requirements on strides. In the future this
> would make it ea
On Thu, Feb 28, 2013 at 4:58 AM, Yury V. Zaytsev wrote:
> Hi,
>
> I'm sorry if my question would appear to be trivial, but what am I
> supposed to do, if I want to wrap class methods, that return a reference
> to another class?
As a workaround you could use:
cdef extern from "test.h":
int*
Hey,
Maybe someone here already saw it (I don't have a track account, or I
would just create a ticket), but it would be nice if Cython was more
forgiving about contiguous requirements on strides. In the future this
would make it easier for numpy to go forward with changing the
contiguous flags to
On 28.02.2013 15:55, Dave Hirschfeld wrote:
So the issue is that at present memoryviews can't be readonly?
https://github.com/cython/cython/blob/master/Cython/Compiler/MemoryView.py#L33
Typed memoryviews are thus acquired with the PyBUF_WRITEABLE flag. If
the the assigned buffer is readonly,
On 28.02.2013 15:46, Yury V. Zaytsev wrote:
My method call is actually wrapped in a try { ... } catch clause,
because I declared it as being able to throw exceptions, so the
reference can't be defined in this block, or it will not be accessible
to the outside world.
If Cython generates illegal
Sturla Molden writes:
>
> On 27.02.2013 20:05, Dave Hirschfeld wrote:
>
> > Is this a required restriction? Is there any workaround?
>
> http://www.python.org/dev/peps/pep-3118/
>
> What you should consider is the "readonly" field in "struct bufferinfo"
> or the access flag "PyBUF_WRITEABLE"
On Thu, 2013-02-28 at 15:34 +0100, Sturla Molden wrote:
>
> This is clearly a bug in Cython. One cannot let a C++ reference
> dangle.
Hi Sturla,
Thanks for the confirmation! I had a closer look at it, and I think I
know why this happens.
My method call is actually wrapped in a try { ... } catch
On 28.02.2013 13:58, Yury V. Zaytsev wrote:
Hi,
I'm sorry if my question would appear to be trivial, but what am I
supposed to do, if I want to wrap class methods, that return a reference
to another class?
From reading the list, I've gathered that apparently the best strategy
of dealing with r
On 27.02.2013 20:05, Dave Hirschfeld wrote:
Is this a required restriction? Is there any workaround?
http://www.python.org/dev/peps/pep-3118/
What you should consider is the "readonly" field in "struct bufferinfo"
or the access flag "PyBUF_WRITEABLE".
In short:
A PEP3118 buffer can be r
Hi,
I'm sorry if my question would appear to be trivial, but what am I
supposed to do, if I want to wrap class methods, that return a reference
to another class?
>From reading the list, I've gathered that apparently the best strategy
of dealing with references is just to not to use them (convert
%%cython
cimport cython
import numpy as np
cimport numpy as np
ctypedef np.float64_t float64_t
@cython.boundscheck(False)
@cython.wraparound(False)
@cython.cdivision(True)
def echo_numpy(np.ndarray[float64_t, ndim=1] x):
return x
@cython.boundscheck(False)
@cython.wraparound(False)
@cython.
Dave Hirschfeld writes:
>
> Dave Hirschfeld writes:
>
> >
> > Using the following test code:
>
> >
> > So, it seems either typing the array as a memview or printing res
> > will screw up the calculation.
> >
> > The cython code is given below. Any ideas if this is a cython bug or
somethin
Looking into IndexNode class in ExprNode.py I have seen a possibility
for addition of more fast code path for unicode[index] as it done in
method `generate_setitem_code` in case of lists.
This is files for evaluation of performance difference:
unicode_index.h
/* This is striped version of
Dave Hirschfeld writes:
>
> Using the following test code:
>
> So, it seems either typing the array as a memview or printing res
> will screw up the calculation.
>
> The cython code is given below. Any ideas if this is a cython bug or
> something
> I'm doing wrong?
>
> Thanks,
> Dave
>
T
28 matches
Mail list logo
