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

[Ilhan Polat]

I'm secretly working on it :) Hopefully this week I can submit something.

On Jan 20, 2018 06:10, "Ralf Gommers" <ralf.gommers at gmail.com> wrote:

>
>
> 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
>>
>>
>
> _______________________________________________
> 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/83f2b756/attachment.html>