On Mar 10, 2009, at 7:35 PM, Carl Witty wrote:

> I just reported http://trac.cython.org/cython_trac/ticket/229, which
> points out that division and % on cdef ints have C rather than Python
> semantics (for instance, (-1 % 16) is -1 in C, and 15 in Python).
>
> I'm not sure what the right thing to do here is.  Using C semantics
> gives faster code.  Using Python semantics is nicer (whenever I care
> about the difference, I always want Python semantics) but slower, and
> would be confusing to somebody who was coming from C.

Changing this to use Python semantics would actually slow down real  
code in this case. I'm thinking specifically of linear algebra mod n  
(for word sized n) in Sage, but I'm sure there are many other places  
as well. So I'm generally -1 for such a change. I also don't like the  
idea of an new operator (%%), and I think Carl Witty has a good point  
about needing to change the semantics of // as well. Also, I think  
making literals into Python objects by default will be way cumbersome.

> But whatever happens should be prominently documented; I couldn't find
> any mention of the issue in the current docs (although maybe I wasn't
> looking in the right place).

+10

I think this is neither the first nor last issue that will come up  
like this. What I think we should do is have a "-pedantic" flag which  
obeys Python semantics exactly, at the expense of speed. This applies  
to %, //, **, etc. (Overflowing is a separate issue, and I think  
there should be a flag for that too.) Compilation of .py files would  
be, by default, with -pedantic enabled, and compilation of .pyx files  
with it disabled.

If one suspects that something subtle like this is changing your  
algorithm, you can compile with -pedantic and confirm (or deny) your  
suspicions. Also, everything that differs will query this flag in the  
code, making it easy to find and *document* the discrepancies. In  
fact, the annotate feature could even make note of such places.

Thoughts?

- Robert


P.S. As an implementation aside, it can be much faster to write

r = a % b; r += (r < 0) * b

than

r = a % b; if r < 0: r += b

especially if one is doing this in a loop with randomly distributed  
(pos/neg) a.

_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to