Hi all,
Just recently got into working with cython for speeding up some calculation
with numpy.
this question, however, has nothing to do with numpy.
The following code is valid python:
var = 0
def count(n):
for i in range(n):
var += i
return var
Translating to cython
I tested that and it works, thanks.
Chris
On Sat, May 9, 2009 at 3:43 AM, Danilo Freitas dsurvi...@gmail.com wrote:
As Stefan said...
try:
cdef double var = 0.0
def count(int n):
cdef int i
global var
for i in range(n):
var += i
return var
I don't
What follows is my 0.02, and i'm really new at these two libs so keep in
mind I could be completely off base. I'm sure someone will jump in and
correct my errors.
I think the speed is really going to depend on the nature of your calls into
the c library. From the code i've examined, there will
done compiling a C dll.
Chris
On Wed, May 13, 2009 at 12:31 AM, Chris Colbert sccolb...@gmail.com wrote:
What follows is my 0.02, and i'm really new at these two libs so keep in
mind I could be completely off base. I'm sure someone will jump in and
correct my errors.
I think the speed
I'm trying to test writing extensions that release the gil. This simple
example is failing cython compilation with errors stating that the count()
function requires the gil.
Can anyone point me in the right direction?
Thanks,
Chris
# code ##
cdef double count(int n) nogil:
thanks
On Wed, May 13, 2009 at 11:48 AM, Dag Sverre Seljebotn
da...@student.matnat.uio.no wrote:
Chris Colbert wrote:
I'm trying to test writing extensions that release the gil. This simple
example is failing cython compilation with errors stating that the
count() function requires
the gil, and thus
waits for count() to return.
How do I work this so that I can run a c-function outside the gil and thus
make use of the multi-cores on my machine?
Thanks!
Chris
On Wed, May 13, 2009 at 11:58 AM, Chris Colbert sccolb...@gmail.com wrote:
thanks
On Wed, May 13, 2009 at 11:48 AM
Excellent! that did the trick!
Thanks Dag!
Chris
On Wed, May 13, 2009 at 12:16 PM, Dag Sverre Seljebotn
da...@student.matnat.uio.no wrote:
Chris Colbert wrote:
alright i made the change and here is the code:
cdef double count(int n) nogil:
cdef int i, j, k
cdef double out
so my intitial guess that the problem was with my inability to properly
build a dll was correct.
After reading (partially) the gcc manual on compiling optimizations i get
the following result:
Starting Threads
no GIL cython: Value: 1999000.00 Time: 8.076570 s
no GIL ctypes: Value:
as Dag said, don't use numpy to calculate the trig functions, and don't pass
a numpy array as the argument function. Pass 3 floats instead.
On Thu, May 14, 2009 at 11:25 AM, Dag Sverre Seljebotn
da...@student.matnat.uio.no wrote:
OUARDA MEHDI wrote:
and here my optimised function from
How would I go about interfacing with OpenCV data types in cython?
I've read the wiki on interfacing with external C code but didn't fully
follow.
I'm currently using a ctypes wrapper for OpenCV from python and doing some
manipulation there, but I would like to chain together a bunch of
You can probably skip the write my functions in a pure C source
file step and write them directly in Cython.
- Robert
i tried doing that today and was running into boat loads of trouble
resolving the IplImage data type and header dependencies.
This is actually turning out to be quite
This error seems like you're not linking to the python library. I
would recommend using distutils to compile your files. Can you
compile the Cython file
print hello
This is totally doable from Cython.
I can compile and use cython modules that don't depend on external c
libraries with
On Mon, May 18, 2009 at 7:30 PM, Chris Colbert sccolb...@gmail.com wrote:
This error seems like you're not linking to the python library. I
would recommend using distutils to compile your files. Can you
compile the Cython file
print hello
This is totally doable from Cython.
I can
Hoyt,
All functions, even external ones, that can be run without the gil
need the nogil decorator on the end or cython assumes it needs the
gil. E.g.
cdef extern from highgui.h:
cdef IplImage* cvLoadImage(char* file, int iscolor) nogil
cdef int cvNamedWindow(char* name, int
yet again:
for various reasons, I would like to use both the ctypes wrapper and cython
in same program. Specifically I have a ctypes instance of an OpenCV image. I
pass the pointer of this image to a cython function which returns a pointer
to a new image. I need to get this pointer back into
I think i'm starting to wrap my head around all of this, but I have a
question about expose a C data type to python.
I'm interfacing with the OpenCV library whose fundamental data structure is
an IplImage. Most of the functional code passes around pointers to these
types and can do this in cython
this message got sent before it was finished.
At any rate, am I on the right track here? I'll need a way, at the very
least to expose the data buffer of the image to python so I can display on
the screen via wxPython.
Chris
On Tue, May 19, 2009 at 11:29 AM, Chris Colbert sccolb...@gmail.com
Do I need to worry about python garbage collecting what I reference through
my IplImage*. i.e. when i create my images on the c-level, I alone am
responsible for freeing that space when no longer needed correct?
Chris
___
Cython-dev mailing list
, Lisandro Dalcin dalc...@gmail.com wrote:
On Tue, May 19, 2009 at 12:54 PM, Chris Colbert sccolb...@gmail.com
wrote:
Do I need to worry about python garbage collecting what I reference
through
my IplImage*. i.e. when i create my images on the c-level, I alone am
responsible for freeing
how do a pass a pointer to a C datatype to my python extension type
constructor? I have the following in my code:
in a cdef extern from .h block ##
struct _IplImage:
filler
ctypedef _IplImage IplImage
## extension type declaration ###
cdef class PyIplImage:
cdef
What you can do is allow it to pass in a char* (bytes) object with a
length, have a cdef set method, use opaque object pointer wrappers
(there was a previous thread about this).
i'm not sure I understand what your saying with this ^^^
You could also make a function
def
...@math.washington.edu wrote:
On May 19, 2009, at 2:02 PM, Chris Colbert wrote:
What you can do is allow it to pass in a char* (bytes) object with a
length, have a cdef set method, use opaque object pointer wrappers
(there was a previous thread about this).
i'm not sure I understand what your
Once you get used to code
Cython, and assuming you have some C/C++ background, I bet you will
stop using ctypes ;-) ..
I think you are right :). In an afternoon, I've got a decent amount of what
I need wrapped :)
Cheers!
Chris
___
Cython-dev
I know that Cython does an implicit conversion from char* to Python string,
but do I need to somehow specify the length of the string?
I ask because I have a data buffer of known size (7854000 bytes uint8) but
when i pass the pointer to that buffer into python, my string length is only
4617.
this
sources...
On Tue, May 19, 2009 at 6:22 PM, Chris Colbert sccolb...@gmail.com
wrote:
True, but it seems a little off to programatically set every attribute
one
by one every time i create an instance of that type.
Is it not recommended to declare a property for every attribute I want
Lisandro,
Once again, thank you!
I think I finally have a tricky question for you now however:
I have the OpenCV IplImage class wrapped as so:
cdef class IplImage:
cdef c_cxcore.IplImage* thisptr
#Convienience Functions
def show(self):
#
Any chance that cvQueryFrame() returns an image that you should not
free??
that's exactly it (i feel really dumb for having missed it)
the first img is likely garbage-collected. Perhaps your
Image.__dealloc__ is not doing the right thing in this case?
would you suggest setting a private
Hi,
I have this definition file:
cy_cvtypes.pxd #
cimport c_cxcore
cimport c_highgui
cdef class IplImage:
cdef c_cxcore.IplImage* thisptr
cdef int needs_free
###
and the corresponding implementation:
cy_cvtypes.pxy ##
cimport c_cxcore
Ok, so compiling each .pyx file into an individual .pyd worked.
Is there a way to properly compile everything into a single .pyd, or should
I create a dummy module at the end that imports each individual module when
called from python?
Chris
___
compiled and built into a single .pyd
Is that possible?
Chris
On Wed, May 20, 2009 at 8:35 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
Chris Colbert wrote:
Is there a way to properly compile everything into a single .pyd,
You can use include statements to split a .pyx into
multiple files
Hi,
I'm trying to write a wrapper for a C library.
The C header from which I am making declaration has this:
struct Foo
{
int blah;
union
{
int Bar;
} data;
}
can this be wrapped in Cython?
I've tried:
cdef extern from c.h:
ctypedef struct Foo:
I have certain functions that should accept types of IplImage or CvMat
I have the two types declared as inheriting from a generic CvArr as such
cdef class CvArr:
cdef void* thisptr
cdef class IplImage(CvArr):
.
cdef class CvMat(CvArr):
and a function declared like
, casting, or void pointers
I would greatly appreciate any insight one could give..
Thanks and Cheers!
Chris
On Thu, May 21, 2009 at 7:05 PM, Chris Colbert sccolb...@gmail.com wrote:
I have certain functions that should accept types of IplImage or CvMat
I have the two types declared
c_CvArr*self.image
cdef class CvMat(CvArr):
cdef c_CvMat *cvmat
def c_CvArr* handle(self):
return c_CvArr*self.cvmat
Mmm... just a use case for cdef properties managed by calling
get/setters in the vtable?
On Thu, May 21, 2009 at 9:16 PM, Chris Colbert sccolb...@gmail.com
wrote
so if I have:
cdef class IplImage:
cdef c_lib.IplImage* thisptr
cdef class CvMat:
cdef c_lib.CvMat* thisptr
then I can just do this?
def exposedPythonFunc(image): where image can be an IplImage or CvMat
c_lib.cFunction(image.thisptr) since I know thisptr exists
lol, OK thanks!
Just for my own education which parts of this will translate to C and which
will remain Python after Cython compilation?
Chris
Worse:
def exposedPythonFunc(image):
if isinstance(image, IplImage):
c_lib.cFunction((IplImageimage).thisptr)
elif
Ok, I get what your saying. that's a good idea and I think it's a little
cleaner than casting during the call.
Thanks!
Chris
On Fri, May 22, 2009 at 10:17 AM, Lisandro Dalcin dalc...@gmail.com wrote:
On Fri, May 22, 2009 at 1:49 AM, Chris Colbert sccolb...@gmail.com
wrote:
is 'handle
well, i tried your way Lisandro, and it compiled fine, but upon importing
the module, it raised an error along the lines of it appears IplImage is
not of the right type.
Dag's method works, but I'm still gonna try to find something cleaner.
Chris
On Fri, May 22, 2009 at 11:05 AM, Chris Colbert
, May 22, 2009 at 11:05 AM, Chris Colbert sccolb...@gmail.comwrote:
Ok, I get what your saying. that's a good idea and I think it's a little
cleaner than casting during the call.
Thanks!
Chris
On Fri, May 22, 2009 at 10:17 AM, Lisandro Dalcin dalc...@gmail.comwrote:
On Fri, May 22, 2009
alright I figured it out.
Lisandro, your method worked perfect. the problem was in my function
prototype in the .pxd file.
I had to change it to this (fixed the argument types):
/* .pxd ***/
cimport c_cxcore
cimport c_highgui
cdef class CvArr:
cdef c_cxcore.CvArr*
cdef c_cxcore.CvArr* handle(IplImage)
/* .pxy */
cdef class CvArr:
cdef c_cxcore.CvArr* handle(self):
return self.dummyptr
On Fri, May 22, 2009 at 12:20 PM, Chris Colbert sccolb...@gmail.com wrote:
alright I figured it out.
Lisandro, your method
So I'm wrapping the OpenCV library in Cython and its coming along quite
nicely (thanks to everyone here for getting me up to speed!), but today I've
run across a strange issue where a wrapped function fails for certain values
of integer arguments, but a pure c implementation testing the same thing
for that function and I
cant see anything wrong. You have any ideas I could try?
Thanks!
Chris
On Wed, May 27, 2009 at 10:49 AM, Lisandro Dalcin dalc...@gmail.com wrote:
On Wed, May 27, 2009 at 11:36 AM, Chris Colbert sccolb...@gmail.com
wrote:
sometimes the docs are a bit dated
:
On Wed, May 27, 2009 at 3:09 PM, Chris Colbert sccolb...@gmail.com
wrote:
Lisandro,
Unfortunately, I'm on a windows machine and thus can't use valgrind.
Wow... Well, not in a good position to help you... Anyway, Did you
build OpenCV with EXACTLY the same compiler your installed Python
Dag,
I've listed the code below and added the memory cleanup to the Cython file.
Behavior is the same.
#---the pure C code which doesnt crash---#
#include highgui.h
#include cv.h
#include cxcore.h
#include cxtypes.h
int main(void)
{
IplImage* img, *img2;
img =
I think I'm starting to narrow it down.
I made the following python extension module by hand and it works. I can
pass any value (0, 1, 2, or 3) to the function exttest.test() in python and
they all work properly.
#- exttest.c -#
#include Python.h
#include
I should note in the last code example, I manually change the integer and
the recompile. i.e. the python arguments passed to the function are
irrelevant.
Chris
On Thu, May 28, 2009 at 1:00 AM, Chris Colbert sccolb...@gmail.com wrote:
I think I'm starting to narrow it down.
I made
Many of the numpy functions (dot in particular) already execute as compiled
C extensions. Functions that execute mostly in Python (histogramdd for
example) can see a speedup by using Cython. That said, you would be better
off building numpy from source against lapack and atlas, this will give you
Alright, I fixed the problem by hacking the Cython generated C file.
I removed everything in the IF clause that determined whether the Python
Arguments were keyword argument or not and left only the PyTuple_GET_ITEM
statements.
I then changed the PyMethodDef line like so:
old entry:
Bradshaw
rober...@math.washington.edu wrote:
On May 28, 2009, at 9:16 AM, Chris Colbert wrote:
Alright, I fixed the problem by hacking the Cython generated C file.
I removed everything in the IF clause that determined whether the
Python Arguments were keyword argument or not and left only
Just to clarify, I've never used keyword arguments with this function.
Chris
On Thu, May 28, 2009 at 10:46 PM, Chris Colbert sccolb...@gmail.com wrote:
Robert,
That's correct. Of course I had to remove all the checks related to Keyword
args in the body of the function before it would execute
python strings are automagically converted to char* by cython.
You can also look at a wrapper i'm building for the OpenCV library.
cython-opencv at google code.
Chris
On Mon, Jun 1, 2009 at 6:38 AM, Amit Sethi amit.pureene...@gmail.comwrote:
hi ,
I guess this needs to go on cython-users but
I never mind being corrected/updated/put-in-my-place with such a great
answer.
So there you have it :)
Cheers!
On Mon, Jun 1, 2009 at 3:09 PM, Dag Sverre Seljebotn
da...@student.matnat.uio.no wrote:
Chris Colbert wrote:
python strings are automagically converted to char* by cython.
I'll
to code like this:
# foo.pyx
cdef int Foo_count = 0
cdef class Foo:
def __cinit__(self):
global Foo_count
Foo_count += 1
On Tue, Jun 2, 2009 at 1:36 PM, Chris Colbert sccolb...@gmail.com wrote:
you have to declare the attribute as public.
http://docs.cython.org
I think because he was cross compiling these extensions for windows
while working in MacOSX or Linux
On Wed, Jun 10, 2009 at 10:30 AM, Lisandro Dalcindalc...@gmail.com wrote:
Just a couple of comments/questions regarding Windows, an OS I really
do not know well :-)...
1) Why did you need
Just to be sure... if you look at all the OpenCV headers, can you see
__stdcall somewhere?
here's the results of a grep:
brucewa...@broo:/usr/local/include/opencv$ grep -ir __stdcall *
cxtypes.h:#define CV_STDCALL __stdcall
highgui.h:#define CV_STDCALL __stdcall
ml.h:#define
how about both? :)
brucewa...@broo:/usr/local/include/opencv$ grep -ir CV_STDCALL *
cxcore.h:typedef IplImage* (CV_STDCALL* Cv_iplCreateImageHeader)
cxcore.h:typedef void (CV_STDCALL* Cv_iplAllocateImageData)(IplImage*,int,int);
cxcore.h:typedef void (CV_STDCALL* Cv_iplDeallocate)(IplImage*,int);
In wrapping a C library, I come across many #define statements that I
need to use elsewhere. When they simply define a constant, I use an
anonymous enum and all is well.
But how would I wrap something like this that shown up in a header
file that i'm cdef extern'ing from:
#define
Thanks Lisandro,
I may just end up declaring each struct like this with a 'pass'
and then implementing the fields on the python side (this is how ctypes does it)
Cheers!
On Wed, Jul 1, 2009 at 3:01 PM, Lisandro Dalcindalc...@gmail.com wrote:
On Wed, Jul 1, 2009 at 3:24 PM, Chris
what about functions defined in a macro where i wont know the return
type in advance?
such as:
#define CV_NEXT_GRAPH_EDGE( edge, vertex ) \
(assert((edge)-vtx[0] == (vertex) || (edge)-vtx[1] == (vertex)), \
(edge)-next[(edge)-vtx[1] == (vertex)])
Thanks Stefan!
On Thu, Jul 2, 2009 at 12:32 AM, Stefan Behnelstefan...@behnel.de wrote:
Hi,
Chris Colbert wrote:
I'm thinking this may be what the new array type is for, but i'm not sure.
say I have a C struct which I wrap as a class:
#mycfile.h
struct Foo
{
int* data[32
+1
On Fri, Jul 24, 2009 at 11:21 AM, Lisandro Dalcindalc...@gmail.com wrote:
On Fri, Jul 24, 2009 at 8:53 AM, Robert
Bradshawrober...@math.washington.edu wrote:
This feels a lot like C++ operator overloading...
I'm not a fan of _as_parameter_, but maybe an as foo_t kind of
attribute that it
Well, I have a dreamhost server just sitting around. It only hosts my
blog (which is mostly non-existant), but I have ample bandwidth and
space.
It is however, on a shared box so the performance isnt stellar.
The Cython list seems to be lightweight however, so if you want to
give it a try (and
I'm working on a paper and need to include a citation for Cython, is
there a preferred citation, or should I use this entry I found in the
sage archives?
@manual{cython,
Author = {Stefan Behnel, Robert Bradshaw, and Dag Sverre Seljebotn },
Title = {Cython: C-Extensions for Python},
note =
},
url= {http://www.cython.org},
year = 2009
}
On Mon, Aug 24, 2009 at 4:13 PM, Robert
Bradshawrober...@math.washington.edu wrote:
On Mon, 24 Aug 2009, Chris Colbert wrote:
I'm working on a paper and need to include a citation for Cython, is
there a preferred citation
I'm no expert, but I would type your input arguments and use the float
versions of the math.h functions since your dtypes are floats.
On Tue, Aug 25, 2009 at 11:19 AM, Adam
Ginsburgadam.ginsb...@colorado.edu wrote:
From: Robert Bradshaw rober...@math.washington.edu
Subject: Re: [Cython] Linking
with regards to replacing weave, would it be possible to just use a
function decorator?
i.e something like:
@cythonize
def trivial_func(int i):
cdef int j
j = i + 1
return j
I particularly like the thought of this over weave so that I don't
have to switch gears in brain from
wait, scratch that idea, that would throw python syntax errors all
over the place.
I was too quick on the send button...
On Tue, Aug 25, 2009 at 5:49 PM, Chris Colbertsccolb...@gmail.com wrote:
with regards to replacing weave, would it be possible to just use a
function decorator?
i.e
Ah, I'm having a stupid day.
I need to use the same name for the .so as the source file. Doh!
Chris
On Tue, Sep 29, 2009 at 3:15 PM, Chris Colbert sccolb...@gmail.com wrote:
I'm getting the following error when import a simple cython extension module:
ImportError: dynamic module does
I'm getting the following error when import a simple cython extension module:
ImportError: dynamic module does not define init function
(initcythonsuperquadricfit)
the following is how i built the module... doesnt seem there is a problem:
brucewa...@broo:~/Desktop/object_reconstruction$ cython
Normally, when I'm hitting a road block with numpy performance, I port
that section to cython and typically see an order of magnitude
increase in speed. (this is without disabling bounds checking) In my
current case, I'm seeing a slowdown of 2x (with boundschecking
disabled) and I'm pretty sure
Dag,
HTML was too big to attach to the list email, so I sent it to your
personal email.
Thanks for taking a look!
Chris
On Tue, Sep 29, 2009 at 4:42 PM, Chris Colbert sccolb...@gmail.com wrote:
Dag,
Html is attached, all that garbage at the bottom in commented out via
a docstring (i
-fwrapv -O2 -Wall -fno-strict-aliasing
-I/usr/local/lib/python2.6/dist-packages/numpy/core/include/numpy
-I/usr/include/python2.6 -o superquadricfit.so superquadricfit.c
they both yield the same result
On Tue, Sep 29, 2009 at 4:46 PM, Chris Colbert sccolb...@gmail.com wrote:
Dag,
HTML
or better yet, which pow function is numpy using?
On Tue, Sep 29, 2009 at 6:21 PM, Chris Colbert sccolb...@gmail.com wrote:
No, the python ** gets translated to a pow statement by cython.
I think the issue is that for some reason, i'm getting stuck in the
gcc slow pow function
if i let
per loop
over 6x improvement just by avoid a few measly pow statements...
anyone know why i'm stuck in slowpow?
On Tue, Sep 29, 2009 at 6:15 PM, Sturla Molden stu...@molden.no wrote:
Sturla Molden skrev:
Chris Colbert skrev:
and within that loop it is these statements that take the bulk
tried that already...
no difference...
On Tue, Sep 29, 2009 at 6:33 PM, Robert Kern robert.k...@gmail.com wrote:
On 2009-09-29 11:21 AM, Chris Colbert wrote:
or better yet, which pow function is numpy using?
double pow(double, double) from math.h .
--
Robert Kern
I have come
Molden stu...@molden.no wrote:
Chris Colbert skrev:
No, the python ** gets translated to a pow statement by cython.
I think the issue is that for some reason, i'm getting stuck in the
gcc slow pow function
if i let e2 and e1 be 1 and replace f**2 (which would call pow) with f*f,
my
.
Cheers,
Chris
On Tue, Sep 29, 2009 at 7:11 PM, Chris Colbert sccolb...@gmail.com wrote:
my big issue here is that these two lines of code, are taking more
time to execute than the entire function as a pure numpy
implementation. And numpy is using the same calls to pow in the
background...
i
:
Chris Colbert skrev:
No, the python ** gets translated to a pow statement by cython.
I think the issue is that for some reason, i'm getting stuck in the
gcc slow pow function
if i let e2 and e1 be 1 and replace f**2 (which would call pow)
with f*f,
my execution time drops
, 2009, at 12:03 PM, Chris Colbert wrote:
Actually, yes. The exponents are done specifically in that way to
force the sign of the end value.
I suppose i could just call abs() on it though
I'm sure that abs would be faster than pow, though it's not the
squaring that's expensive
using something similar to ctypes dlopen?
I would like to be able to create a wrapper for a library that can
built on the client machine without the necessity of the target
libraries being present.
Then, upon import of the library, the library would check for the
presence of the .so's and raise
Sverre Seljebotn
da...@student.matnat.uio.no wrote:
Chris Colbert wrote:
using something similar to ctypes dlopen?
I would like to be able to create a wrapper for a library that can
built on the client machine without the necessity of the target
libraries being present.
Consider having
cytypestest.c
$python
import cytypestest
1255008817
On Thu, Oct 8, 2009 at 3:05 PM, Chris Colbert sccolb...@gmail.com wrote:
Ok, tried both of those methods, and they pass cython compilation, but
then I get this error from gcc:
brucewa...@broo:~/Desktop$ gcc -shared -pthread -fPIC -fwrapv -O2
Since I have a cimport numpy as np at the top of my cython file,
array1.shape == array2.shape
is only true if array1 IS array2 because .shape return the npy_intp*
pointer to the shape array.
Is there a way for me check if the values in the shape array are equal
(ala python) without having to
Fantastic!
Thanks!
On Fri, Oct 9, 2009 at 8:17 AM, David Warde-Farley d...@cs.toronto.edu wrote:
On 8-Oct-09, at 7:38 PM, Chris Colbert wrote:
Since I have a cimport numpy as np at the top of my cython file,
array1.shape == array2.shape
is only true if array1 IS array2 because .shape
for example if I have something like this:
cimport numpy as np
cdef void foo(np.ndarray arr):
do stuff
def bar(np.ndarray arr):
foo(arr)
is arr getting passed by value or by reference?
When I wrap other C libraries, I have to do a foo(cobject) to pass
cobject by
I can't connect from germany.
just an FYI
Cheers,
Chris
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
so I have this function: (the print statements are just for debugging)
cdef np.npy_intp* clone_array_shape(np.ndarray arr):
# the proper way to do this would be to use malloc
# to create a new npy_intp* array of the proper size
# but then we would have to track it and make a call to
Ah, that would explain it.
Thanks!
On Mon, Oct 12, 2009 at 10:11 PM, Sturla Molden stu...@molden.no wrote:
Chris Colbert skrev:
i cant for the life of me, figure out where the error is coming in?
Does anyone see it?
You are returning a pointer to local arrays. The pointer is invalid when
Ok, I gotcha. My lack of formal programming training is on display today :)
Thanks Sturla and Robert!
Chris
On Mon, Oct 12, 2009 at 10:12 PM, Robert Kern robert.k...@gmail.com wrote:
On 2009-10-12 15:00 PM, Chris Colbert wrote:
so I have this function: (the print statements are just
line 317 in numpy.pxd for Cython 11.3
bint PyArray_ISISCONTIGUOUS(ndarray m)
double IS in that definition.
Cheers,
Chris
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
On Tue, Oct 27, 2009 at 10:16 PM, Sturla Molden stu...@molden.no wrote:
Stéfan van der Walt skrev:
As a side note, it may be safer to use the definitions of npy_intp and
npy_uintp from the numpy header, rather than Py_ssize_t and Py_size_t.
In some earlier versions of Python (e.g., 2.4),
#--
# foo.py
#--
from decorator import docdeco
@docdeco('''docstring goes here''')
def bar():
pass
On Thu, Oct 29, 2009 at 1:32 PM, Chris Colbert sccolb...@gmail.com wrote:
Hi,
I didn't get a response on Cython-users, so i thought I might try here.
I tried modifying
What was the rationality behind having to explicitly declare C
division, versus explicitly declaring python division?
Just curious.
Cheers!
On Mon, Nov 9, 2009 at 5:40 PM, Dag Sverre Seljebotn
da...@student.matnat.uio.no wrote:
Hi all,
Why is it necessary to decorate a pure cdef with
is there an error in that table:
'''
cdivision True/False Version = 0.12
If set to True, Cython will adjust the remainder and quotient
operators C types to match those of Python ints (which differ when the
operands have opposite signs) and raise a ZeroDivisionError when the
right operand is
I noticed you just changed the version signature too:
Version 0.12
Does that mean we can't turn that off in = 0.12, or must we just
explicitly declare it?
On Mon, Nov 9, 2009 at 7:54 PM, Robert Bradshaw
rober...@math.washington.edu wrote:
On Nov 9, 2009, at 10:45 AM, Chris Colbert wrote
AFAIK, you only have to INCREF the dtype. And only for numpy array
creation routines that take a dtype object as an argument (they
steal a dtype reference, which is why you have to incref it).
On Sun, Nov 15, 2009 at 2:09 AM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
I've been spending
AH I see ok. I should have read more carefully (a little late here).
When you commented out the INCREF on the datat, did you also comment
out PyArray_Set_BASE? If not, that may have been causing the problem.
If you set the base without INCREF'ing the data, then numpy will
DECREF that data when
I forgot a disclaimer:
This is all to the best of my knowledge. I'm sure one of the awesome
Cython devs will jump in and correct me ;)
On Sun, Nov 15, 2009 at 3:04 AM, Chris Colbert sccolb...@gmail.com wrote:
AH I see ok. I should have read more carefully (a little late here).
When you
1 - 100 of 102 matches
Mail list logo
