Amaury Forgeot d'Arc wrote: > Hello, > > On Thu, Mar 26, 2009 at 01:41, Ben Mellor <[email protected]> wrote: >> Does anyone know why >> >> lambda x, y: x % y >> >> is being converted to a flow graph as: >> >> v2 = int_mod(x_0, y_0) >> v1 = int_add(v2, [int_mul([int_and([cast_bool_to_int([int_le([int_xor(x_0, >> y_0)], (0))])], [cast_bool_to_int([int_ne(v2, (0))])])], y_0)]) >> >> (v1 is returned) >> >> >> What's wrong with just v1 = int_mod(x_0, y_0)? > > You are looking at the graph of the function: > pypy.rpython.lltypesystem.opimpl.op_int_mod > > The difference is certainly because C and python handle modulus > differently when one argument is negative: > (-5 % 3) returns -2 in C, but 1 with python. > > Now, I don't know whether RPython should absolutely implement python > semantics here. > RPython does not check for overflow for example.
The semantics of % in RPython _are_ the same as in Python. It's just that the semantics of int_mod aren't that of Python, therefore % must be mapped to something more complex. The reason why int_mod has the C semantics is that it makes the life of all backends easier. Cheers, Carl Friedrich _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
