[SciPy-dev] tagging 0.7rc1 this weekend?
Tue Dec 2 21:48:55 CST 2008
On Tue, Dec 2, 2008 at 1:52 AM, Tiziano Zito <firstname.lastname@example.org> wrote:
> #800 : numpy's test_poly1d_nan_roots is broken if scipy.linalg is imported
> #243: linalg.qr to take mode argument
> both have one or more fixes possible, a decision is needed.
> another IMO seriuos problem:
> #794: linalg.eig segmentation fault on unpickled arrays
> there's no fix to that one.
I don't think we are going to be able to close these tickets in time
for the 0.7.0 release, but I am not sure whether they should be
considered release blockers. If you disagree, please let me know.
#800 -- I think we should leave scipy as is and consider this a numpy
bug and fix numpy (i.e., use asarray_chkfinite in numpy.linalg.eig)
#243 -- I think that we should make some changes to qr, but I don't
think there is a general agreement on what we should do. There is
another thread about this, which I will look at again.
#794 -- I am not sure what to do about this, but since pickling arrays
is discouraged I don't think we should hold the release for this. Of
course, it would be great if you could resolve this in the next few
> #630: Support for generalized symmetric eigenvalue problem in SciPy
> can be closed.
Please close this ticket. Your account (tzito) should now have
permission. If not, please let me know.
> #593: flapack.error: ((lwork==-1) || (lwork>=MAX(1,8*n))) failed for 3rd keyword lwork
> can be closed.
Please close this ticket.
> #632: Matrix gallery aka test matrices
> should be scheduled for 0.8 (I also have some code for that).
Please feel free to take this ticket. I for one would be interested
in seeing this in 0.8.
> #585: scipy.linalg.pinv() returns array when input is matrix
> the fix seems easy in this case, but I think a decision is needed.
I think everything should be an array (i.e., we should remove
matrices), so I would rather leave this as is. But I am sure that
many people will disagree with me....
> #492: Problem in linalg.svd ?
> no fix. (but does the problem still exists?)
Not sure. But I don't think this should hold up the release.
> I can work on some of these tickets if needed.
While I don't think that any of these things constitute grounds for
postponing the release candidate, I would love to see as many tickets
closed as possible. If you have any other tickets that should be
reviewed, please let us know.
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
More information about the Scipy-dev