Stefan Behnel | 1 Sep 12:14 2014
Picon

Re: [Cython] build failure on windows with 0.21b2 windows py27 x64

Dirk Rothe schrieb am 01.09.2014 um 09:55:
> the Problem reported by Ian Bell on v0.21b1 seems still to be there. With
> v0.21a1 from https://github.com/cython/cython/releases/tag/0.21a1
> everything seems to be fine. So maybe it's related to the method call
> optimisations, you've mentioned.
> 
> I've also tested with windows+py27+x64 and I get the same errors;
> 
> configobj.c(42437) : error C2121: '#' : invalid character : possibly the
> result of a macro expansion
> configobj.c(42437) : error C2146: syntax error : missing ')' before
> identifier 'ifdef'
> configobj.c(42437) : error C2121: '#' : invalid character : possibly the
> result of a macro expansion
> configobj.c(42439) : error C2059: syntax error : 'else'
> configobj.c(42449) : error C2059: syntax error : '}'
> configobj.c(42463) : error C2121: '#' : invalid character : possibly the
> result of a macro expansion
> configobj.c(42463) : error C2121: '#' : invalid character : possibly the
> result of a macro expansion
> error: command '"C:\Program Files (x86)\Microsoft Visual Studio
> 9.0\VC\BIN\amd64\cl.exe"' failed with exit status 2

Could you copy lines 42430-42463 (i.e. the error lines plus a bit of
preceding context) from the generated C file and send them to me? (Please
make sure it's clear which lines are the offending ones.)

Thanks,

Stefan
(Continue reading)

Alexandru Ionut Grama | 26 Aug 17:45 2014
Picon

[Cython] [Desired feature] Process .pxd before .py

Hello to all

I've start to use cython in order to use call some API modules written in python from C/C++. Those modules written in python must remain untouched, and all .py files should be "decorated" with their counterpart .pxd files.
I would like to mark as public some API functions from .py files, following the indications from http://docs.cython.org/src/tutorial/pxd_files.html. I've started to write a little example:

suma_alex.py:
def suma_Alex(a,b):
        return a+b

suma_alex.pxd:
cdef public int suma_Alex(int a,int b)


The combination of those two files should turn into something like this for the compiler:

cdef public int suma_Alex(int a,int b):
      return a+b

On generated .h file I should obtain a function prototype like this:
__PYX_EXTERN_C DL_IMPORT(int) suma_Alex(int, int);

Instead of that, I obtain a prototype like this:
__PYX_EXTERN_C DL_IMPORT(int) __pyx_f_10suma_alex_suma_Alex(int, int);

Digging into code and executing cythonize with pdb, I followed that is executed a pipeline for .py file before .pxd file's pipeline. Correct me if I'm wrong, but this makes the name of .c function be generated according to py file instead of pxd file. That makes an add of string "__pyx_f_10suma_alex_" before function name, because the compiler doesn't know about "public" key (on python doesn't exists). Including public key on a pxd file for this function makes the compiler remove "static" key and generate a .h file, but doesn't change the name prototype into a simple "suma_Alex".

If I use cython on a pyx file containing the code below, it works perfectly as expected.
cdef public int suma_Alex(int a,int b):
      return a+b

The questions are:
- I'm doing what I want to do on a right way?
- Is this feature included on cython development version? I've tried on 0.20.2
- If is not implemented, I want to colaborate implementing it. Could you please provide me some guidelines with the methods/modules that I should modify?

King regards,
Alexandru.

--
---------------------------------------------------------------
Alexandru Ionut Grama
email: gramaalexandruionut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<div><div dir="ltr"><div>
<div>
<div>Hello to all</div>
<div><br></div>
<div>I've start to use cython in order to use call some API modules written in python from C/C++. Those modules written in python must remain untouched, and all .py files should be "decorated" with their counterpart .pxd files.</div>

<div>I would like to mark as public some API functions from .py files, following the indications from <a href="http://docs.cython.org/src/tutorial/pxd_files.html">http://docs.cython.org/src/tutorial/pxd_files.html</a>. I've started to write a little example:</div>

<div><br></div>
<div>suma_alex.py:</div>
<div>def suma_Alex(a,b):</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; return a+b</div>
<div><br></div>
<div>suma_alex.pxd:</div>
<div>cdef public int suma_Alex(int a,int b)</div>
<div><br></div>
<div><br></div>
<div>

The combination of those two files should turn into something like this for the compiler:</div>
<div><br></div>
<div>cdef public int suma_Alex(int a,int b):</div>
<div>&nbsp; &nbsp; &nbsp; return a+b</div>
<div><br></div>
<div>On generated .h file I should obtain a function prototype like this:</div>

<div>__PYX_EXTERN_C DL_IMPORT(int) suma_Alex(int, int);</div>
<div><br></div>
<div>Instead of that, I obtain a prototype like this:</div>
<div>__PYX_EXTERN_C DL_IMPORT(int) __pyx_f_10suma_alex_suma_Alex(int, int);</div>
<div>

<br>
</div>
<div>Digging into code and executing cythonize with pdb, I followed that is executed a pipeline for .py file before .pxd file's pipeline. Correct me if I'm wrong, but this makes the name of .c function be generated according to py file instead of pxd file. That makes an add of string "__pyx_f_10suma_alex_" before function name, because the compiler doesn't know about "public" key (on python doesn't exists). Including public key on a pxd file for this function makes the compiler remove "static" key and generate a .h file, but doesn't change the name prototype into a simple "suma_Alex".</div>

<div><br></div>
<div>If I use cython on a pyx file containing the code below, it works perfectly as expected.</div>
<div>cdef public int suma_Alex(int a,int b):</div>
<div>&nbsp; &nbsp; &nbsp; return a+b</div>
<div><br></div>
<div>The questions are:</div>

<div>- I'm doing what I want to do on a right way?</div>
<div>- Is this feature included on cython development version? I've tried on 0.20.2</div>
<div>- If is not implemented, I want to colaborate implementing it. Could you please provide me some guidelines with the methods/modules that I should modify?</div>

<div><br></div>
<div>King regards,</div>
<div>Alexandru.</div>
</div>
<div><br></div>-- <br>---------------------------------------------------------------<br>Alexandru Ionut Grama<br>email: <a href="mailto:gramaalexandruionut@..." target="_blank">gramaalexandruionut@...</a><br>
</div></div></div>
Robert Bradshaw | 24 Aug 07:46 2014
Picon

[Cython] Towards a formal Cython grammar

I've started playing around with writing a grammar for Cython. As well
as formally defining the language (in particular, with respect to
Python) this should allow us to eventually move to using
parser-generators rather than ad-hoc hand written code and be useful
to  external tools (e.g. IDEs, linters, syntax highlighting, etc.)

I've posted what I have at
https://github.com/robertwb/cython/tree/grammar , in particular

https://github.com/robertwb/cython/blob/grammar/Cython/Parser/Grammar
https://github.com/robertwb/cython/compare/robertwb:3aa9056943f83a68cc9d9335f8a9c81e9a6f3f91...363bc162fd626203f832a33b6c736ff8b10f6086#diff-8b69afcfc588fde3d763f2ec670e42c2L1

Nothing beyond generating the raw parse tree is hooked up yet, and
even that requires an extra directive (formal_grammar=True). Building
and using the parser requires a source-built Python (it looks for the
pgen artifact Python uses to compile the grammar). We may or may not
want to stick with this approach long term (though if we do we might
ship the generated .c files). This parse tree is still pretty
low-level, we might want to also create something like Python.asdl to
give us a (closer) AST.

The grammar isn't complete, but should cover a most of the language
(over 3/4 of the test suite passes, and that explores a lot of the
corner cases). The most notable omissions are that it's using Python's
lexer, so doesn't have a token for '?' or the additional literal
string prefixes/int literal suffixes. Also, as the lexer clearly
doesn't understand includes, these are handled by inlining in a
preparsing step (which messes with line numbers).

The grammar could be tightened up as well. For example, this grammar
doesn't distinguish between valid pxd vs. pyx constructs, and allows
cdef statements within if statements (or even normal class
declarations).

I tried to restrict the existing grammar as little as possible, in
particular the only new illegal identifiers are 'cdef', 'ctypedef' and
(for ambiguity reasons new' and 'sizeof'). Also, the "cython" keywords
may not be used for identifiers that might be typed (e.g. "def
foo(int): ..." is not allowed).

The most significant departure from the existing "grammar" is that
rather than using C-style declarators, cdef declarations are of the
form "cdef [type] name." Thus one write the (already legal)

    cdef double[3] loc

and

    cdef double* a, b

declares two pointers. How to handle function pointers is still up in
the air, but I wouldn't be opposed to moving to a new syntax (e.g.
"(double, void*) -> double" inspired by Py3) for those. It disallows
empty "declarators" for parameters of function declarations (though we
could consider adding this back).

i think this would also be a nice chance to simplify the grammar, so
there are some intentional ommisions. Most notably, there are several
modifiers (e.g the __cdecl, __stdcall, __fastcall callspecs, maybe
inline, maybe even "with nogil", and the "cdef class Foo [object
object_struct_name, type type_object_name ]" spec for external
classes) that would make more sense as decorators. This would be
backwards incompatible, but these are not commonly used features and
fair warning (or even translators, I included a sed script to deal
with the common case of declarators mentioned above) could be given
and I think could be worth the simplification.

Thoughts?

- Robert
Ian Bell | 21 Aug 09:00 2014
Picon

[Cython] build failure on windows with 0.21b1 windows py27 x64

 A snippet of my failure:

lex\Scanners.c(6876) : error C2121: '#' : invalid character : possibly the result of a macro expansion
lex\Scanners.c(6876) : error C2146: syntax error : missing ')' before identifier 'ifdef'
lex\Scanners.c(6876) : error C2121: '#' : invalid character : possibly the result of a macro expansion
lex\Scanners.c(6878) : error C2059: syntax error : 'else'
lex\Scanners.c(6888) : error C2059: syntax error : '}'
lex\Scanners.c(6902) : error C2121: '#' : invalid character : possibly the result of a macro expansion
lex\Scanners.c(6902) : error C2121: '#' : invalid character : possibly the result of a macro expansion
soft Visual Studio 9.0\VC\BIN\amd64\cl.exe"' failed with exit status 2

Anyone run into similar problems?
<div><div dir="ltr">
<div>&nbsp;A snippet of my failure:<br><br>lex\Scanners.c(6876) : error C2121: '#' : invalid character : possibly the result of a macro expansion<br>lex\Scanners.c(6876) : error C2146: syntax error : missing ')' before identifier 'ifdef'<br>

lex\Scanners.c(6876) : error C2121: '#' : invalid character : possibly the result of a macro expansion<br>lex\Scanners.c(6878) : error C2059: syntax error : 'else'<br>lex\Scanners.c(6888) : error C2059: syntax error : '}'<br>

lex\Scanners.c(6902) : error C2121: '#' : invalid character : possibly the result of a macro expansion<br>lex\Scanners.c(6902) : error C2121: '#' : invalid character : possibly the result of a macro expansion<br>

soft Visual Studio 9.0\VC\BIN\amd64\cl.exe"' failed with exit status 2<br><br>
</div>Anyone run into similar problems?<br>
</div></div>
Stefan Behnel | 16 Aug 08:40 2014
Picon

[Cython] python-ideas discussion on "multiple dispatch", also operator overloading

Hi,

there's a discussion going on on python-ideas about generic functions and
multiple dispatch. Might be interesting for the fused functions
implementation in Cython.

http://thread.gmane.org/gmane.comp.python.ideas/28790/focus=28848

Cython can definitely improve its own dispatch implementation.

The reply I linked to is by Nick Coghlan, who also makes an interesting
comment on operator overloading methods and NotImplemented:

"""
A *lot* of folks make the mistake
of raising TypeError or NotImplementedError directly in their operator
overload implementations, rather than returning the NotImplemented
singleton that tells the interpreter to try the other type. Even some
of the CPython builtins get that wrong, since the sq_concat and
sq_repeat slots in C don't properly support the type coercion dance,
so you *have* to raise the exception yourself if you're only
implementing those without implementing nb_add and nb_mul (types
defined in Python automatically populate both sets of C level slots if
you define __add__ or __mul__).
"""

I think Cython could help its users here to a certain extent, if only by
warning about raising TypeError explicitly in these methods and encouraging
better behaviour.

Stefan
Andriy Kornatskyy | 14 Aug 07:20 2014

[Cython] error LNK2001: unresolved external symbol PyInit_init

Here is an issue when trying to install wheezy.template (it uses cythonize) into environment with cython.

Host: windows 7 64bit Python version: 3.4.1 32 bit wheezy.template version: 0.1.151

When installing either from pip3 or downloading the source with python3 setup.py install

c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\link.exe /DLL /nologo /INCREMENTAL:NO
/LIBPATH:C:\Python34\libs /LIBPATH:C:\Python34\PCbuild /EXPORT: PyInit_init
build\temp.win32-3.4\Release\src\wheezy\template__init.obj /O
UT:build\lib.win32-3.4\wheezy\template__init.pyd /IMPLIB:build\temp.win32-3.4
\Release\src\wheezy\template__init.lib /MANIFESTFILE:build\temp.win32-3.4\Rel ease\src\wheezy\template__init.pyd.manifest
LINK : error LNK2001: unresolved external symbol PyInit_init
build\temp.win32-3.4\Release\src\wheezy\template__init__.lib : fatal error LNK1120: 1 unresolved externals
error: command 'c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\link.exe' failed with
exit status 1120

Some details are here:
https://bitbucket.org/akorn/wheezy.template/issue/10/installation-on-windows-fails

Thanks.

Andriy Kornatskyy

Leon Bottou | 12 Aug 18:06 2014

[Cython] [Re] OpenMP thread private variable not recognized (bug report + discussion)

On Tue, 12 Aug 2014 14:26:31, Sturla Molden wrote:
> Cython does not do an error here:[...
> - i is recognized as private
> - r is recognized as reduction
> - w is (correctly) recognized as shared

Not according to the documentation.
http://docs.cython.org/src/userguide/parallelism.html documentation for
cython.parallel.parallel says "A contained prange will be a worksharing loop
that is not parallel, so any variable assigned to in the parallel section is
also private to the prange. Variables that are private in the parallel block
are unavailable after the parallel block.".  Variable w is such a variable.

Furthermore, if cython is correct, why does GCC report an error on the
cython generated C code?  

My point here is that there is a bug because (a) cython does not behave as
documented, and (b) it generates invalid C code despite not reporting an
error.

> Personally I prefer to avoid OpenMP and just use Python threads and an
> internal function (closure) or an internal class. If you start to use
OpenMP,
> Apple's libdispatch ("GCD"), Intel TBB, or Intel clikplus, you will soon
discover
> that they are all variations over the same theme: a thread pool and a
closure.

I am making heavy uses of OpenBlas which also uses OpenMP.
Using the same queue manager prevents lots of CPU provisioning problem.
Using multiple queue managers in the same code does not work as well because
they are not aware of what the other one is doing.

- L.

Marcus Brinkmann | 12 Aug 04:57 2014
Picon

[Cython] bug: constructor declarations not working

Hi,

I want to declare and define C++ classes from Cython.  Sure, I could 
write them in native C++, but it's just small glue code, and I prefer to 
let Cython handle the GIL and all the other good stuff.

First, for reference, the following works (c.f. 
tests/run/cpp_classes_def.pyx):

== cython --cplus example1.pyx ============
cdef cppclass Foo "Foo":
   int _foo
   __init__(int foo) nogil:
     this._foo = foo
   __dealloc__() nogil:
     pass
===========================================

This will emit a declaration for Foo and the implementations of the 
constructor and destructor (output is truncated to show relevant parts 
only):

struct Foo {
   int _foo;
    Foo(int);
   virtual  ~Foo(void);
};
  Foo::Foo(int __pyx_v_foo) {
   this->_foo = __pyx_v_foo;
}
  Foo::~Foo(void) {
}

Now, I want to export the class to other cython files.  The following 
does not work, and I think it's a bug:

== example2.pxd ===========================
cdef extern cppclass Foo:
   int _foo
   __init__(int foo)
   __dealloc__()
===========================================

== cython --cplus example2.pyx ============
cdef cppclass Foo:
   __init__(int foo) nogil:
     this._foo = foo
   __dealloc__() nogil:
     pass
===========================================

== cython --cplus example3.pyx ============
from example2 cimport Foo

cdef Foo* foo_p = new Foo(2)
===========================================

This fails for example2 with an obscure error message:

$ cython --cplus example2.pyx
example2.pyx:3:8: undeclared name not builtin: this
...more spurious errors...

For example3, Cython runs through but trying to compile shows the actual 
problem (which you can also see in example2 if you shift things around a 
bit):

$ g++ -fPIC -shared -o example3.so -I /usr/include/python2.7 example3.cpp
example3.cpp: In function ‘void initexample3()’:
example3.cpp:775:38: error: no matching function for call to ‘Foo::Foo(int)’
    __pyx_v_8example3_foo_p = new Foo(2);

This is in the generated code:

/*--- Type declarations ---*/
struct Foo;
struct Foo {
   int _foo;
   virtual  ~Foo(void);
};

It's missing the constructor declaration!

I traced this a bit down the Compiler/Symtab.py and found this part in 
CppClassScope::declare_var:

4e07fc52 (Robert Bradshaw      2012-08-21 00:46:00 -0700 2112) 
if name != "this" and (defining or name != "<init>"):
4e07fc52 (Robert Bradshaw      2012-08-21 00:46:00 -0700 2113) 
    self.var_entries.append(entry)

Here defining is 0, so the declaration is skipped.  I don't know Cython 
internals, so I am hoping someone who does can fix this easily given the 
above information or point me in the right direction.

Thanks a lot for Cython, it's very useful!

Marcus Brinkmann
Leon Bottou | 11 Aug 03:20 2014

[Cython] OpenMP thread private variable not recognized (bug report + discussion)


The attached cython program uses an extension class to represent a unit of 
work. The with parallel block temporarily gets the gil to allocate the object, 
then release the gil and performs the task with a for i in prange(...) 
statement. My expectation was to have w recognized as a thread private 
variable.

    with nogil, parallel():
        with gil: 
            w = Worker(n)                 # should be thread private
            with nogil: 
                for i in prange(0,m): 
                    r += w.run()          # should be reduction
            w = None                      # is this needed?

Cythonize (0.20.2) works without error but produces an incorrect C file.

hello.c: In function ‘__pyx_pf_5hello_run’:
hello.c:2193:42: error: expected identifier before ‘)’ token
hello.c: At top level:

The erroneous line is:

#pragma omp parallel private() reduction(+:__pyx_v_r) private(__pyx_t_5, 
__pyx_t_4, __pyx_t_3) firstprivate(__pyx_t_1, __pyx_t_2) 
private(__pyx_filename, __pyx_lineno, __pyx_clineno) 
shared(__pyx_parallel_why, __pyx_parallel_exc_type, __pyx_parallel_exc_value, 
__pyx_parallel_exc_tb)

where you can see that the first private() clause has no argument. The 
variable __pyx_v_w is not declared as private either as I would expect.

I believe that the problem comes from line 7720 in Cython/Compiler/Node.py

        if self.privates:
            privates = [e.cname for e in self.privates
                                    if not e.type.is_pyobject]
            code.put('private(%s)' % ', '.join(privates))

And I further believe that the clause "if not e.type.is_pyobject" has been 
added because nothing would decrements the reference count of the thread 
private worker object when leaving the parallel block. 

My quick fix would be to remove this clause and make sure that my program 
contains the line "w = None" before leaving the thread. But I realize that 
this is not sufficient for you.

Note that the temporary python objects generated by the call to the Worker 
construction are correctly recognized as thread private and their reference 
count is correctly decremented when they are no longer needed.  The problem 
here is the clash between the python scoping rules and the semantics of thread 
private variables. This is one of these cases where I would have liked to be 
able to write

    with nogil, parallel():
        with gil: 
            cdef w = Worker(n)            # block-scoped cdef
            with nogil: 
                for i in prange(0,m): 
                    r += w.run()

with an understanding that the scope of the cdef variable is limited to the 
block where the cdef appears. But when you try this, cython tells you that 
cdefs are not legal there. 

# -*- Python -*-

import numpy as np
cimport numpy as np
from cython.parallel import parallel, prange

cdef class Worker:
    cdef double[::1] v
    def __init__(self, int n):
        self.v = np.random.randn(n)
    cdef double run(self) nogil:
        cdef int i
        cdef int n = self.v.shape[0]
        cdef double s = 0
        for i in range(0,n): 
            s += self.v[i]
        return s / n

def run(int n, int m):
    cdef Worker w
    cdef double r
    cdef int i
    with nogil, parallel():
        with gil: 
            w = Worker(n)
            with nogil: 
                for i in prange(0,m): 
                    r += w.run()
            w = None
    return r / m

Attachment (setup.py): text/x-python, 349 bytes
# -*- Python -*-

import numpy as np
cimport numpy as np
from cython.parallel import parallel, prange

cdef class Worker:
    cdef double[::1] v
    def __init__(self, int n):
        self.v = np.random.randn(n)
    cdef double run(self) nogil:
        cdef int i
        cdef int n = self.v.shape[0]
        cdef double s = 0
        for i in range(0,n): 
            s += self.v[i]
        return s / n

def run(int n, int m):
    cdef Worker w
    cdef double r
    cdef int i
    with nogil, parallel():
        with gil: 
            w = Worker(n)
            with nogil: 
                for i in prange(0,m): 
                    r += w.run()
            w = None
    return r / m

J Robert Ray | 9 Aug 04:04 2014
Picon

[Cython] Bug: operator[] does not respect except +

I apologize for not having a working demonstration, but I have found this bug and verified it is still an issue in Cython 0.20.2. No try/catch block is generated for operator[]. In contrast, a try/catch block does get generated for operator().

If it is any use, here is a paraphrasing of the pyx code and the generated cpp code.

cdef extern from "blah.h" namespace "blah":
    cdef cppclass Blah:
        int operator[](int) except +

...

cdef class PyBlah:
    ...
    def demo(self, int index):
        return deref(self.thisptr)[index]

...

/* "Blah.pyx":107
 *     def demo(self, int index):
 *         return deref(self.thisptr)[index]             # <<<<<<<<<<<<<<
 */
  __Pyx_XDECREF(__pyx_r);
  __pyx_t_1 = __Pyx_PyInt_From_int(((*__pyx_v_self->thisptr)[__pyx_v_index])); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 107; __pyx_clineno = __LINE__; goto __pyx_L1_error;}
  __Pyx_GOTREF(__pyx_t_1);
  __pyx_r = __pyx_t_1;
  __pyx_t_1 = 0;
  goto __pyx_L0;


Please let me know if I'm doing anything wrong. Thanks!
<div><div dir="ltr">I apologize for not having a working demonstration, but I have found this bug and verified it is still an issue in Cython 0.20.2. No try/catch block is generated for operator[]. In contrast, a try/catch block does get generated for operator().<div>

<br>
</div>
<div>If it is any use, here is a paraphrasing of the pyx code and the generated cpp code.</div>
<div>
<div><br></div>
<div>cdef extern from "blah.h" namespace "blah":</div>
<div>&nbsp; &nbsp; cdef cppclass Blah:</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; int operator[](int) except +</div>
<div><br></div>
<div>...</div>
<div><br></div>
<div>cdef class PyBlah:</div>
<div>&nbsp; &nbsp; ...</div>
<div>&nbsp; &nbsp; def demo(self, int index):</div>
<div>

&nbsp; &nbsp; &nbsp; &nbsp; return deref(self.thisptr)[index]</div>
<div><br></div>
<div>...</div>
<div><br></div>
<div>
<div>/* "Blah.pyx":107</div>
<div>&nbsp;* &nbsp; &nbsp; def demo(self, int index):<br>
</div>
<div>&nbsp;* &nbsp; &nbsp; &nbsp; &nbsp; return deref(self.thisptr)[index] &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; # &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;</div>

<div>&nbsp;*/<br>
</div>
<div>&nbsp; __Pyx_XDECREF(__pyx_r);</div>
<div>&nbsp; __pyx_t_1 = __Pyx_PyInt_From_int(((*__pyx_v_self-&gt;thisptr)[__pyx_v_index])); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 107; __pyx_clineno = __LINE__; goto __pyx_L1_error;}</div>

<div>&nbsp; __Pyx_GOTREF(__pyx_t_1);</div>
<div>&nbsp; __pyx_r = __pyx_t_1;</div>
<div>&nbsp; __pyx_t_1 = 0;</div>
<div>&nbsp; goto __pyx_L0;</div>
<div><br></div>
<div><br></div>
<div>Please let me know if I'm doing anything wrong. Thanks!</div>

</div>
</div>
</div></div>
Ian Henriksen | 4 Aug 21:11 2014
Picon

[Cython] aritmetic with arrays in Cython

Hi all,
I noticed that some time ago there was a pull request (https://github.com/cython/cython/pull/144) open that was trying to implement basic arithmetic operations with arrays. This seems to have also been proposed in CEP 518 (https://github.com/cython/cython/wiki/enhancements-simd). What is the status on this?

This is a feature I'd really like to see in Cython. I'd be happy to help with it, though I don't currently know enough about the internals of Cython to do it without some guidance. What would be the best way to do this? I've had three ideas thus far that might allow something like this to work, but I'd really like to get some second opinions before I get too far with any of them.

1. Make these array operations available as a part of Cython's memory view objects.

2. Write a Cython wrapper around a NumPy-like C++ library. https://github.com/ContinuumIO/libdynd seems to be a good candidate, though I'm not as familiar with it. (This doesn't strike me as something that would be a part of the main Cython project, but it could be a good way to make this sort of functionality available. It seems like a good way to avoid a lot of duplicate work though.)

3. Write a Fortran backend for Cython that uses Fortran's arrays wherever memory views are used.
(This could be a bit crazy, but with the iso_c_binding module, it might be possible. It could also allow better optimizations for arrays to be applied by the compiler.)

What would be the best way to go about this?

Thanks!

-Ian Henriksen
<div><div dir="ltr">Hi all,<div>I noticed that some time ago there was a pull request (<a href="https://github.com/cython/cython/pull/144">https://github.com/cython/cython/pull/144</a>) open that was trying to implement basic arithmetic operations with arrays. This seems to have also been proposed in CEP 518 (<a href="https://github.com/cython/cython/wiki/enhancements-simd">https://github.com/cython/cython/wiki/enhancements-simd</a>). What is the status on this?</div>
<div><br></div>
<div>This is a feature I'd really like to see in Cython. I'd be happy to help with it, though I don't currently know enough about the internals of Cython to do it without some guidance. What would be the best way to do this? I've had three ideas thus far that might allow something like this to work, but I'd really like to get some second opinions before I get too far with any of them.</div>
<div><br></div>
<div>1. Make these array operations available as a part of Cython's memory view objects.</div>
<div><br></div>
<div>2. Write a Cython wrapper around a NumPy-like C++ library.&nbsp;<a href="https://github.com/ContinuumIO/libdynd">https://github.com/ContinuumIO/libdynd</a> seems to be a good candidate, though I'm not as familiar with it. (This doesn't strike me as something that would be a part of the main Cython project, but it could be a good way to make this sort of functionality available. It seems like a good way to avoid a lot of duplicate work though.)</div>
<div><br></div>
<div>3. Write a Fortran backend for Cython that uses Fortran's arrays wherever memory views are used.</div>
<div>(This could be a bit crazy, but with the iso_c_binding module, it might be possible. It could also allow better optimizations for arrays to be applied by the compiler.)</div>
<div><br></div>
<div>What would be the best way to go about this?</div>
<div><br></div>
<div>Thanks!</div>
<div><br></div>
<div>-Ian Henriksen</div>
</div></div>

Gmane