headers
Greg Ewing | 1 Aug 2008 01:38
Picon
Picon
Favicon

Re: [Cython] Temp framework proposal

Dag Sverre Seljebotn wrote:

> I think it is mostly the CloneNode that scares me, that doesn't look very
> intuitive to use from a transform perspective.

On further reflection, CloneNode isn't the right thing
to use, since it assumes it's being inserted during
the analysis phase and doesn't quite do what we want.

I think the best thing would be to add a new node
type, such as LocalRefNode (and maybe rename
LocalNode to LocalDefNode to better distinguish
them).

I'm not sure I like the idea of re-using NameNode,
since it's intended to represent a name appearing
in the source code, and temp locals don't correspond
to any name in the source.

--

-- 
Greg
Permalink | Reply | 0 comments |
headers
Greg Ewing | 1 Aug 2008 03:43
Picon
Picon
Favicon

Re: [Cython] Refactor or surgery on global constants?

Dag Sverre Seljebotn wrote:

> 2) Move these things from the scopes to code.global (a global context of 
> the CCodeWriter). This fits nicely with utility_code going over as well. 
> This means that for now each scope simply pipe their things into code 
> where they are merged, while in time then e.g. StringNode could intern a 
> string during code generation rather than bothering with it during 
> analysis.

This sounds good to me.

--

-- 
Greg
Permalink | Reply | 1 comment |
headers
Stefan Behnel | 1 Aug 2008 06:41
Picon
Favicon

Re: [Cython] Cython and complex floats

Hi,

Dag Sverre Seljebotn wrote:
> Buffers and Python has the complex datatype, while I'm reasonably sure I 
> haven't found anything about it in Cython (?).

You can use Python's complex types in Cython by simply declaring them as an
extension type:

    cdef extern from "complexobject.h":

        struct Py_complex:
            double real
            double imag

        ctypedef class __builtin__.complex [object PyComplexObject]:
            cdef Py_complex cval

    # A function which uses the above type
    def spam(complex c):
        print "Real:", c.cval.real
        print "Imag:", c.cval.imag

That's already done in Cython/Includes/python2.5.pxd.

> 1) Complex numbers can be pulled out into a struct consisting of two 
> floats. Like this:
> 
> cdef struct cdouble:
>    double real
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Bradshaw | 1 Aug 2008 06:58
Favicon

Re: [Cython] Refactor or surgery on global constants?

On Jul 31, 2008, at 6:43 PM, Greg Ewing wrote:

> Dag Sverre Seljebotn wrote:
>
>> 2) Move these things from the scopes to code.global (a global  
>> context of
>> the CCodeWriter). This fits nicely with utility_code going over as  
>> well.
>> This means that for now each scope simply pipe their things into code
>> where they are merged, while in time then e.g. StringNode could  
>> intern a
>> string during code generation rather than bothering with it during
>> analysis.
>
> This sounds good to me.

+1 from me too.

- Robert
Permalink | Reply | 0 comments |
headers
Robert Bradshaw | 1 Aug 2008 07:03
Favicon

Re: [Cython] Cython and complex floats

On Jul 31, 2008, at 9:41 PM, Stefan Behnel wrote:

> Hi,
>
> Dag Sverre Seljebotn wrote:
>> Buffers and Python has the complex datatype, while I'm reasonably  
>> sure I
>> haven't found anything about it in Cython (?).
>
> You can use Python's complex types in Cython by simply declaring  
> them as an
> extension type:
>
>     cdef extern from "complexobject.h":
>
>         struct Py_complex:
>             double real
>             double imag
>
>         ctypedef class __builtin__.complex [object PyComplexObject]:
>             cdef Py_complex cval
>
>     # A function which uses the above type
>     def spam(complex c):
>         print "Real:", c.cval.real
>         print "Imag:", c.cval.imag
>
> That's already done in Cython/Includes/python2.5.pxd.
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dag Sverre Seljebotn | 1 Aug 2008 09:27
Picon
Picon

Re: [Cython] Cython and complex floats

Stefan Behnel wrote:
> Hi,
> 
> Dag Sverre Seljebotn wrote:
>> Buffers and Python has the complex datatype, while I'm reasonably sure I 
>> haven't found anything about it in Cython (?).
> 
> You can use Python's complex types in Cython by simply declaring them as an
> extension type:
> 
>     cdef extern from "complexobject.h":
> 
>         struct Py_complex:
>             double real
>             double imag
> 
>         ctypedef class __builtin__.complex [object PyComplexObject]:
>             cdef Py_complex cval
> 
>     # A function which uses the above type
>     def spam(complex c):
>         print "Real:", c.cval.real
>         print "Imag:", c.cval.imag
> 
> That's already done in Cython/Includes/python2.5.pxd.

Thanks. Buffers support more types though (Zf, Zd and Zg, ie complex 
float, complex double, complex long double), so I'm not sure how useful 
this would be.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Behnel | 1 Aug 2008 10:22
Picon
Favicon

Re: [Cython] Refactor or surgery on global constants?

Hi,

Dag Sverre Seljebotn wrote:
> In making it possible to have runnable code in pxds, I need to make a 
> choice. The problem is that interned strings, objects etc. live in 
> seperate scopes and you get double copies, basically now I get the 
> following code twice in my c-file:
> 
> static char __pyx_k___getbuffer__[] = "__getbuffer__";
> static PyObject *__pyx_kp___getbuffer__;
> 
> which gcc isn't too thrilled about.
> [...]
> 2) Move these things from the scopes to code.global (a global context of 
> the CCodeWriter). This fits nicely with utility_code going over as well. 
> This means that for now each scope simply pipe their things into code 
> where they are merged, while in time then e.g. StringNode could intern a 
> string during code generation rather than bothering with it during 
> analysis. (I think this is a viable way forward, but may take an hour or 
> three longer for me to do.)

Since I previously worked a bit on the string interning code, I think it would
really benefit from such a change. Please go ahead.

Stefan
Permalink | Reply | 2 comments |
headers
Lisandro Dalcin | 1 Aug 2008 18:10
Picon
Gravatar

[Cython] vtables and the type cache

In general, for Py >= 2.6, we sould invalidate the type cache every
time we set something in the 'tp_dict' field. 'Pyx_SetVtable()' adds
stuff there. However, this call is made immediately after
'PyType_Ready()', so at first it seems the call to
'Pyx_TypeModified()' is not needed. But I'm not completelly sure about
this, and anyway perhaps the safest thing to do is to invalidate the
cache,

Comments? BTW, I've already have a patch for this.

--

-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
Permalink | Reply | 0 comments |
headers
Arnaud Bergeron | 1 Aug 2008 21:48
Picon

[Cython] Equivalent of __new__() in python

Sorry if this is the wrong list to ask questions like that, I couldn't
find any other list for cython.

I am looking for a way to implement the uniqueness of a class in
Cython.  I have a class say:

cdef class Unique(object):
    cdef val

    def __init__(self, val):
        self.val = val

And I want to have only one instance at a time with a single value of val.

I already know how to do this in python using the __new__() method and
a WeakValueDictionary.  I am looking for a way to do the equivalent in
cython.

And if this requires monkey-patching the tp_new slot of the class,
perhaps some pointers as to what should the replacement method should
at least do in order not to screw the rest of the system.

Arnaud
Permalink | Reply | 3 comments |
headers
Ondrej Certik | 2 Aug 2008 19:40
Picon
Gravatar

[Cython] couple gcc warnings problems

Hi,

$ cython -v
Cython version 0.9.8
$ cython --convert-range step.pyx
$ gcc -O3 -W -Wall -I/usr/include/python2.5/ -I/usr/include/numpy/ -c
-o step.o step.c
step.c: In function '__pyx_pf_4step_temperature':
step.c:608: warning: unused parameter '__pyx_self'
step.c: In function '__pyx_pf_4step_advance':
step.c:739: warning: unused parameter '__pyx_self'
step.c: In function '__pyx_pf_4step_assign_speeds':
step.c:1068: warning: unused parameter '__pyx_self'
step.c: In function '__pyx_pf_4step_fit_in_the_box':
step.c:1336: warning: unused parameter '__pyx_self'
step.c: In function '__pyx_pf_4step_get_f':
step.c:1675: warning: unused parameter '__pyx_self'
step.c: In function '__pyx_pf_4step_get_f2':
step.c:1794: warning: unused parameter '__pyx_self'
step.c: In function '__pyx_pf_4step_calculate_potential':
step.c:1941: warning: unused parameter '__pyx_self'
step.c: At top level:
step.c:2052: warning: missing initializer
step.c:2052: warning: (near initialization for
'__pyx_string_tab[11].is_identifier')
/usr/include/numpy/__multiarray_api.h:959: warning: '_import_array'
defined but not used

Now you can discover couple problems above. The last warning:
(Continue reading)

Permalink | Reply | 7 comments |

Gmane