On Aug 17, 2008, at 1:08 AM, Dag Sverre Seljebotn wrote:

> Sorry about all the posts, but I just now realized what you are  
> saying....
>
> well:
> - I write an algorithm where I don't care about speed and use  
> negative indices
> - someone else takes it and turns off bounds checking as it doesn't  
> raise any indexerrors, so "why not"?
> - poof!
>
> I think this would be very obscure. The recipe people would tend to  
> follow seems to be "run with bounds checking on, if all the tests  
> pass then you can turn it off". This would break that way of working.

Yep, certainly.

> I vote for a new compiler directive to do this, and then a new  
> higher-level directive including both this and bounds checking.  
> Alternatively, a buffer option allow_negative which is set to True  
> by default.

My conclusion too. I still think we should put the option in a  
buffers namespace. "Flat is better than nested." vs "Namespaces are  
one honking great idea -- let's do more of those!" But the pragma  
doesn't turn of bounds checking for, other objects, e.g. tuples and  
lists (which could be nice to do).

- Robert

>
> Dag Sverre Seljebotn
> -----Original Message-----
> From: Robert Bradshaw <[EMAIL PROTECTED]>
> Date: Sunday, Aug 17, 2008 6:55 am
> Subject: [Cython] Boundchecking question
> To: Cython-dev <[email protected]>Reply-To: cython- 
> [EMAIL PROTECTED]
>
> I've been playing with the (very cool!) buffer stuff Dag did getting
>> ready for the SciPy conference. I've seen a 20% increase in speed not
>> adjusting for negative indices, but making sure the indices are
>> unsigned is a pain (especially if there is arithmetic involved). One
>> proptosal that has been brought up is to make positive integer
>> constants unsigned, which could lead to complications elsewhere and
>> would still require care. Another proposal that I'd like to throw out
>> there is to have negative index realigning part of bounds checking,
>> i.e. negative indices are not checked for if bounds checking is off.
>>
>> Thoughts?
>>
>> - Robert
>>
>> _______________________________________________
>> Cython-dev mailing list
>> [email protected]
>> http://codespeak.net/mailman/listinfo/cython-dev
>>
>
> _______________________________________________
> Cython-dev mailing list
> [email protected]
> http://codespeak.net/mailman/listinfo/cython-dev

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

Reply via email to