Dag Sverre Seljebotn wrote: > Robert Bradshaw wrote: >> On Nov 3, 2009, at 12:45 AM, Dag Sverre Seljebotn wrote: >> >> >>> Robert Bradshaw wrote: >>> >>> >>>> There's >>>> another regression, "cdef int complex" doesn't work anymore (our >>>> structs used to support this, as does gcc, even if it's non-c99). >>>> >>> Turns out this broke nearly all my own code :-( I'll give a proper >>> solution a go. >>> >> >> Thanks! It think it should be pretty easy (probably can use the type >> name, rather than the math postfix marker to name the methods...) >> > I fixed the basic case of > > ctypedef double mydouble > print some_mydouble * some_complex > > however external ctypedefs will still raise errors. > > It's not easy; nearly all calls rely on widest_type to decide their > signature, and widest_type information is unavailable. I'll start a > new thread. I didn't start a new thread, it quickly degraded to rehashing. But in the specific case of complex, the problem is:
a) The only reason stuff like "a * b" even works for external typedefs is because this can mean *different things* to the C compiler and Cython. I.e. to Cython "a" may be the widest type and to the C compiler "b" may be the widest type, but "a * b" is output anyhow so it doesn't matter. b) For complex types, with "__pyx_c_mul_mytype(a, b)", Cython defines the widening behaviour (and Cython is wrong!) I guess it's the same issue that we're facing with division. This is the kind of trouble we get for half-way allowing something impossible... Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
