[Cython] buffer&numpy bugs&shortcomings

[Norbert Nemec]

Thanks, Dan, for the comments on the bugs I reported. I just requested a trac account from Robert to produce proper tickets for the latter two.

Good to know that two of the issues will be worked on over the summer. I should have checked the trac tickets more thoroughly...

In fact, I know the problem of limited resources just too well. Just amazing what you guys have produced already. I would certainly like to join in with more than just bug reports, but for the moment, that is all I can offer. :-(

Greetings,
Norbert




-------- Original-Nachricht --------
> Datum: Wed, 29 Apr 2009 15:50:58 +0200
> Von: Dag Sverre Seljebotn <dagss at student.matnat.uio.no>
> An: cython-dev at codespeak.net
> Betreff: Re: [Cython] buffer&numpy bugs&shortcomings

> Norbert Nemec wrote:
> > Hi there,
> > 
> > thanks for the great work on Cython! It has already helped me to a
> significant speedup on my code.
> > 
> > Working to port parts of my numpy-based program to Cython, I stumbled
> over a number of bugs/shortcomings in the implementation of buffer types and
> the numpy-cython interface that I would like to report in the following.
> For every snippet, assume a header of
> 
> Thanks. All in all, we know that there are major shortcomings, the 
> problem is simply having resources to pull it off. Ask me if you want me 
> to e.g. mentor you for doing a patch or similar.
> 
> Still I'll take care to track these problems; see below for individual 
> resopnse.
> 
> > 
> > --------
> >     import numpy
> >     cimport numpy
> > --------
> > 
> > ==============
> > 1. (reported before) extension types cannot have buffer types as
> elements. The snippet
> > 
> > --------
> > cdef class myclass:
> >     cdef numpy.ndarray[numpy.float_t] data
> > --------
> > 
> > gives the cython-compiler error "Buffer types only allowed as function
> local variables". I can work around this by keeping a pointer to the data as
> an additional member, but that results in a tremendous uglification of the
> whole code...
> 
> This is now http://trac.cython.org/cython_trac/ticket/301
> 
> I don't know when/whether it will be done, but you can try asking again 
> after summer when it will likely be easier for me to add it.
> 
> > ==============
> > 2. C functions cannot have buffer types as arguments. The snippet
> > 
> > --------
> > cdef myfunc(numpy.ndarray[numpy.float] arg):
> >     pass
> > --------
> > 
> > produces the cython *syntax error*
> > 
> > cdef myfunc(numpy.ndarray[numpy.float] arg):
> >                                       ^
> > ------------------------------------------------------------
> > /home/nobbi/NNlab/src/cython-bugs/tryout2.pyx:6:39: Expected ')'
> > 
> > The same thing works fine with def instead of cdef.
> 
> This is http://trac.cython.org/cython_trac/ticket/177
> 
> There's a good chance it will be fixed by Kurt Smith in his GSoC over 
> summer.
> 
> > ==============
> > 3. On typed variable of type numpy.ndarray, the .shape member does not
> work
> > 
> > ---------
> > cdef numpy.ndarray var = numpy.zeros((3,))
> > print var.shape
> > ---------
> > 
> > gives the cython compiler error "Cannot convert 'numpy.npy_intp *' to
> Python object"
> 
> Can you file a ticket for this?
> 
> (To get access to trac, email an .htpasswd-file to Robert Bradshaw)
> 
> This is mostly a question of semantics. shape is defined to be a C 
> integer array for speed of var.shape[0]. How can we define a generic 
> rule in Cython which makes both possible?
> 
> Should the behaviour of "var.shape" e.g. depend on the requested return 
> value? This means overloading on return value which is a non-trivial 
> language change, though perhaps appropriate here.
> 
> Thoughts welcome!
> 
> 
> > ==============
> > 4. The numpy.float_t type is not handled correctly. The snippet
> > 
> > ------------
> > cdef class myclass:
> >     cdef readonly:
> >         double var_d
> >         numpy.float_t var_nf
> >     def __init__(self):
> >         self.var_d = 42.0
> >         self.var_nf = 42.0
> > 
> > c = myclass()
> > 
> > print "double (correctly given as 42.0):",c.var_d
> > print "numpy.float_t (should be 42.0):",c.var_nf
> > ------------
> > 
> > compiles fine, but prints
> > 
> >     double (correctly given as 42.0): 42.0
> >     numpy.float_t (should be 42.0): 0.0
> > 
> > so the value of var_nf seems to be lost somewhere on the way.
> 
> This is a (major) bug that I was completely unaware of, and it should be 
> fixed soonish. Thanks a lot!
> 
> Will you file a ticket for it?
> 
> Dag Sverre
> _______________________________________________
> Cython-dev mailing list
> Cython-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/cython-dev

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01