Re: [Cython] 'with gil:' statement
Wed, 16 Mar 2011 14:10:29 +0100, Dag Sverre Seljebotn wrote: > Ah, right. I guess I agree with disallowing nested "with nogil" > statements for the time being then. Could you make the inner nested "with nogil" statements no-ops instead, if the GIL is already released? Does the Cython compiler keep track if GIL is acquired or not? -- Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] CEP: prange for parallel loops
Mon, 04 Apr 2011 21:26:34 +0200, mark florisson wrote: [clip] > For clarity, I'll add an example: [clip] How about making all the special declarations explicit? The automatic inference of variables has a problem in that a small change in a part of the code can have somewhat unintuitive non-local effects, as the private/ shared/reduction status of the variable changes in the whole function scope (if Python scoping is retained). Like so with explicit declarations: def f(np.ndarray[double] x, double alpha): cdef double alpha = 6.6 cdef char *ptr = something() # Parallel variables are declared beforehand; # the exact syntax could also be something else cdef cython.parallel.private[int] tmp = 2, tmp2 cdef cython.parallel.reduction[int] s = 0 # Act like ordinary cdef outside prange(); in the prange they are # firstprivate if initialized or written to outside the loop anywhere # in the scope. Or, they could be firstprivate always, if this # has a negligible performance impact. tmp = 3 with nogil: s = 9 for i in prange(x.shape[0]): if cython.parallel.first_iteration(i): # whatever initialization; Cython is in principle allowed # to move this outside the loop, at least if it is # the first thing here pass # tmp2 is not firstprivate, as it's not written to outside # the loop body; also, it's also not lastprivate as it's not # read outside the loop tmp2 = 99 # Increment a private variable tmp += 2*tmp # Add stuff to reduction s += alpha*i # The following raise a compilation error -- the reduction # variable cannot be assigned to, and can be only operated on # with only a single reduction operation inside prange s *= 9 s = 8 # It can be read, however, provided openmp supports this tmp = s # Assignment to non-private variables causes a compile-time # error; this avoids common mistakes, such as forgetting to # declare the reduction variable. alpha += 42 alpha123 = 9 ptr = 94 # These, however, need to be allowed: # the users are on their own to make sure they don't clobber # non-local variables x[i] = 123 (ptr + i)[0] = 123 some_routine(x, ptr, i) else: # private variables are lastprivate if read outside the loop foo = tmp # The else: block can be added, but actually has no effect # as it is always executed --- the code here could as well # be written after the for loop foo = tmp # <- same result with nogil: # Suppose Cython allowed cdef inside blocks with usual scoping # rules cdef cython.parallel.reduction[double] r = 0 # the same variables can be used again in a second parallel loop for i in prange(x.shape[0]): r += 1.5 s -= i tmp = 9 # also the iteration variable is available after the loop count = i # As per usual Cython scoping rules return r, s What did I miss here? As far as I see, the above would have the same semantics and scoping as a single-threaded Python implementation. The only change required to make things parallel is replacing range() by prange() and adding the variable declarations. -- Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] CEP: prange for parallel loops
Tue, 05 Apr 2011 12:55:36 +, Pauli Virtanen wrote: [clip] > # Assignment to non-private variables causes a compile-time > # error; this avoids common mistakes, such as forgetting to > # declare the reduction variable. > alpha += 42 > alpha123 = 9 > ptr = 94 Actually, I'm not sure this is absolutely necessary -- life is tough, especially if you are programming in parallel, and there are limits to hand-holding. However, an explicit declaration could be added for turning the error off for the (rare) cases where this makes sense (e.g. setting a shared flag) cdef cython.parallel.shared[double] some_flag -- Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fused Types
Fri, 29 Apr 2011 10:23:55 +0200, mark florisson wrote: [clip] > Ok, branching on the type sounds fine to me. It brings one problem > though: because you cannot declare the variables of your variable type > (the type of say, mystruct.attrib), you will need to do multiple > declarations outside of your branches. So in my example: > > cdef func(struct_t mystruct, int i): > cdef string_t string_var > cdef int int_var > > if typeof(mystruct) is typeof(int): > int_var = mystruct.attrib + i > ... > else: >string_var = mystruct.attrib + i >... > > But this is probably not a common case, so likely not an issue. Are you planning to special-case the "real_t complex" syntax? Shooting from the sidelines, one more generic solution might be, e.g., ctypedef cython.fused_type(A, B) struct_t ctypedef cython.fused_type(float, double, paired=struct_t) real_t ctypedef cython.fused_type(int_t, string_t, paired=struct_t) var_t and just restrict the specialization to cases that make sense. -- Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fused Types
Fri, 29 Apr 2011 11:30:19 +0200, mark florisson wrote: > On 29 April 2011 11:03, Pauli Virtanen wrote: [clip] >> Are you planning to special-case the "real_t complex" syntax? Shooting >> from the sidelines, one more generic solution might be, e.g., > > I'm sorry, I'm not sure what syntax you are referring to. Are you > talking about actual complex numbers? This: On 28 April 2011 23:30, Robert Bradshaw wrote: > OK, I take back what I said, I was looking at the RHS, not the LHS. If > one needs to specialize in this manner, explicitly creating two > branches should typically be enough. The same for casting. The one > exception (perhaps) is "my_fused_type complex." Otherwise it's > starting to feel too much like C++ template magic and complexity for > little additional benefit. That is, declaring a complex type matching a real one. >> ctypedef cython.fused_type(A, B) struct_t >>ctypedef cython.fused_type(float, double, paired=struct_t) real_t >> ctypedef cython.fused_type(int_t, string_t, paired=struct_t) var_t >> >> and just restrict the specialization to cases that make sense. > > The paired means you're declaring types of attributes? No, just that real_t is specialized to float whenever struct_t is specialized to A and to double when B. Or a more realistic example, ctypedef cython.fused_type(float, double) real_t ctypedef cython.fused_type(float complex, double complex) complex_t cdef real_plus_one(complex_t a): real_t b = a.real return b + 1 which I suppose would not be a very unusual thing in numerical codes. This would also allow writing the case you had earlier as cdef cython.fused_type(string_t, int, paired=struct_t) attr_t cdef func(struct_t mystruct, int i): cdef attr_t var if typeof(mystruct) is typeof(int): var = mystruct.attrib + i ... else: var = mystruct.attrib + i ... Things would need to be done explicitly instead of implicitly, though, but it would remove the need for any special handling of the "complex" keyword. -- Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fused Types
Fri, 29 Apr 2011 12:53:06 +0200, mark florisson wrote: [clip] > But if we just allow that for fused types, then couldn't we simply do > > ctypedef cython.fused_type(float, double) real_t > > cdef real_plus_one(real_t complex a): > real_t b = a.real > return b + 1 > > ? Then you don't need to pair anything. Perhaps we could introduce > real_t as a type, just like numeric and floating. So I guess > special-casing complex sounds fine with me. Special-casing for complex sounds ugly to me; "complex float" is a type name in the same way as "long int" is, and writing "real_t complex" feels a bit like writing "int_t long". But of course, if this feature is really only needed for declaring complex variants of real types, then how it is done doesn't matter so much. But, IMHO, such a special casing would be a somewhat weird language feature. -- Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fused Types
Fri, 29 Apr 2011 16:59:22 +0200, mark florisson wrote: [clip] > Hmm, indeed, it's pretty weird. I'm fine with the pairing also, although > I'm still not sure how common this case is, and if we really want to > support it. Wouldn't good old C promotion work for this? e.g. if the > type is either float or double, just declare your variable double? In practice mostly yes I guess; IIRC single-precision arithmetic is not any faster than double precision nowadays anyway. However, (playing the devil's advocate :) (i) Theoretically, someone might also want to write code that works both for "double" and for "long double complex". You probably wouldn't want to use "long double" for the double-precision specialization. (ii) One reason to use floats could be the 2x size advantage. In principle someone might want to deal with huge float and float complex arrays. (Sounds like a somewhat rare use case though.) (iii) If you want to wrap a library that already provides complex float functions in both precisions, having a specialized real type could come handy sometimes. But in practice, I guess the "fused_type(double, double complex)" would be the most common use case. Maybe it's best to wait until enough concrete examples accumulate before implementing anything more --- I guess e.g. the pairing feature wouldn't be too difficult to add if it turns out something like that is really needed. Pauli ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] hg-git shows 25 heads?
On Thu, 07 Jul 2011 15:28:36 +0200, Stefan Behnel wrote: > there's something broken with the repo recently. Even in a fresh > checkout, I see 25 heads, most of which were supposed to be merges into > the master branch (mainly button merges). The github web site doesn't > show these, it only has three branches. > > This keeps me from pushing. A hg pull currently says that it gets 735 > objects *each time*, without any visible changes, and a push says it > would override a changeset. > > Any idea what may have gone wrong? It seems that the Github's automatic merge feature creates hidden branches in the namespace refs/pull/* Git does not fetch these by default unless you tell it to, git fetch origin refs/*:refs/* The hidden branches are there, but you never see them in normal usage, and they are never pulled so they do not take space in clones. But maybe Mercurial's git plugin gets confused because of them? I'm not familiar with how it works, but maybe you can instruct it to track only branches in the default namespace refs/heads/* Pauli ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] hg-git shows 25 heads?
On Thu, 07 Jul 2011 20:10:30 +0200, Dag Sverre Seljebotn wrote: [clip] > 5 minutes of Googling didn't turn up anything... Do you think it would > be a bad idea to simply delete these branches, something like > > git push origin :refs/* That drops *all* branches -- not recommended :) As far as I see, git push origin :refs/pull/* should not break anything. However, depending on how the stuff is set up on the Github side, either the merge button stops working (would be an improvement to the state of matters, IMHO), or alternatively, the branches come back immediately whenever someone views pull requests. So I don't think doing this would help much. Maybe best to ask the Github guys what the heck is their creation doing here, and try to see if hg-git can be made to work properly. Pauli ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] N-d arrays, without a Python object
Hi, # OK, but slow cdef double[:,:] a = np.zeros((10, 10), float) # OK, fast (no Python object) cdef double[10] a # OK, but slow, makes Python calls (-> cython.view array) cdef double[10*10] a_ cdef double[:,:] a = (a_) # not allowed cdef double[10,10] a Small N-d work arrays are quite often needed in numerical code, and I'm not aware of a way for conveniently getting them in Cython. Maybe the recently added improved memoryviews could allow for Python-less N-dim arrays? This may be reinveinting a certain language, but such a feature would find immediate practical use. -- Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Failure with asarray(memoryview) on Python 2.4
Hi, This doesn't work on Python 2.4 (works on >= 2.5): cimport numpy as np import numpy as np def _foo(): cdef double[:] a a = np.array([1.0]) return np.asarray(a) def foo(): print _foo() Spotted when using Cython 1.6 in Scipy. Results to: Python 2.4.6 (#1, Nov 20 2010, 00:52:41) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import fail >>> fail.foo() Traceback (most recent call last): File "", line 1, in ? File "fail.pyx", line 10, in fail.foo (fail.c:1776) print _foo() File "fail.pyx", line 7, in fail._foo (fail.c:1715) return np.asarray(a) File "/usr/local/stow/python-easy-install//lib/python2.4/site-packages/numpy/core/numeric.py", line 235, in asarray return array(a, dtype, copy=False, order=order) File "stringsource", line 366, in View.MemoryView.memoryview.__getitem__ (fail.c:5975) File "stringsource", line 650, in View.MemoryView._unellipsify (fail.c:9236) TypeError: Cannot index with type '' ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Cython 1.6 & compilation failure on MinGW?
Hi,
We ran with Scipy to a compilation failure on MinGW in Cython code:
http://projects.scipy.org/scipy/ticket/1673
interpnd.c:10580: error: initializer element is not constant
interpnd.c:10580: error: (near initialization for
`__pyx_CyFunctionType_type.tp_call')
Can be fixed like this:
...
+static PyObject *__Pyx_PyCFunction_Call_wrap(PyObject *a, PyObject *b,
PyObject *c)
+{
+return __Pyx_PyCFunction_Call(a, b, c);
+}
static PyTypeObject __pyx_CyFunctionType_type = {
PyVarObject_HEAD_INIT(0, 0)
__Pyx_NAMESTR("cython_function_or_method"),
@@ -10577,7 +10581,7 @@ static PyTypeObject __pyx_CyFunctionType_type = {
0,
0,
0,
-__Pyx_PyCFunction_Call,
+__Pyx_PyCFunction_Call_wrap,
0,
0,
0,
...
It's a bit surprising to me that you cannot use the function from the
Python headers as a static initializer on that platform...
--
Pauli Virtanen
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Failure with asarray(memoryview) on Python 2.4
Hi, 11.06.2012 21:16, mark florisson kirjoitti: [clip] > Yeah, there was some weird bug with PyIndex_Check() not operating > properly. Could you retry with the latest master? Doesn't seem to work in 5a0effd0 :( Traceback (most recent call last): File "", line 1, in ? File "fail.pyx", line 10, in fail.foo (fail.c:1807) print _foo() File "fail.pyx", line 7, in fail._foo (fail.c:1747) return np.asarray(a) File "/usr/local/stow/python-easy-install//lib/python2.4/site-packages/numpy/core/numeric.py", line 235, in asarray return array(a, dtype, copy=False, order=order) File "stringsource", line 366, in View.MemoryView.memoryview.__getitem__ (fail.c:6019) File "stringsource", line 650, in View.MemoryView._unellipsify (fail.c:9199) TypeError: Cannot index with type '' Cheers, Pauli ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 1.6 & compilation failure on MinGW?
11.06.2012 21:17, mark florisson kirjoitti: [clip] > Thanks, could you provide a pull request? That makes it easier to > merge and assign credit. Ok, I'll try to not only just complain :) BRB, Pauli ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 1.6 & compilation failure on MinGW?
11.06.2012 21:17, mark florisson kirjoitti: [clip] > Thanks, could you provide a pull request? That makes it easier to > merge and assign credit. Ok, this one seemed to already have been fixed in Cython master. Pauli ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Failure with asarray(memoryview) on Python 2.4
11.06.2012 21:23, Pauli Virtanen kirjoitti: > Hi, > > 11.06.2012 21:16, mark florisson kirjoitti: > [clip] >> Yeah, there was some weird bug with PyIndex_Check() not operating >> properly. Could you retry with the latest master? > > Doesn't seem to work in 5a0effd0 :( [clip] Uhh, Numpy header arrayobject.h -> npy_common.h contains this #if (PY_VERSION_HEX < 0x0205) ... #undef PyIndex_Check #define PyIndex_Check(op) 0 ... which nicely overrides the fixed PyIndex_Check defined by Cython. Time to fix that, I guess. I don't see reasonable ways to work around this in Cython... Pauli ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Refcount error with fused types in classes
Hi, Here's a snippet demonstrating a refcount error with fused types inside classes: -8<- cimport cython ctypedef fused some_t: int double class Foo(object): def bar(self, some_t x): pass cdef extern from "Python.h": int Py_REFCNT(object) def main(): x = Foo() print "before:", Py_REFCNT(x) x.bar(1.0) # spuriously increments refcount of `x` print "after: ", Py_REFCNT(x) -----8<- -- Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Refcount error with fused types in classes
Hi, 17.03.2013 18:51, mark florisson kirjoitti: [clip] > Thanks, I pushed a fix here: https://github.com/markflorisson88/cython > (fd4853d202b13a92). Thanks. You beat me to this, I just arrived at the same fix :) Cheers, Pauli ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Refcount error with fused types in classes
17.03.2013 19:18, Pauli Virtanen kirjoitti: > Hi, > > 17.03.2013 18:51, mark florisson kirjoitti: > [clip] >> Thanks, I pushed a fix here: https://github.com/markflorisson88/cython >> (fd4853d202b13a92). > > Thanks. You beat me to this, I just arrived at the same fix :) Note that the Py_XDECREF(self->__signatures__) needs to be removed from _dealloc, though. -- Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Shared Cython runtime (was: Upcoming cython/numpy breakage with stride checking)
09.04.2013 22:00, Robert Bradshaw kirjoitti: [clip] > I am curious what percentage of the final .so file is boilerplate. A > huge chunk of the .c code often is, but that consists largely of > specialize macros and inline functions that (ideally) optimize away to > nearly nothing. FWIW, switching from np.ndarray+templating to fused types+memoryviews increased the stripped size of scipy.interpolate.interpnd [1] from 368k to 633k. [1] https://github.com/scipy/scipy/pull/211 -- Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Memory leak of memoryview attributes in cdef subclasses
Hi, 18.09.2013 16:14, Daniel, Bruno kirjoitti: > We encountered memory leaks when using memoryview attributes in cdef > subclasses > in Cython code. They can be avoided by adding a dealloc method setting the > value > of the memoryview attribute to None. The problem does not occur in topmost > cdef classes. > > Here's an example: (See the module docstring on how to compile and run the > example.) Cannot reproduce the failure on Cython 0.19.1. If you are using an earlier version, please try that instead. One bug with memory leaks in cdef classes was fixed in 0.18 IIRC. -- Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Too many instantiations with fused type memoryviews
Hi,
FYI: Cython instantiates fused type routines with memoryview arguments
unnecessarily many times.
Example:
```
ctypedef fused idx_t:
short
long
# Cython 0.20.1 instantiates this function 128 times,
# even though only 2 would be needed
def fubar_128(idx_t[:] a,
idx_t[:] b,
idx_t[:] c,
idx_t[:] d,
idx_t[:] e,
idx_t[:] f,
idx_t[:] g):
print("HALLO")
def fubar_2(idx_t a,
idx_t b,
idx_t c,
idx_t d,
idx_t e,
idx_t f,
idx_t g):
print("HULLO")
```
$ cython cymod.pyx
$ cython --version
Cython version 0.20.1
$ grep -c 'print("HALLO")' cymod.c
128
$ grep -c 'print("HULLO")' _cymod.c
2
The n**m explosion starts to hurt quite quickly when there are several
array arguments and more than one fused type. I think this issue is
also accompanied by some signature resolution bugs (I'll try to come
up with an example case).
Cheers,
--
Pauli Virtanen
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Too many instantiations with fused type memoryviews
08.03.2014 22:40, Stefan Behnel kirjoitti: [clip] > Yes, this is a known problem. The work-around is to ctypedef the > memory view type, not just the dtype. > > http://thread.gmane.org/gmane.comp.python.cython.user/10437 Thanks, I missed that. Re: arguments in the previous thread --- I think it would indeed be better if memoryviews would not invoke cross-product behavior. If scalars work in one way, also arrays should work in the same way. Pauli ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Fused type signature resolution failures
Hi, Here are the fused types + memoryview signature resolution failures I promised earlier (Cython 0.20.1): (A) TypeError: No matching signature - asd.pyx cimport numpy as cnp ctypedef fused value_t: cnp.float32_t cnp.float64_t cpdef foo(value_t x): pass - quux.py import numpy as np import asd asd.foo(np.float32(1.0)) - (B) ValueError: Buffer dtype mismatch, expected 'int64_t' but got 'double' - asd.pyx cimport numpy as cnp ctypedef fused idx_t: cnp.int32_t cnp.int64_t ctypedef fused value_t: cnp.int64_t cnp.float64_t cpdef foo(idx_t[:,:] i, idx_t[:,:] j, value_t[:,:] x): pass - quux.py import numpy as np import asd i = np.zeros((3, 3), np.int64) j = np.zeros((3, 3), np.int64) x = np.zeros((3, 3), np.float64) asd.foo(i, j, x) - (C) Then some nasty platform-dependent failures: https://github.com/scipy/scipy/issues/3461 The relevant code is: https://github.com/scipy/scipy/blob/master/scipy/sparse/_csparsetools.pyx#L202 The code looks nothing special. However, call to `lil_fancy_get` fails with "TypeError: No matching signature found" when the inputs have types with ndarray dtypes: object object object object int32 int32 The failure occurs only on Christoph Gohlke's Win64 build, but not on Linux/OSX/MINGW32. This sounds like some integer size combination issue, but I'm far from sure. Unfortunately, I'm not easily able to isolate/understand what's going wrong here. -- Pauli Virtane ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Too many instantiations with fused type memoryviews
Hi, 22.03.2014 12:08, Stefan Behnel kirjoitti: [clip] >> Re: arguments in the previous thread --- I think it would indeed be >> better if memoryviews would not invoke cross-product behavior. If >> scalars work in one way, also arrays should work in the same way. > > I'm not a fused types user myself, but it seems to me that it's worth > changing this behaviour for 0.21 to better match the most common use cases. > A pull request that implements this certainly won't hurt, if only to get > real-world feedback on the change. > > The work-around for (existing) code that actually wants the cross product > behaviour for memory views (for whatever reason) would then be (I guess) to > use two identical typedefs with different names. This sounds acceptable, > given that the cross product suggests that we are dealing with independent > (i.e. different) kinds of data anyway. I think another argument against the cross-product behavior is that constructs such as cdef idx_t foo and x = y and if idx_t is np.int: # FOO else: # BAR all become ambiguous in the function body, if idx_t is instantiated in several different ways. I can take a look at this today... (Re: Sturla: I *want* a bloatware generator, but a controllable one :) -- Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Too many instantiations with fused type memoryviews
22.03.2014 14:48, Pauli Virtanen kirjoitti: [clip] > I can take a look at this today... Here's one attempt: https://github.com/cython/cython/pull/284 In the long run, I'd like to be able to write code like this: https://github.com/pv/scipy-work/blob/csparsetools-nocrud/scipy/sparse/_csparsetools.pyx with fused types and have it just work. The above change gets it mostly towards the goal, apart from issues with Numpy scalars and numpy boolean arrays. I'll probably look at this later on... -- Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Fused type signature resolution failures
22.06.2014 13:48, Stefan Behnel kirjoitti: [clip] > > (A) [clip] > > asd.foo(np.float32(1.0)) > > I don't actually know how NumPy represents its types at the Python > level, but my guess is that it would be tricky to match these two > without teaching Cython itself something about NumPy (and how it > wraps basic C types here). I'd rather like to avoid that and live > with the above. Agreed, it's probably not possible to properly deal with this without making use of Numpy scalar type object binary layout in some form. On the other hand, `asd.foo(np.array(1.0))` doesn't work either --- maybe the buffer code path does not trigger for scalar values. [clip] >> (B) >> >> ValueError: Buffer dtype mismatch, expected 'int64_t' but got 'double' [clip] > This looks like a bug to me at first sight. This was fixed by my PR #284 that you merged. >> (C) >> >> Then some nasty platform-dependent failures: [clip] > Generally speaking, I think that the signature matching algorithm has some > room for improvements, especially the one that matches Python signatures at > runtime. > > We should take a look at how other implementations do this dispatch. There > are multiple "generic functions" implementations for Python that do similar > things. I agree that there probably is room for improvement, possibly also speed-wise. I'll try to revisit (at some point) the csparsetools Cython implementation to see if there are low-hanging fixes that would be useful there. -- Pauli Virtanen ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
