[Numpy-discussion] Release blockers for 1.4.0 ?

josef.pktd@gmai... josef.pktd@gmai...
Mon Dec 7 22:59:33 CST 2009


On Mon, Dec 7, 2009 at 11:22 PM, David Cournapeau
<david@ar.media.kyoto-u.ac.jp> wrote:
> josef.pktd@gmail.com wrote:
>> On Mon, Dec 7, 2009 at 1:24 PM, Charles R Harris
>> <charlesr.harris@gmail.com> wrote:
>>
>>> On Mon, Dec 7, 2009 at 11:16 AM, Charles R Harris
>>> <charlesr.harris@gmail.com> wrote:
>>>
>>>> On Mon, Dec 7, 2009 at 10:31 AM, David Cournapeau <cournape@gmail.com>
>>>> wrote:
>>>>
>>>>> On Tue, Dec 8, 2009 at 1:48 AM, Charles R Harris
>>>>> <charlesr.harris@gmail.com> wrote:
>>>>>
>>>>>> On Mon, Dec 7, 2009 at 8:24 AM, David Cournapeau <cournape@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 it is out of the question to set the default to raise - at least
> that not what I suggest. The default up to 1.0.4 was warning, and it was
> unintentionally set to ignored starting at 1.1.0.

warning is no problem, but I haven't figured out what the pattern is
for repeated warnings.

When I do the same zero division several times, I only get the warning
the first time, after that no warning is printed anymore. I don't know
about the scope of the non-printing. If it is globally, so that only
the first warning is printed, then it won't really help in detecting
errors. ?

Josef

>>> import numpy as np
>>> np.seterr('warn')
{'over': 'ignore', 'divide': 'ignore', 'invalid': 'ignore', 'under': 'ignore'}
>>> np.arange(3)/0
__main__:1: RuntimeWarning: divide by zero encountered in divide
array([0, 0, 0])
>>> np.arange(3)/0
array([0, 0, 0])




>
>> 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.
>>
>
> I think it depends on the use-cases: I can see why in stats it may be
> useful to set them to ignore, but for linear algebra, for example, nan
> is almost always a bug in the code somewhere.
>
> Note also that the default can be overriden temporarily - we should
> actually have a context manager so that it becomes easy to use it safely
> if python >= 2.6 is an option.
>
> cheers,
>
> David
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>


More information about the NumPy-Discussion mailing list