On Apr 12, 2010, at 2:16 PM, Lisandro Dalcin wrote: > On 12 April 2010 18:04, Robert Bradshaw > <[email protected]> wrote: >> On Apr 12, 2010, at 1:42 PM, Lisandro Dalcin wrote: >> >>> On 12 April 2010 14:14, Robert Bradshaw >>> <[email protected]> wrote: >>>> On Apr 11, 2010, at 4:50 PM, Lisandro Dalcin wrote: >>>> >>>>> See this... >>>>> >>>>> ---------------------------------------------------------------------- >>>>> File "C:\Users\dalcinl\DEVEL\cython-devel\BUILD\run\cpp >>>>> \complex_int_T446.pyd", >>>>> line ?, in complex_int_T446.__test__.test_arith (line 3) >>>>> Failed example: >>>>> test_arith(29+11j, 5+7j) >>>>> Expected: >>>>> ((-29-11j), (34+18j), (24+4j), (68+258j), (3-2j)) >>>>> Got: >>>>> ((-29-11j), (34+18j), (24+4j), (68+258j), (1-4j)) >>>>> >>>>> It seems that std::complex<int> in MSVC does not work well for >>>>> integrals, operator/() was written with floating types in mind. >>>>> >>>>> What should we do? >>>> >>>> Hmm... I would be OK with complex_int_T446 not testing division >>>> (with >>>> a note). >>> >>> Do you mean a little comment saying this is broken with MSVC? >> >> >> Yep. For non-exact division I could see calling the result undefined, >> but that's not the case here. >> > > Mmm.. Wait a minute... Now this makes me think a bit different ... In > general, we cannot trust std::complex implementations [except GCC, of > course :-)] ... So what about switching to struct-based complexes if > the real-type is integral? Or perhaps better, use an ad-hoc quot() > implementation?
I think the situation with complex types is complicated enough--adding another case for integral vs. floating point types (or just their division) will make things even messier. What we could do is let C++ behave like C and use the structs unless <complex> is involved. Note that the user can control this with the CYTHON_CCOMPLEX macro as well. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
