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

[Ralf Gommers]

On Wed, Dec 27, 2017 at 2:40 AM, Ilhan Polat <ilhanpolat at gmail.com> wrote:

> 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?
>

Just wondering about the tradeoff between deprecating + having a new
function with arguments in the same order as LAPACK, vs. just appending the
keywords to the existing function. The latter case would need a thin Python
function in lapack.py, but unless that hurts performance significantly I'm
not sure that's much of an issue.

Ralf




>
>
>
> 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
>>
>
>
> _______________________________________________
> 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/20180113/f9e256c1/attachment.html>