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? -- Lisandro Dalcin --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
