<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">?(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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I would like to start a separate discussion about the deprecation of keywords "eigvals" and "turbo" via a decorator later once this is done.</div><div dir="auto"><br></div><div dir="auto"> 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.</div><div dir="auto"><br></div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jan 13, 2018 09:31, "Ralf Gommers" <<a href="mailto:ralf.gommers@gmail.com">ralf.gommers@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 27, 2017 at 2:40 AM, Ilhan Polat <span dir="ltr"><<a href="mailto:ilhanpolat@gmail.com" target="_blank">ilhanpolat@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>The situation, as usual, turns out a bit more involved <br><br></div>In the discussion, <a href="https://github.com/scipy/scipy/issues/6502" target="_blank">https://github.com/scipy/scipy<wbr>/issues/6502</a> Tiziano writes <br><br>"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 <code>scipy.linalg.eigh</code>
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 <code>eigvals</code> to <code>scipy.linalg.eigh</code>. I think that your wrapper is too generic. You should not allow setting from Python the values of things like <code>lwork</code>: a wrong value there and the user can generate a segfault from Python, which is a no-no."<br><br></div>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.,<br>
<br>
cgegv <span class="m_-7409564594699440703m_8630161255500383215gmail-pl-k">=</span> _np.deprecate(cgegv, <span class="m_-7409564594699440703m_8630161255500383215gmail-pl-v">old_name</span><span class="m_-7409564594699440703m_8630161255500383215gmail-pl-k">=</span><span class="m_-7409564594699440703m_8630161255500383215gmail-pl-s"><span class="m_-7409564594699440703m_8630161255500383215gmail-pl-pds">'</span>cgegv<span class="m_-7409564594699440703m_8630161255500383215gmail-pl-pds">'</span></span>, <span class="m_-7409564594699440703m_8630161255500383215gmail-pl-v">message</span><span class="m_-7409564594699440703m_8630161255500383215gmail-pl-k">=</span>_dep_message) <br><br></div>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 <br><br></div>"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"<br><div><div><br></div><div>Would you dis/agree? <br></div></div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>Ralf</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div></div><div><br><br></div></div></div><div class="m_-7409564594699440703HOEnZb"><div class="m_-7409564594699440703h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 25, 2017 at 11:58 PM, <span dir="ltr"><<a href="mailto:pav@iki.fi" target="_blank">pav@iki.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Ilhan Polat kirjoitti tiistai 26. joulukuuta 2017:<br>
[clip]<br>
<span>> I've done a similar thing by freeing out all ins and outs. It seems to me<br>
> that the signature change is inevitable but the question is how to handle<br>
> this?<br>
<br>
</span>New function sounds best, maximally unimaginative new name is probably most appropriate.<br>
<br>
Not sure how well np.deprecate etc python level wrappers work on f2py.<br>
<span><br>
<br>
> 2) It looks like flapack.src.pyf file is getting exceedingly long and<br>
> unstructured. Should we break it apart just like LAPACK documentation?<br>
<br>
</span>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.)<br>
______________________________<wbr>_________________<br>
SciPy-Dev mailing list<br>
<a href="mailto:SciPy-Dev@python.org" target="_blank">SciPy-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/scipy-dev</a><br>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
SciPy-Dev mailing list<br>
<a href="mailto:SciPy-Dev@python.org" target="_blank">SciPy-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/scipy-dev</a><br>
<br></blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
SciPy-Dev mailing list<br>
<a href="mailto:SciPy-Dev@python.org">SciPy-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/scipy-dev</a><br>
<br></blockquote></div></div>