Travis Oliphant wrote:
>>     Personally I think that the default error mode should be tightened
>>     up.
>>     Then people would only see these sort of things if they really care
>>     about them. Using Python 2.5 and the errstate class I posted earlier:
>>
>>         # This is what I like for the default error state
>>         numpy.seterr (invalid='raise', divide='raise', over='raise',
>>         under='ignore')
>>
>>
>> I like these choices too. Overflow, division by zero, and sqrt(-x) are 
>> usually errors, indicating bad data or programming bugs. Underflowed 
>> floats, OTOH, are just really, really small numbers and can be treated 
>> as zero. An exception might be if the result is used in division and 
>> no error is raised, resulting in a loss of accuracy.
>>
>>     
>
> I'm fine with this.  I've hesitated because error checking is by default 
> slower.  But, I can agree that it is "less surprising" to new-comers.  
> People that don't mind no-checking can simply set their defaults back to 
> 'ignore'
>
>   
Great.

One thing we may want to do (numarray had this), was add a pseudo 
argument 'all', that allows you to set all of the values at once. Then 
if you want the full-bore, ignore-all-errors computation (and your using 
2.5 and "from __future__ import with_statement") you can just do:

with errstate(all='ignore'):
    # computation here
# back to being picky

-tim



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Reply via email to