[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #41305] generate human-readable error strings

From: Pantxo Diribarne
Subject: [Octave-bug-tracker] [bug #41305] generate human-readable error strings from arpack error codes
Date: Mon, 27 Jan 2014 22:41:34 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Firefox/26.0

Follow-up Comment #17, bug #41305 (project octave):

Sorry, I may have been a bit to fast here, you are right. However, here are
the reasons that make me think octave does the right thing: 

1 - I you care enough to see if it's a bug from  octave, you may want to check
__eigs__.cc and eig-base.cc. The number k of requested eigen values is
directly (this should be double checked) passed to xnaupd arpack functions.
>From this quick browse, I'd say if there is a bug it is in arpack.

2 - I tested the attached modified sweepseed.m in matlab and octave 3.8 using

nval = 1;
failed = sweepseed (1:600, nval); 
sum (failed)/600
And for this particular set of seeds I see about 1-2% failures in both  matlab
and octave (and with the same error).

>There are cases, where  eigs(M,1,'LM')  fails, but
eigs(M,6,'LM')  successfully returns.

3 - Wild guess: the convergence criterion (based on opt.tol) may well not be
satisfied for one large eigen value, and satisfied for 6 smaller in average
values (e.g. if the criterion is a simple algebraic mean error). Anyway matlab
behaves the same: for a failing seed if I increase nval, the error

>Also, failure seem to be version dependent, as comment 2 states.

If you add comment 1 you'll see that the error is not simply octave version
dependent, it may be machine/architecture  dependent also. 

(file #30393)

Additional Item Attachment:

File name: sweepseed.m                    Size:0 KB


Reply to this item at:


  Message posté via/par Savannah

reply via email to

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