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)? -- Ben
Hello, On Thu, Mar 26, 2009 at 01:41, Ben Mellor <cumber@netspace.net.au> wrote:
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. -- Amaury Forgeot d'Arc
Amaury Forgeot d'Arc wrote:
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
Hello, On Thu, Mar 26, 2009 at 01:41, Ben Mellor <cumber@netspace.net.au> wrote:
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. -- Amaury Forgeot d'Arc
Amaury Forgeot d'Arc wrote:
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
participants (3)
-
Amaury Forgeot d'Arc -
Ben Mellor -
Carl Friedrich Bolz