<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_8630161255500383215gmail-pl-k">=</span> _np.deprecate(cgegv, <span class="m_8630161255500383215gmail-pl-v">old_name</span><span class="m_8630161255500383215gmail-pl-k">=</span><span class="m_8630161255500383215gmail-pl-s"><span class="m_8630161255500383215gmail-pl-pds">'</span>cgegv<span class="m_8630161255500383215gmail-pl-pds">'</span></span>, <span class="m_8630161255500383215gmail-pl-v">message</span><span class="m_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="HOEnZb"><div class="h5"><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">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><br></div></div>