[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: moving toward a 3.0 release
From: |
David Bateman |
Subject: |
Re: moving toward a 3.0 release |
Date: |
Wed, 27 Sep 2006 22:08:08 +0200 |
User-agent: |
Thunderbird 1.5.0.7 (X11/20060921) |
Søren Hauberg wrote:
> ons, 27 09 2006 kl. 15:23 -0400, skrev John W. Eaton:
>> Anyway, I would really prefer to be discussing whether there are
>> features or bug fixes that people think are essential to have before
>> we release 3.0 instead of how we label the releases.
> Okay, sorry about the sidetrack.
>
> I don't have any outstanding requests assuming Davids implementation of
> eigs lands in octave. Things are looking good to me...
>
> Søren
>
>
I had hoped to get it ready for 2.9.9 but the segfault I'm having is
proving rather persistent. If you want to try to help diagnose the
problem, take the version of eigs attached (some small bug fixes
relative to the last version) and try
segtest(10000)
function aerr = segtest(iter)
%% This will seg-fault octave consistently, but not matlab.
n=20;
k=4;
A =
sparse([3:n,1:n,1:(n-2)],[1:(n-2),1:n,3:n],[ones(1,n-2),4*ones(1,n),-ones(1,n-2)]);
opts.disp = 0;
aerr = 0;
for i=1:iter
[v1,d1] = eigs(A, k, 'sr', opts);
d1 = diag(d1);
merr = 0;
for i=1:k
newerr = max(abs((A - d1(i)*speye(n))*v1(:,i)));
if (newerr > merr)
merr = newerr;
end
end
fprintf('Max Err: %g\n', merr);
if (merr > aerr)
aerr = merr;
end
end
end
I can get it to seg-fault about once every 20000 by enlarging some of
the dneupd and daupd work arrays above the recommended sizes, but can't
eliminate it. valgrind seems to indicate that its the variables "v",
"dr" and "di" allocated with OCTAVE_LOCAL_BUFFER that are causing the
problems, Looking at arpack++ they add one to the recocmmended values
and that seems to make the dominant error the one due to the variable v.
BTW, FreeMat also seems to have the same issue, and I can crash it in
much the same way.
One difference I see with arpack++ relative to octave is that arpack++
uses the new/delete c++ operators on the double, etc types, rather than
the std::vector class as the OCTAVE_LOCAL_BUFFER code currently does.
Though, why that should make a difference, I don't know. I'll try and
see if it helps..
D.
eigs.cc.bz2
Description: BZip2 compressed data
- moving toward a 3.0 release, John W. Eaton, 2006/09/27
- Re: moving toward a 3.0 release, Søren Hauberg, 2006/09/27
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/27
- Re: moving toward a 3.0 release, Søren Hauberg, 2006/09/27
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/27
- Re: moving toward a 3.0 release, Søren Hauberg, 2006/09/27
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/27
- Re: moving toward a 3.0 release, Søren Hauberg, 2006/09/27
- Re: moving toward a 3.0 release,
David Bateman <=
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/27
- Re: moving toward a 3.0 release, Dmitri A. Sergatskov, 2006/09/27
- Re: moving toward a 3.0 release, David Bateman, 2006/09/27
- Re: moving toward a 3.0 release, Dmitri A. Sergatskov, 2006/09/27
- Re: moving toward a 3.0 release, David Bateman, 2006/09/27
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/27
- Re: moving toward a 3.0 release, David Bateman, 2006/09/27
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/28
- Re: moving toward a 3.0 release, David Bateman, 2006/09/28
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/28