On 13 April 2010 05:17, Greg Ewing <[email protected]> wrote: > Lisandro Dalcin wrote: >> >> This is the Pyrex algorithm: >> >> if type1.rank < type2.rank: >> widest_type = type2 >> elif type1.rank > type2.rank: >> widest_type = type1 >> elif type1.signed < type2.signed: >> widest_type = type1 >> else: >> widest_type = type2 >> >> Below I pasted what the C standard says... IIUC, Pyrex does not follow >> it, right? > > I'm trying to do the best I can. >
Me too! I was just trying to understand your current promotion algorithm and the wording in the standard. >> Otherwise, if the type of the operand with signed integer type can represent >> all of the values of the type of the operand with unsigned integer type, then >> the operand with unsigned integer type is converted to the type of the >> operand with signed integer type. > > This is the part that neither Pyrex nor Cython can follow exactly, > because it requires knowning the actual sizes of the types. E.g. if > int and long are the same size, then unsigned int + long should be > unsigned long, because signed long can't represent all the values > of unsigned int. But if long is wider than int, then it can, so > the result should be signed long. > Yep. > > Pyrex: <unsigned int> + <long> --> <long> > > Cython: <unsigned int> + <long> --> <unsigned long> > > In other words, Pyrex is guessing that long is wider than int, > which will sometimes be wrong. > > But Cython seems to be guessing that anything unsigned is at > least as wide as anything signed, which seems less likely to > be right to me. > OK! Now I see your point: In [1]: from Cython.Compiler.PyrexTypes import * In [2]: widest_numeric_type (c_uchar_type, c_longlong_type) Out[2]: <CNumericType unsigned PY_LONG_LONG> That's clearly wrong (on common platforms) > The only guaranteed correct thing to do would be to treat the > result as being of unknown signedness in these cases, and to > refuse to do anything with it that would require knowing the > signedness (e.g. choosing which Python conversion function to > call). I might consider doing that in a future version. > Or defer C -> Py conversion to C land, where you can use sizeof()... But this would be a bit complicate, we will need to manage the generation of code for binops involving signed and unsigned types... -- 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
