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

[Ralf Gommers]

On Sat, Jan 13, 2018 at 11:16 PM, Ilhan Polat <ilhanpolat at gmail.com> wrote:

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

Okay, that sounds a lot more sensible / less worrying. Maybe just open a PR
and we'll look at the detailed changes there?

Cheers,
Ralf


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
>>
>>
> _______________________________________________
> 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/20180120/bbf60f55/attachment.html>