[SciPy-Dev] Restructuring flapack.src.pyf file

Ilhan Polat ilhanpolat at gmail.com
Tue Dec 26 08:40:12 EST 2017


The situation, as usual, turns out a bit more involved

In the discussion, https://github.com/scipy/scipy/issues/6502 Tiziano
writes

"Hi, I am the author of the original wrappers for those LAPACK routines. If
I remember correctly, the reason for hiding the eigenvalues in an interval
option was simply that the original implementation of scipy.linalg.eigh did
not even allow to limit the number of eigenvalues/eigenvectors returned. I
needed only the possiblity to define the indices of the eigenvalues and not
the range, and the result is the option eigvals to scipy.linalg.eigh. I
think that your wrapper is too generic. You should not allow setting from
Python the values of things like lwork: a wrong value there and the user
can generate a segfault from Python, which is a no-no."

and I can see more LAPACK routines that are wrapped along this line. Having
8 more "xxxx_full" and "xxxx_full_lwork" routines doesn't seem to be
elegant though I don't have any alternative yet. Maybe it is OK to have
them for a few versions but I guess it would be nice if we have a parallel
running deprecation plans for this issue. It looks like _np.deprecate works
pretty OK. And we have four deprecations already in lapack.py e.g.,

cgegv = _np.deprecate(cgegv, old_name='cgegv', message=_dep_message)

This will print a deprecation warning when it is called or docstring is
printed. "DeprecationWarning: `dgegv` is deprecated! The `*gegv` family of
routines has been deprecated in LAPACK 3.6.0 in favor of the `*ggev` family
of routines.The corresponding wrappers will be removed from SciPy in a
future release." So I would like to deprecate the routines abouve with a
message

"The *XXXXX family of routines will have a different signature in the
future versions of  SciPy. The new versions are now available as
*XXXXX_full and will eventually replace the original *XXXXX family"

Would you dis/agree?



On Mon, Dec 25, 2017 at 11:58 PM, <pav at iki.fi> wrote:

> Hi,
>
> Ilhan Polat kirjoitti tiistai 26. joulukuuta 2017:
> [clip]
> > I've done a similar thing by freeing out all ins and outs. It seems to me
> > that the signature change is inevitable but the question is how to handle
> > this?
>
> New function sounds best, maximally unimaginative new name is probably
> most appropriate.
>
> Not sure how well np.deprecate etc python level wrappers work on f2py.
>
>
> > 2) It looks like flapack.src.pyf file is getting exceedingly long and
> > unstructured. Should we break it apart just like LAPACK documentation?
>
> If you think that helps it significantly and is worthwhile use of your
> time then why not. (I suspect it's not particularly worthwhile but ymmv.)
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20171226/b8258c4c/attachment.html>


More information about the SciPy-Dev mailing list