Robert Bradshaw wrote:
> 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'd 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.

Like Carl I have problem with a pedantic flag because it gives two "modes"
to worry about (which mode is this code written in? etc.) and just
headache in general. So I'm much more in favor of a specific pragma for
this (cython.fastdivision), which can be inserted in source visibly as a
decorator (as much for documentation purposes as anything else).

(Then the disagreement boils down to what should be the default value of
that pragma, I suppose.).

Dag Sverre

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

Reply via email to