[SciPy-dev] Reverting eigh code ?

[Tiziano Zito]

I have added the code for eigh. The corresponding fortran wrappers
have been running without any problems since 6 years in symeig. symeig
has been dowloaded more than 1000 times since its first appearence and
the MDP package (more than 11000 dowloads) depends on it. No bug has
been reported regarding symeig in 6 years.
I feel responsible for the eigh code, so if someone cares to submit a
proper bug report, or a link to a scipy ticket, I would be glad to
also have a look at it. It may be an issue with proper "lwork" size if
using a LAPACK+ATLAS compiled on a different machine to that where the
code is running.
Before submitting the code, I tested it on a debian lenny + system
lapack and atlas, on a windows XP with manually compiled atals 3.8 and
lapack 3.1, and on a MacOsX with enthought python distribution.
Is there a buildbot that we can use for such cases?

tiziano

On Sat, Nov 22, 2008 at 5:18 AM, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Jarrod Millman wrote:
>> On Fri, Nov 21, 2008 at 4:44 PM, David Cournapeau
>> <david at ar.media.kyoto-u.ac.jp> wrote:
>>
>>> If nobody complains within the beta time, I will remove it myself,
>>>
>>
>> Let's give it 24 hours before removing it.  I want to take a look
>> before making a judgment; but, in principle, I would be OK with some
>> *minor* rough edges in the first beta if someone is willing to commit
>> to fixing them before the release candidate.  But the beta should be
>> feature complete so we need to decide whether to remove the eigh code
>> before we tag the release.
>>
>
> I agree with the above principle in general but in that case:
>     - it is a fortran issue, and worse happens in call to external code
> (BLAS/LAPACK)
>     - the feature was added a few days ago (hence nobody really tested
> it, and nobody really depends on it either)
>     - in that precise case, it is hard to know if it is minor or not
> (the problem seems to depend on the LAPACK version; I can't reproduce it
> on every machine I have at hand).
>
> So if the feature is known to break for the beta, it means we will need
> at least two beta. Which I would rather avoid just for that issue,
>
> David
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>