[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Eigs again - Success!!
From: |
David Bateman |
Subject: |
Re: Eigs again - Success!! |
Date: |
Thu, 09 Nov 2006 10:07:26 +0100 |
User-agent: |
Thunderbird 1.5.0.7 (X11/20060921) |
John W. Eaton wrote:
> On 4-Nov-2006, David Bateman wrote:
>
> | The fix is a simple 5 line change to xNEUPD.f in ARPACK, to force the M
> | output of xTRSEN to not exceed the original NCONV value. I've reported
> | the error to the maintainers of ARPACK and will see if there is any
> | follow-up. In any case with the above change I can no longer generate
> | the segfault even after millions of iterations of the segtest code.. I
> | attach the ARPACK patch, last version of eigs and the test code for
> | those that are interested.
>
> Any response to that yet? I suppose the worst case would be that we
> would have to distribute a patch for ARPACK with Octave. Would it be
> possible to test for the bug in the configure script?
>
No feedback yet. I don't believe the patch should be distributed with
octave. At worst I think it should go in the distribution deb and rpm
files. I'll deal with that if I don't get any feedback. I hope not to
have to as this would require me to extract a self-contained test case
from my existing example.
Doing a test in the configure file would also need a self contained
example. However, I think I just had bad luck in the example I chose and
that eigs will be useful and fairly safe against segfaults even without
my patch. So I'd prefer not to have the test.
> | Basically, before finally submitting this function I'd like to split
> | eigs up into a number of classes, and use these template classes to
> | allow both sparse and full cases to be treated. So I hope to have
> | something relatively soon. So after 18 months of on again off again work
> | on eigs, I think I finally have something I can be confident in :-)
>
> It would be better if the core of Feigs could be smaller, and if the
> functionality it provides is also more easily available from
> liboctave, but that's not essential.
>
I'm working on making it smaller, but the code developed rather
chaotically and its a real rats nest. So extracting it into self
contained classes is not that easy. I have two false starts already and
am working on a third idea. The case of how to treat a a function handle
passed to eigs is particularly problematic...
It really depends on when you want to do a 2.9.10 release. If its in the
next two weeks I'd say take my existing code (I'll work it up as a
patch) and include it as is, it can be modified later. If it is longer
than two weeks, I'll try to have the extracted classes ready by then..
Regards
David
> Thanks,
>
> jwe
>
>
--
David Bateman address@hidden
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax)
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary