Robert Bradshaw wrote:
Note also that Danilo did some work on overloaded functions which
could be useful here too.
It may, yes. Is there any documentation about what he actually did? I never
saw any floating around, the related mailing list discussions were rather
sparse (IMHO), and I
Dag Sverre Seljebotn wrote:
I know that it is not an incompatability as such, I just don't like it --
especially as, from the perspective of Python, it is called inverse, and it
is used for that purpose in Sage.
What does NumPy use ~ for? If it is conjugate I could be swayed, but I highly
Stefan Behnel wrote:
Robert Bradshaw wrote:
Note also that Danilo did some work on overloaded functions which
could be useful here too.
It may, yes. Is there any documentation about what he actually did? I never
saw any floating around, the related mailing list discussions were
I have two more things to say about this.
First, support for C++ std::complex and C99 _Complex in Cython would be
great. I recently tried to reimplement scipy.signal.lfilter using
std::complex instead of hand-written complex arithmetics in C89. I got
nearly 400% increase in performance.
Sturla Molden wrote:
Dag Sverre Seljebotn wrote:
I know that it is not an incompatability as such, I just don't like it --
especially as, from the perspective of Python, it is called inverse, and it
is used for that purpose in Sage.
What does NumPy use ~ for? If it is conjugate I could
Sturla Molden wrote:
I have two more things to say about this.
First, support for C++ std::complex and C99 _Complex in Cython would be
Note that C99 complex support is already there since 0.11.2, just make
sure you include complex.h somehow.
Dag Sverre
Chris Colbert wrote:
Given our previous conversation, it will probably be easier to use
ctypes to get the function handles for dynamically loaded libraries
and *somehow* get that function pointer into Cython.
My attempt is like so (for a simple example) but Cython is complaining
during
Dag Sverre Seljebotn wrote:
Chris Colbert wrote:
Given our previous conversation, it will probably be easier to use
ctypes to get the function handles for dynamically loaded libraries
and *somehow* get that function pointer into Cython.
My attempt is like so (for a simple example) but Cython
I experience this:
Py_ssize_tnp.sqrt(some_float64)
= TypeError: 'numpy.float64' object cannot be interpreted as an index
However
a) intnp.sqrt(...) works fine, as does long and long long.
b) In Python, int(np.sqrt(...)) and long(np.sqrt(...)) both works fine
Is Py_ssize_t special when it
alright I figured it out, I just dont dereference the function pointer
before calling it. I don't understand why that works though...
At any rate, here is a self contained working example for future googlers
# cytypestest.pyx
import ctypes
libc =
I have used Cython for numerical programming for quite a while. I'd like
to share my experience with you Cython developers. There are two or
three annoying issues I keep encounter, which I hope you can take into
consideration for future tickets.
First, is there any reason why Cython does not
I was just pointing to GCC-specific syntax that perhaps we could use,
I was not actually requesting for it !!!
I really prefer your time being invested in reviewing the patch:
http://trac.cython.org/cython_trac/ticket/398
BTW, What would be better from creating a C99/C++ complex number
from re
On Thu, Oct 8, 2009 at 11:29 AM, Sturla Molden stu...@molden.no wrote:
First, is there any reason why Cython does not recognize const and
restrict?
Probably it is just the lack of time to implement it. This also annoys
me. But I remember Dag was interested in supporting 'restrict'.
In
On Wed, Oct 7, 2009 at 10:43 PM, Peter Alexander vel.ac...@gmail.com wrote:
On Thu, Oct 8, 2009 at 1:13 AM, William Stein wst...@gmail.com wrote:
Hi,
1. I rsynced all the servers from the old sagemath to the new virtual
machine. If you put a line like this in your /etc/hosts file
Lisandro Dalcin wrote:
BTW, What would be better from creating a C99/C++ complex number
from re im parts: use a macro or a inline function as we currently
have?
I don't know much about cython, so perhaps I misunderstand the question. In
general, inline functions are _much_ preferred over
On Oct 8, 2009, at 7:29 AM, Sturla Molden wrote:
I have used Cython for numerical programming for quite a while. I'd
like
to share my experience with you Cython developers. There are two or
three annoying issues I keep encounter, which I hope you can take into
consideration for future
On Oct 8, 2009, at 4:54 AM, Dag Sverre Seljebotn wrote:
Stefan Behnel wrote:
Robert Bradshaw wrote:
Note also that Danilo did some work on overloaded functions which
could be useful here too.
It may, yes. Is there any documentation about what he actually
did? I never
saw any floating
Robert Bradshaw wrote:
On Oct 8, 2009, at 6:04 AM, Dag Sverre Seljebotn wrote:
I experience this:
Py_ssize_tnp.sqrt(some_float64)
= TypeError: 'numpy.float64' object cannot be interpreted as an
index
However
a) intnp.sqrt(...) works fine, as does long and long long.
b) In Python,
Sturla Molden wrote:
Dag Sverre's NumPy work allow ndarrays in Python, so declaring
cdef np.ndarray[double, ndim=2, mode=c] U
we could have written U[j,i] instead of Uj[i]. Or uf there was a fast
way of slicing, we could have written
cdef np.ndarray[double, ndim=1, mode=c] Uj
On Oct 8, 2009, at 10:54 AM, Dag Sverre Seljebotn wrote:
Robert Bradshaw wrote:
On Oct 8, 2009, at 6:04 AM, Dag Sverre Seljebotn wrote:
I experience this:
Py_ssize_tnp.sqrt(some_float64)
= TypeError: 'numpy.float64' object cannot be interpreted as an
index
However
a) intnp.sqrt(...)
Robert Bradshaw wrote:
On Oct 8, 2009, at 10:54 AM, Dag Sverre Seljebotn wrote:
Robert Bradshaw wrote:
On Oct 8, 2009, at 6:04 AM, Dag Sverre Seljebotn wrote:
I experience this:
Py_ssize_tnp.sqrt(some_float64)
= TypeError: 'numpy.float64' object cannot be interpreted as an
index
Lisandro Dalcin wrote:
I was just pointing to GCC-specific syntax that perhaps we could use,
I was not actually requesting for it !!!
I really prefer your time being invested in reviewing the patch:
http://trac.cython.org/cython_trac/ticket/398
Robert wrote the support so he'd be much more
On Thu, Oct 8, 2009 at 3:42 PM, Dag Sverre Seljebotn
da...@student.matnat.uio.no wrote:
Lisandro Dalcin wrote:
I was just pointing to GCC-specific syntax that perhaps we could use,
I was not actually requesting for it !!!
I really prefer your time being invested in reviewing the patch:
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
On Thu, Oct 8, 2009 at 5:33 PM, Jason Grout jason-s...@creativetrax.com wrote:
William Stein wrote:
Hi,
1. I rsynced all the servers from the old sagemath to the new virtual
machine. If you put a line like this in your /etc/hosts file
128.208.160.197 sagemath.org trac.sagemath.org
25 matches
Mail list logo
