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

[Ilhan Polat]

Most of them would indeed just gain new keywords xxgvd, xxgv, and so on.
These would only get lwork and liwork keywords. No deprecations needed.

?(sy/he)evr on the other hand not only gets these extra keywords but also
would gain two more output arguments which is actually the reason for this
thread. So fortunately the amount of deprecation is "a few"~
ssyevr/dsyevr/cheevr/zheevr so far.

These are used in the regular case of scipy.linalg.eigh and was causing
problems due to unoptimized lwork values. Also they were not completely
exposed.hence the new ouput args.

I would like to start a separate discussion about the deprecation of
keywords "eigvals" and "turbo" via a decorator later once this is done.

 Because now we are able to give "eig_range" as an input if need be as a
new functionality. And "eigvals" does not correspond to giving an index
range say, "eig_index". But that will have to wait until this surgery on
the LAPACK side.



On Jan 13, 2018 09:31, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:

>
>
> 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
>>
>>
>
> _______________________________________________
> 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/690cbf14/attachment-0001.html>