headers
Sturla Molden | 2 Jul 2012 14:49
Picon
Gravatar

Re: [Cython] Automatic C++ conversions

On 30.06.2012 01:06, Stefan Behnel wrote:

>> std::string<=>  bytes
>> std::map<=>  dict
>> iterable =>  std::vector =>  list
>> iterable =>  std::list =>  list
>> iterable =>  std::set =>  set
>> 2-iterable =>  std::pair =>  2-tuple
>
> Very cool.

I think (in C++11) std::unordered_set and std::unordered_map should be 
used instead. They are hash-based with O(1) lookup.

std::set and std::map are binary search threes with average O(log n) 
lookup and worst-case O(n**2).

Also beware that C++11 has a std:tuple type.

Sturla Molden
Permalink | Reply | 2 comments |
headers
Sturla Molden | 2 Jul 2012 14:52
Picon
Gravatar

Re: [Cython] Automatic C++ conversions

On 02.07.2012 14:49, Sturla Molden wrote:

> I think (in C++11) std::unordered_set and std::unordered_map should be
> used instead. They are hash-based with O(1) lookup.
>
> std::set and std::map are binary search threes with average O(log n)
> lookup and worst-case O(n**2).

Sorry typo, that should be worst-case O(n).

Sturla
Permalink | Reply | 0 comments |
headers
Robert Bradshaw | 2 Jul 2012 18:09
Picon

Re: [Cython] Automatic C++ conversions

On Mon, Jul 2, 2012 at 5:49 AM, Sturla Molden <sturla <at> molden.no> wrote:
> On 30.06.2012 01:06, Stefan Behnel wrote:
>
>>> std::string<=>  bytes
>>> std::map<=>  dict
>>> iterable =>  std::vector =>  list
>>> iterable =>  std::list =>  list
>>> iterable =>  std::set =>  set
>>> 2-iterable =>  std::pair =>  2-tuple
>>
>>
>> Very cool.
>
>
> I think (in C++11) std::unordered_set and std::unordered_map should be used
> instead. They are hash-based with O(1) lookup.
>
> std::set and std::map are binary search threes with average O(log n) lookup
> and worst-case O(n**2).
>
> Also beware that C++11 has a std:tuple type.

The object => C++ coercion is always explicit, there's no choice made
here. This is used to do, e.g.

    cdef map<int, vector<double>> my_cpp_map = o

or

    cdef extern from "mylibrary.h":
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yaroslav Halchenko | 3 Jul 2012 00:56

[Cython] e: Automatic C++ conversions

I was thinking about updating Debian package for cython 0.16 but ran into
the failing unittests so decided first to check with experts: anything obvious
which comes to mind from seeing those?

...
compiling (c) and running sequential_parallel ... sequential_parallel.c: In function '__pyx_pf_19sequential_parallel_56test_chunksize':
sequential_parallel.c:12405:7: warning: variable '__pyx_t_6' set but not used [-Wunused-but-set-variable]
sequential_parallel.c:12404:7: warning: variable '__pyx_t_5' set but not used [-Wunused-but-set-variable]
sequential_parallel.c:12402:7: warning: variable '__pyx_t_3' set but not used [-Wunused-but-set-variable]
sequential_parallel.c: In function '__pyx_pw_19sequential_parallel_25test_nested_break_continue':
sequential_parallel.c:5887:29: warning: '__pyx_v_j' may be used uninitialized in this function [-Wmaybe-uninitialized]
sequential_parallel.c:5590:7: note: '__pyx_v_j' was declared here
sequential_parallel.c: In function '__pyx_f_19sequential_parallel_parallel_exc_cpdef_unnested.isra.29':
sequential_parallel.c:8915:3: warning: '__pyx_r' may be used uninitialized in this function [-Wmaybe-uninitialized]
sequential_parallel.c:8681:7: note: '__pyx_r' was declared here
sequential_parallel.c: In function '__pyx_f_19sequential_parallel_parallel_exc_cpdef.isra.30':
sequential_parallel.c:8614:3: warning: '__pyx_r' may be used uninitialized in this function [-Wmaybe-uninitialized]
sequential_parallel.c:8259:7: note: '__pyx_r' was declared here
sequential_parallel.c: In function '__pyx_pw_19sequential_parallel_33test_parallel_exc_cdef':
sequential_parallel.c:8222:78: warning: '__pyx_r' may be used uninitialized in this function [-Wuninitialized]
sequential_parallel.c:7946:7: note: '__pyx_r' was declared here
sequential_parallel.c:8233:69: warning: '__pyx_r' may be used uninitialized in this function [-Wuninitialized]
sequential_parallel.c:7578:7: note: '__pyx_r' was declared here
Fatal Python error: deletion of interned string failed
Compiling /tmp/buildd/.cython/inline/_cython_inline_a998a12d3d1450b2368ca75e07a27942.pyx
because it changed.
Cythonizing /tmp/buildd/.cython/inline/_cython_inline_a998a12d3d1450b2368ca75e07a27942.pyx
ERROR
compiling (cpp) and running sequential_parallel ... sequential_parallel.cpp: In function 'PyObject* __pyx_pf_19sequential_parallel_56test_chunksize(PyObject*)':
sequential_parallel.cpp:12402:7: warning: variable '__pyx_t_3' set but not used [-Wunused-but-set-variable]
(Continue reading)

Permalink | Reply | 3 comments |
headers
Yaroslav Halchenko | 3 Jul 2012 01:04

[Cython] Exception: Tests in module 'parallel' were unexpectedly killed by signal 11

please pardon my sloppy cut/paste which ruined the subject line in the
original post ;)  So the topic is:

On Mon, 02 Jul 2012, Yaroslav Halchenko wrote:
> I was thinking about updating Debian package for cython 0.16 but ran into
> the failing unittests so decided first to check with experts: anything obvious
> which comes to mind from seeing those?

> ...
> compiling (c) and running sequential_parallel ... sequential_parallel.c: In function '__pyx_pf_19sequential_parallel_56test_chunksize':
> sequential_parallel.c:12405:7: warning: variable '__pyx_t_6' set but not used [-Wunused-but-set-variable]
> sequential_parallel.c:12404:7: warning: variable '__pyx_t_5' set but not used [-Wunused-but-set-variable]
> sequential_parallel.c:12402:7: warning: variable '__pyx_t_3' set but not used [-Wunused-but-set-variable]
> sequential_parallel.c: In function '__pyx_pw_19sequential_parallel_25test_nested_break_continue':
> sequential_parallel.c:5887:29: warning: '__pyx_v_j' may be used uninitialized in this function [-Wmaybe-uninitialized]
> sequential_parallel.c:5590:7: note: '__pyx_v_j' was declared here
> sequential_parallel.c: In function '__pyx_f_19sequential_parallel_parallel_exc_cpdef_unnested.isra.29':
> sequential_parallel.c:8915:3: warning: '__pyx_r' may be used uninitialized in this function [-Wmaybe-uninitialized]
> sequential_parallel.c:8681:7: note: '__pyx_r' was declared here
> sequential_parallel.c: In function '__pyx_f_19sequential_parallel_parallel_exc_cpdef.isra.30':
> sequential_parallel.c:8614:3: warning: '__pyx_r' may be used uninitialized in this function [-Wmaybe-uninitialized]
> sequential_parallel.c:8259:7: note: '__pyx_r' was declared here
> sequential_parallel.c: In function '__pyx_pw_19sequential_parallel_33test_parallel_exc_cdef':
> sequential_parallel.c:8222:78: warning: '__pyx_r' may be used uninitialized in this function [-Wuninitialized]
> sequential_parallel.c:7946:7: note: '__pyx_r' was declared here
> sequential_parallel.c:8233:69: warning: '__pyx_r' may be used uninitialized in this function [-Wuninitialized]
> sequential_parallel.c:7578:7: note: '__pyx_r' was declared here
> Fatal Python error: deletion of interned string failed
> Compiling /tmp/buildd/.cython/inline/_cython_inline_a998a12d3d1450b2368ca75e07a27942.pyx
because it changed.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stefan Behnel | 3 Jul 2012 06:13
Picon
Favicon

Re: [Cython] Exception: Tests in module 'parallel' were unexpectedly killed by signal 11

Yaroslav Halchenko, 03.07.2012 01:04:
> please pardon my sloppy cut/paste which ruined the subject line in the
> original post ;)  So the topic is:
> 
> On Mon, 02 Jul 2012, Yaroslav Halchenko wrote:
>> I was thinking about updating Debian package for cython 0.16 but ran into
>> the failing unittests so decided first to check with experts: anything obvious
>> which comes to mind from seeing those?

Yes, they are known to be broken currently.

https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests/

AFAIK, Mark is working on fixing them.

Stefan
Permalink | Reply | 0 comments |
headers
Stefan Behnel | 3 Jul 2012 06:58
Picon
Favicon

[Cython] Cython methods for C/C++ types

Hi,

the discussion on allowing for automatic user provided ways to coerce
between Python types and C++ types got me thinking that this might hide a
rather interesting general feature: methods for low-level types. I faintly
remember that this idea has come up in our discussions before, but here's a
draft CEP for it:

http://wiki.cython.org/enhancements/ctypemethods

Basically, it would allow writing this in .pxd files:

"""
cdef extern from "...":
    cdef cppclass MyClass:
        cdef int cython_method_here(self):
            return 1

ctypedef double mydouble:
    cdef double cython_method_here(self):
        return self ** 2

cdef struct mystruct:
    int x, y

    cdef int cython_method_here(self):
        return self.x + self.y

cdef union myunion:
    int a
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stefan Behnel | 3 Jul 2012 09:14
Picon
Favicon

Re: [Cython] [cython-users] C++: how to handle failures of 'new'?

Robert Bradshaw, 29.06.2012 11:08:
> On Thu, Jun 28, 2012 at 10:45 PM, Stefan Behnel wrote:
>> Robert Bradshaw, 28.06.2012 21:46:
>>> On Thu, Jun 28, 2012 at 11:38 AM, Stefan Behnel wrote:
>>>> currently, when I write "new CppClass()" in Cython, it generates a straight
>>>> call to the "new" operator. It doesn't do any error handling. And the
>>>> current documentation doesn't even mention this case.
>>>>
>>>> Is there a "standard" way to handle this? It seems that C++ has different
>>>> ways to deal with failures here but raises an exception by default. Would
>>>> you declare the constructor(s) with an "except +MemoryError"? Is there a
>>>> reason Cython shouldn't be doing this automatically (if nothing else was
>>>> declared) ?
>>>
>>> I think it certainly makes sense to declare the default constructor as
>>> "except +" (and std::bad_alloc should become MemoryError),
>>
>> Right. The code in the constructor can raise other exceptions that must
>> also be handled properly. An explicit "except +" will handle that.
>>
>>
>>> but whether
>>> to implicitly annotate declared constructors is less clear, especially
>>> as there's no way to un-annotate them.
>>
>> I agree, but sadly, it's the default behaviour that is wrong. I'm sure we
>> made lots of users run into this trap already. I fixed the documentation
>> for now, but the bottom line is that we require users to take care of
>> proper declarations themselves. Otherwise, the code that we generate is
>> incorrect, although it's 100% certain that an allocation error can occur,
(Continue reading)

Permalink | Reply | 26 comments |
headers
mark florisson | 3 Jul 2012 12:12
Picon
Gravatar

Re: [Cython] Cython methods for C/C++ types

On 3 July 2012 05:58, Stefan Behnel <stefan_ml@...> wrote:
> Hi,
>
> the discussion on allowing for automatic user provided ways to coerce
> between Python types and C++ types got me thinking that this might hide a
> rather interesting general feature: methods for low-level types. I faintly
> remember that this idea has come up in our discussions before, but here's a
> draft CEP for it:
>
> http://wiki.cython.org/enhancements/ctypemethods
>
> Basically, it would allow writing this in .pxd files:
>
> """
> cdef extern from "...":
>     cdef cppclass MyClass:
>         cdef int cython_method_here(self):
>             return 1
>
> ctypedef double mydouble:
>     cdef double cython_method_here(self):
>         return self ** 2
>
> cdef struct mystruct:
>     int x, y
>
>     cdef int cython_method_here(self):
>         return self.x + self.y
>
> cdef union myunion:
(Continue reading)

Permalink | Reply | 0 comments |
headers
mark florisson | 3 Jul 2012 12:15
Picon
Gravatar

Re: [Cython] Cython methods for C/C++ types

On 3 July 2012 05:58, Stefan Behnel <stefan_ml@...> wrote:
> Hi,
>
> the discussion on allowing for automatic user provided ways to coerce
> between Python types and C++ types got me thinking that this might hide a
> rather interesting general feature: methods for low-level types. I faintly
> remember that this idea has come up in our discussions before, but here's a
> draft CEP for it:
>
> http://wiki.cython.org/enhancements/ctypemethods

I see this CEP also mentions overriding C++ methods. But I think if it
doesn't support virtual methods, then overriding base class methods by
calling another function is pretty horrible.

> Basically, it would allow writing this in .pxd files:
>
> """
> cdef extern from "...":
>     cdef cppclass MyClass:
>         cdef int cython_method_here(self):
>             return 1
>
> ctypedef double mydouble:
>     cdef double cython_method_here(self):
>         return self ** 2
>
> cdef struct mystruct:
>     int x, y
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane