[SciPy-Dev] adding chkfinite flags to linalg functions

[josef.pktd at gmail.com]

On Sat, Aug 27, 2011 at 4:36 AM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> On Fri, Aug 26, 2011 at 10:24 PM, Bruce Southey <bsouthey at gmail.com> wrote:
>>
>> On 08/26/2011 02:41 PM, Robert Kern wrote:
>> > On Fri, Aug 26, 2011 at 14:30, Bruce Southey<bsouthey at gmail.com>  wrote:
>> >> On 08/26/2011 02:09 PM, Matthew Brett wrote:
>> >>> Hi,
>> >>>
>> >>> On Fri, Aug 26, 2011 at 11:45 AM, Bruce Southey<bsouthey at gmail.com>
>> >>>  wrote:
>> >>>> On 08/26/2011 12:02 PM, Christopher Jordan-Squire wrote:
>> >>>>> Breaking it into two steps has its own issues associated with it as
>> >>>>> well. Then the user must verify their own inputs before passing them
>> >>>>> to scipy linalg methods. If I understand your suggestion correctly.
>> >>>> That is exactly what your patch is doing because people will misuse
>> >>>> that
>> >>>> argument just because they perceive it as faster.
>> >>> I object to this objection.
>> >>>
>> >>> There's a long tradition of letting people do dangerous things if they
>> >>> want to.  Here the option is sensibly labeled and it's not the
>> >>> default.
>> >> So why not have the patch remove all the calls to asarray_chkfinite()?
>> > Because we want the *default* to be safe for all inputs. We want to
>> > *allow* people to avoid those checks when they have extra information
>> > about the inputs. Adding a flag is a more convenient way to do this
>> > than any other alternative.
>>
> OK, so this idea seems to be getting a positive reception. The thing that
> still needs to be resolved is whether to call the keyword chkfinite or
> check_finite. I have a slight preference for the latter, because it's more
> readable (googling a a keyword seems less important).
>
>>
>> You and others are totally ignoring the author has stated (without
>> example) that there is a major roadblock when that assumption is wrong.
>>
>> I am very aware of that many functions will provide something even if
>> the input was not correct. So I agree with Matthew about letting people
>> live dangerously as the output will tell them that something was wrong.
>> That means there should be no need for asarray_chkfinite() here.
>
> It's not just that functions may return incorrect results; they may hang in
> an infinite loop, or crash inside a lapack call for example. Removing
> asarray_chkfinite() is not possible. In addition it would break backwards
> compatibility.

Crashing or hanging makes this quite dangerous to have in a library
package. I'm all in favor of living dangerously and do ex-post checks
if something is wrong in the style of try ... except.

But having python crash after some long calculations or never return is no fun.
scipy had crashing on wrong inputs in ndimage, and on some machines or
with some version combinations some optimizers never return.

Cheers,

Josef

>
> Cheers,
> Ralf
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>