octave-maintainers
[Top][All Lists]
Advanced

[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.

Attachment: eigs.cc.bz2
Description: BZip2 compressed data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]