On Sat, Apr 30, 2011 at 12:51 AM, Dag Sverre Seljebotn <d.s.seljeb...@astro.uio.no> wrote: > On 04/30/2011 08:39 AM, Robert Bradshaw wrote: >> >> On Fri, Apr 29, 2011 at 3:53 AM, mark florisson >> <markflorisso...@gmail.com> wrote: >>> >>> On 29 April 2011 12:28, Pauli Virtanen<p...@iki.fi> wrote: >>>> >>>> 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. >> >> If we're going to introduce pairing, another option would be >> >> ctypedef fused_type((double complex, double), (float complex, >> float)) (complex_t, real_t) >> >> though I'm not sure I like that either. We're not trying to create the >> all-powerful templating system here, and anything that can be done >> with pairing can be done (though less elegantly) via branching on the >> types, or, as Pauli mentions, using a wider type is often (but not >> always) a viable option. > > Keeping the right balance is difficult. But, at least there's some cases of > needing this in various codebases when interfacing with LAPACK. > > Most uses of templating with Cython code I've seen so far does a similar > kind of "zip" as what you have above (as we discussed on the workshop). So > at least the usage pattern you write above is very common. > > float32 is not about to disappear, it really is twice as fast when you're > memory IO bound. > > Using a wider type is actually quite often not possible; any time the type > is involved as the base type of an array it is not possible, and that's a > pretty common case. (With LAPACK you take the address of the variable and > pass it to Fortran, so using a wider type is not possible there either, > although I'll agree that's a more remote case.) > > My proposal: Don't support either "real_t complex" or paired fused types for > the time being. Then see.
+1, then we can address real need. > But my vote is for paired fused types instead of "real_t complex". > > Dag Sverre > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
