bugGNU Octave - Bugs: bug #63787, test pcg may fail at high...

 
 

bug #63787: test pcg may fail at high optimization

Submitter:  Dmitri A. Sergatskov <dasergatskov>
Submitted:  Fri 10 Feb 2023 09:19:45 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 8.0.90 Operating System:  * Any
Fixed Release:  8.3.0 Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 19 Jul 2023 04:47:50 PM UTC, comment #14: 

Check in the changeset here: http://hg.savannah.gnu.org/hgweb/octave/rev/fe178c793ea0.

Marking as Fixed and closing report.

Rik <rik5>
Group administrator
Tue 18 Jul 2023 09:38:41 PM UTC, comment #13: 

Yes, this failing test requires choosing a tolerance for the particular matrix in the BIST test.  In general, a user will need to decide on their own what the tolerance (if any) should be.

Rik <rik5>
Group administrator
Tue 18 Jul 2023 09:30:31 PM UTC, comment #12: 

This works for this particular test, but I remember when it first
came up, I, prompted by comment #8, was trying to construct different M' * M matrices  and could not make a tolerance that satisfy all of them.

I guess we may close it now and just let user to choose a suitable tolerance for their particular case.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 18 Jul 2023 09:09:17 PM UTC, comment #11: 

The attached changeset works for me.  Please review.

(file #54937)

Rik <rik5>
Group administrator
Wed 08 Mar 2023 08:31:00 PM UTC, comment #10: 

Oops I forgot that k6-8335 already has avx (just no avx2).
So nothing new.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 08 Mar 2023 07:29:51 PM UTC, comment #9: 

This test is failing on fedora buildbots (amd k6-8350) with default optimization (-O2).

gcc-13.0.1

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 11 Feb 2023 11:26:47 PM UTC, comment #8: 

Seems reasonable enough to add a tolerance to this.  Does it need to scale with the size of the matrix?  If so, how?  Something like


eps (norm (A))



Rik <rik5>
Group administrator
Sat 11 Feb 2023 05:53:13 PM UTC, comment #7: 

It looks to me the assumption was that M' * M must be Hermetian
(with an absolute precision), and it looks like it is not in the floating-point implementation.

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Sat 11 Feb 2023 05:50:06 PM UTC, comment #6: 

Comment #5 illustrates the point I'm talking about.  One can specifically craft examples that will pass or fail.  I don't know enough about this particular BIST test to know if the original programmer had specifically coded a test that should result in true equality, or if they just wrote some code that calculated a value and thus this expected value is only accurate within a range because of artifacts of numerical math such as roundoff error.

Rik <rik5>
Group administrator
Sat 11 Feb 2023 05:41:07 PM UTC, comment #5: 

Another simple example fail:


octave:3> a = 0.3
a = 0.3000
octave:4> 0.1 + 0.2 == a
ans = 0


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 11 Feb 2023 05:37:52 PM UTC, comment #4: 

M' * M is somewhat more complicated than 2+2.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 11 Feb 2023 05:36:00 PM UTC, comment #3: 

I agree with the general programming practice that floating point numbers should not be compared directly to integers.  However, is this example specifically engineered so that the calculations should result in perfect equality?  A silly example, but "2.0 + 2.0 == 4" and I don't want to have any tolerance on this test because even using floating point numbers this calculation should hold exactly.

Rik <rik5>
Group administrator
Sat 11 Feb 2023 02:59:07 AM UTC, comment #2: 

Yes I also has "-mtune=native". But I also this this on i9-9880 cpu.

In any case it is generally advised not to use equality check
between float and zero.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 11 Feb 2023 02:49:22 AM UTC, comment #1: 

I have seen similar test failures for years with real becoming complex or hermitian failing tests, but only in combination with O2 (or higher) along with -march flags for Zen2. If march or mtune are set to generic x64_64 keeping all optimization flags the same, I have not had problems.

I'm not sure if it's a compiler effect, a processor effect, or if Octave code should go something different.

Arun Giridhar <arungiridhar>
Group Member
Fri 10 Feb 2023 09:19:45 PM UTC, original submission:  

With gcc 11 or gcc 12 and (_O2 -mavx -mavx2 -flto)
"test pcg" fails:


octave:1> test pcg
***** testif HAVE_CHOLMOD
 ## pcg solves preconditioned linear system with A HPD
 N = 20;
 A = sparse (toeplitz ([4, 1, zeros(1, 18)])) + ...
     i * sparse (toeplitz ([0, 1, zeros(1, 18)], [0, -1, zeros(1,18)]));
 b = A * ones (N, 1);
 M2 = chol (A + 0.1 * eye (N));  # Factor of a perturbed matrix
 M = M2' * M2;
 Hermitian_A = ishermitian (A);
 Hermitian_M = ishermitian (M);
 [x, flag] = pcg (A, b, [], 2*N, M);
 assert (Hermitian_A, true);
 assert (Hermitian_M, true);
 assert (flag, 0);
 assert (x, ones (N, 1), -1e-4);
!!!!! test failed
ASSERT errors for:  assert (Hermitian_M,true)

  Location  |  Observed  |  Expected  |  Reason
     ()           0            1         Abs err 1 exceeds tol 0 by 1
-verbaatim-

due to :

+verbatim+
octave:2> N = 20;
 A = sparse (toeplitz ([4, 1, zeros(1, 18)])) + ...
     i * sparse (toeplitz ([0, 1, zeros(1, 18)], [0, -1, zeros(1,18)]));
 b = A * ones (N, 1);
 M2 = chol (A + 0.1 * eye (N));  # Factor of a perturbed matrix
 M = M2' * M2;
octave:7> ishermitian (M)
ans = 0
octave:8> Z = M - M'
Z =

Compressed Column Sparse (rows = 20, cols = 20, nnz = 19 [4.8%])

  (2, 2) ->           0 - 5.0446e-18i
  (3, 3) ->           0 - 5.1973e-17i
  (4, 4) ->           0 + 2.0610e-17i
  (5, 5) ->           0 + 1.6595e-17i
  (6, 6) ->           0 - 4.0964e-17i
  (7, 7) ->           0 - 2.9936e-18i
  (8, 8) ->           0 - 3.1185e-17i
  (9, 9) ->           0 - 5.5264e-17i
  (10, 10) ->           0 - 6.4907e-19i
  (11, 11) ->           0 + 5.3025e-17i
  (12, 12) ->           0 - 2.8965e-17i
  (13, 13) ->           0 - 2.2264e-17i
  (14, 14) ->           0 + 5.3442e-18i
  (15, 15) ->           0 - 2.1381e-18i
  (16, 16) ->           0 - 3.6669e-17i
  (17, 17) ->           0 - 4.4072e-17i
  (18, 18) ->           0 - 2.9208e-18i
  (19, 19) ->           0 + 5.4313e-17i
  (20, 20) ->           0 + 4.2576e-17i


I think the "Hermitian_M = ishermitian (M);" should be
replaced with relaxed version "Hermitian_M = ishermitian (M, eps);" or similar.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #54937:  bug63787.cset added by rik5 (943B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by arungiridhar (Posted a comment)
  • -email is unavailable- added by dasergatskov (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-07-19 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 8.3.0
    2023-07-18 rik5 Attached File- Added bug63787.cset, #54937
        StatusNone Patch Submitted

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code