bugGNU Octave - Bugs: bug #59486, p variable not always defined in...

 
 

bug #59486: p variable not always defined in eigs function

Submitter:  JD <jdbancal>
Submitted:  Thu 19 Nov 2020 05:48:24 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 6.0.92 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 25 Nov 2020 08:57:49 PM UTC, comment #8: 

Thanks guys for fixing this, much appreciated!

JD <jdbancal>
Fri 20 Nov 2020 05:29:20 PM UTC, comment #7: 

Change looks fine. 

And eps() called with an argument is actually exactly what you want.  When called as eps (X) it gives you the machine precision around the number (X).  When called with no argument it gives the machine precision around the default (1).  So X*eps(1) is very much related to eps (X), but they are not always identical.  For example,


octave:1> eps (65) - 65*eps
ans = -2.2204e-16


Not so bad, but consider a larger number


octave:7> e1 = eps (1e6)
e1 = 1.1642e-10
octave:8> e2 = 1e6*eps
e2 = 2.2204e-10
octave:9> delta = e2 - e1
delta = 1.0563e-10
octave:10> percent_change = delta / e1 * 100
percent_change = 90.735


In this case, the kluge way of calculating machine precision is of by 90%.

Rik <rik5>
Group administrator
Fri 20 Nov 2020 05:18:53 PM UTC, comment #6: 

I pushed a change here:
https://hg.savannah.gnu.org/hgweb/octave/rev/b4329276f628

I thought I remembered that I was told once to not call eps with an argument. (Can't remember the exact reason.)

Markus Mützel <mmuetzel>
Group administrator
Fri 20 Nov 2020 04:18:57 PM UTC, comment #5: 

Markus: You wrote 5*eps(65) but the patch has 5*eps*65?

John W. Eaton <jwe>
Group administrator
Fri 20 Nov 2020 04:04:14 PM UTC, comment #4: 

There was nothing special about the tolerance.  I chose something comfortably larger than what I see on my machine (128 eps).  Go ahead and increase it to something that works for the buildbots.  5*eps(65) seems like a good alternative.


Rik <rik5>
Group administrator
Fri 20 Nov 2020 10:27:39 AM UTC, comment #3: 

A possible "solution" might be to allow approximately 5*eps(65) deviation:

diff -r a23870bdf30e scripts/sparse/eigs.m
--- a/scripts/sparse/eigs.m        Fri Nov 20 11:05:06 2020 +0100
+++ b/scripts/sparse/eigs.m        Fri Nov 20 11:25:31 2020 +0100
@@ -1587,7 +1587,7 @@
 %!testif HAVE_ARPACK <*59486>
 %! A = magic (5);
 %! d = eigs (A, [], 1);
-%! assert (d, 65, 150*eps);
+%! assert (d, 65, 5*eps*65);

 ## Test input validation
 %!error <Invalid call> eigs ()


Markus Mützel <mmuetzel>
Group administrator
Fri 20 Nov 2020 09:49:38 AM UTC, comment #2: 

The buildbots seem to struggle with the newly added test.
E.g.:

>>>>> processing /scratch/buildbot/workers/jwe-debian-x86_64-0/stable-clang-debian-save/src/scripts/sparse/eigs.m
***** testif HAVE_ARPACK <*59486>
 A = magic (5);
 d = eigs (A, [], 1);
 assert (d, 65, 150*eps);
!!!!! regression: https://octave.org/testfailure/?59486
ASSERT errors for:  assert (d,65,150 * eps)
  Location  |  Observed  |  Expected  |  Reason
     ()           65           65        Abs err 5.6843e-14 exceeds tol 3.3307e-14 by 2e-14


Should the tolerance for this test just be relaxed? Or is there something more to it?

Markus Mützel <mmuetzel>
Group administrator
Thu 19 Nov 2020 09:09:36 PM UTC, comment #1: 

Definitely an odd corner case.  I fixed it in this changeset http://hg.savannah.gnu.org/hgweb/octave/rev/dc3ee9616267.

Closing report.

Rik <rik5>
Group administrator
Thu 19 Nov 2020 05:48:24 PM UTC, original submission:  

When computing just a few eigenvalues of a matrix, Matlab supports two syntaxes (see https://fr.mathworks.com/help/matlab/ref/eigs.html ):

A = eye(5);
eigs(A, 1)

as well as

A = eye(5);
eigs(A, [], 1)


The second format allows to disambiguate between standard and generalized eigenvalue decompositions (this is not obvious when the first argument is a scalar for instance). Namely, an empty second argument here makes it clear that we are interested in the standard eigenvalue decomposition, even when the dimension of the first argument 'A' happens to be of dimension 1x1, i.e. a scalar.

The second syntax was supported in previous versions of Octave (4.2 for instance), but it gives an error on the newest versions, including Octave 6:

error: 'p' undefined near line 231 column 11
error: called from
    eigs at line 231 column 7


JD <jdbancal>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jdbancal (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-19 rik5 StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code