Sturla Molden <sturla.mol...@gmail.com> wrote: > Dave Hirschfeld <novi...@gmail.com> wrote: > >> Even if lapack_lite always performed the isfinite check and threw a python >> error if False, it would be much better than either hanging or segfaulting >> and >> people who care about the isfinite cost probably would be linking to a fast >> lapack anyway. > > +1 (if I have a vote) > > Correctness is always more important than speed. Segfaulting or hanging > while burning the CPU is not something we should allow "by design". And > those who need speed should in any case use a different lapack library > instead. The easiest place to put a finiteness test is the check_object > function here: > > https://github.com/numpy/numpy/blob/master/numpy/linalg/lapack_litemodule.c > > But in that case we should probably use a macro guard to leave it out if > any other LAPACK than the builtin f2c version is used.
It seems even the more recent (3.4.x) versions of LAPACK have places where NANs can cause infinite loops. As long as this is an issue it might perhaps be worth checking everywhere. http://www.netlib.org/lapack/bug_list.html The semi-official C interface LAPACKE implements NAN checking as well: http://www.netlib.org/lapack/lapacke.html#_nan_checking If Intel's engineers put NAN checking inside LAPACKE it probably were for a good reason. Sturla _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
