[Numpy-discussion] Release blockers for 1.4.0 ?

[josef.pktd at gmail.com]

On Mon, Dec 7, 2009 at 1:24 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Mon, Dec 7, 2009 at 11:16 AM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
>>
>>
>> On Mon, Dec 7, 2009 at 10:31 AM, David Cournapeau <cournape at gmail.com>
>> wrote:
>>>
>>> On Tue, Dec 8, 2009 at 1:48 AM, Charles R Harris
>>> <charlesr.harris at gmail.com> wrote:
>>> >
>>> >
>>> > On Mon, Dec 7, 2009 at 8:24 AM, David Cournapeau <cournape at gmail.com>
>>> > wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> There are a few issues which have been found on numpy 1.4.0, which
>>> >> worry
>>> >> me:
>>> >>
>>> >> # 1317: segfaults for integer division overflow
>>> >> # 1318: all FPU exceptions ignored by default
>>> >>
>>> >> #1318 worries me the most: I think it is a pretty serious regression,
>>> >> since things like this go unnoticed:
>>> >>
>>> >> x = np.array([1, 2, 3, 4]) / 0 # x is an array of 0, no warning
>>> >> printed
>>> >>
>>> >
>>> > Hasn't that always been the case? Unless we have a way to raise
>>> > exceptions
>>> > from ufuncs I don't know what else we can do.
>>>
>>> No, it is a consequence of errors being set to ignored in numpy.ma:
>>>
>>>
>>> http://projects.scipy.org/gitweb?p=numpy;a=blob;f=numpy/ma/core.py;h=f28a5738efa6fb6c4cbf0b3479243b0d7286ae32;hb=master#l107
>>>
>>> So the fix is easy - but then it shows many (> 500) invalid values,
>>> etc... related to wrong fpu handling (most of them are limited to the
>>> new polynomial code, though).
>>>
>>
>> Umm, no. Just four, and easily fixed as I explicitly relied on the
>> behaviour. After the fix and seterror(all='raise'):
>>
>
> To be specific, it was a true divide and I relied on nan being returned. I
> expect many of the remaining failures are of the same sort.

if seterr raise also raises when the calculations are done with
floating point, then it's not really useful. I think there is a lot of
code in scipy.stats that relies on returning nan for 0/0 and inf for
x/0, x!=0 . Instead of partial answers, we would get exceptions in
lots of cases, another common example is np.corrcoef

I think this is more a problem with the silent casting of nan and inf
to 0 for integers (which I dislike for a long time), not a problem
with floating point operations.

>>> np.seterr(all='raise')
{'over': 'warn', 'divide': 'warn', 'invalid': 'warn', 'under': 'warn'}
>>> np.arange(3).astype(int)/0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FloatingPointError: divide by zero encountered in divide
>>> np.arange(3).astype(float)/0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FloatingPointError: divide by zero encountered in divide
>>>

>>> np.corrcoef(np.ones(3),np.arange(3))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Programs\Python25\Lib\site-packages\numpy\lib\function_base.py", line
 1981, in corrcoef
    return c/sqrt(multiply.outer(d,d))
FloatingPointError: invalid value encountered in divide
>>> np.seterr(all='ignore')
{'over': 'raise', 'divide': 'raise', 'invalid': 'raise', 'under': 'raise'}
>>> np.corrcoef(np.ones(3),np.arange(3))
array([[ NaN,  NaN],
       [ NaN,   1.]])

>
> Chuck
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>