[Numpy-discussion] Re: seterr changes

[Albert Strasheim]

Hello all

I was just wondering if someone could provide some example code that would
cause an error if invalid is set to 'raise'?

I also noticed that seterr returns the old values. Is this really useful?
Consider its use in an IPython session:

In [184]: N.geterr()
Out[184]: {'over': 'ignore', 'divide': 'ignore', 'invalid': 'ignore',
'under': 'ignore'}

In [185]: N.seterr(over='raise')
Out[185]: {'over': 'ignore', 'divide': 'ignore', 'invalid': 'ignore',
'under': 'ignore'}

I think the following pattern would make sense, but it seems it doesn't work
at present:
 
old=N.geterr()
N.seterr(over='raise')
# so some calculations that might overflow
N.seterr(old)

This currently causes the following error:

Traceback (most recent call last):
  File "<ipython console>", line 1, in ?
  File "C:\Python24\Lib\site-packages\numpy\core\numeric.py", line 426, in
seterr
    maskvalue = ((_errdict[divide] << SHIFT_DIVIDEBYZERO) +
TypeError: dict objects are unhashable

Is this intended? I think it would be useful to be able to restore all the
error states in one go.

Regards,

Albert

> -----Original Message-----
> From: numpy-discussion-admin at lists.sourceforge.net [mailto:numpy-
> discussion-admin at lists.sourceforge.net] On Behalf Of Travis Oliphant
> Sent: 22 April 2006 04:50
> To: tim.hochberg at ieee.org; numpy-discussion
> Subject: [Numpy-discussion] Re: seterr changes
> 
> Tim Hochberg wrote:
> >
> > Hi Travis et al,
> >
> > I started looking at your seterr changes.
> Thank you very much for the help on this.  I'm not an expert on threaded
> code by any means.  In fact, as you clearly point out, I don't eat and
> drink what will work under threaded environments and what wont.  Clearly
> global variables are problematic.  That is the problem with the
> update_use_defaults bit, right?   This is the way it was being managed
> before and I just changed names a bit to use PyThreadState_GetDict for
> the dictionary (it seems possible to use only from C until Python 2.4).
> 
> I say if it only buys 5% on small arrays then it's not worth it as there
> are other fish to fry to make up for that 5% and I agree that tracking
> down threading problems due to a fanagled global variable is sticky.  I
> did not think about the threading issues deeply enough.
> 
> > I'm also curious about the seterr interface. It returns
> > ufunc_values_obj. I'm wasn't sure how one is supposed to pass that
> > back in to seterr,  so I modified seterr to instead return a
> > dictionary. I also modified it so that the seterr function itself has
> > no defaults (or rather they're all None). Instead, any unspecified
> > values are taken from the current error state. Thus
> > seterr(divide="warn") changes only the divide state, leaving the other
> > entries alone.
> Returning an object is a late-in-the-game idea and should be critiqued.
> It can be passed to seterr (an attribute check grabs the actual list ---
> did you want to change it to a dictionary?).  Doesn't a small list have
> faster access than a small dictionary?
> 
> I'll look over your commits and comment later if I think of anything...
> 
> I'm thrilled with your work.
> 
> Best,
> 
> -Travis