bugGNU Octave - Bugs: bug #60273, Wrong result in GSVD

 
 

bug #60273: Wrong result in GSVD

Submitter:  Leonardo <pocker>
Submitted:  Tue 23 Mar 2021 11:15:02 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 23 Nov 2021 05:00:59 PM UTC, comment #40: 

This bug report has largely been resolved.  Any new issues should be filed as new bug reports.

Marking as Fixed and closing report.

Rik <rik5>
Group administrator
Mon 22 Nov 2021 02:23:28 PM UTC, comment #39: 

That section was added to the manual in this changeset:
http://hg.savannah.gnu.org/hgweb/octave/rev/3300cb76cccd

Given the recent update of reference BLAS, I removed the word "unmaintained" from that sentence here:
http://hg.savannah.gnu.org/hgweb/octave/rev/08f6fbcd33c6

Markus Mützel <mmuetzel>
Group administrator
Sun 21 Nov 2021 09:28:10 PM UTC, comment #38: 

I didn't realize that OpenBLAS was now the recommended library.  I updated my local PC from reference BLAS to OpenBLAS and now I see BIST failures as well.  I relaxed some more BIST tolerances in this changeset: http://hg.savannah.gnu.org/hgweb/octave/rev/2c7a8040f4f2.

Hopefully that will be enough, but this may still take some testing on different architectures and further changes to the tolerances.

Rik <rik5>
Group administrator
Sun 21 Nov 2021 01:35:26 PM UTC, comment #37: 

I'm not sure if the statement about reference BLAS being unmaintained is true. It was updated (to version 3.10.0) quite recently in June 2021:
http://www.netlib.org/blas/#_reference_blas_version_3_10_0

Markus Mützel <mmuetzel>
Group administrator
Sun 21 Nov 2021 05:49:29 AM UTC, comment #36: 

It looks like we currently actively advice to prefer OpenBLAS over reference BLAS in our documentation:
https://octave.org/doc/v6.4.0/External-Packages.html

> BLAS
> Basic Linear Algebra Subroutine library. Accelerated BLAS libraries such as OpenBLAS (https://www.openblas.net/) or ATLAS (http://math-atlas.sourceforge.net) are recommended for best performance. The reference implementation (http://www.netlib.org/blas) is slow, unmaintained, and suffers from certain bugs in corner case inputs.


Markus Mützel <mmuetzel>
Group administrator
Sat 20 Nov 2021 06:46:15 PM UTC, comment #35: 

What is Octave's general position on the use of reference BLAS versus OpenBLAS?  The BIST tests pass with the canonical reference BLAS, and results are inferior with OpenBLAS.  Do we say internally that both libraries are supported and just relax the tolerances, by about 50 eps, necessary for these tests to pass?  Should we have a general comment in the documentation and installation procedures about the difference between the two libraries?  For example, "If you need more accuracy we recommend reference BLAS library, but if performance is more important then OpenBLAS is recommended"

Rik <rik5>
Group administrator
Sat 20 Nov 2021 10:46:04 AM UTC, comment #34: 

@Rik: Yes, this was also with OpenBLAS:

>> version -blas
ans = OpenBLAS (config: OpenBLAS 0.3.13 NO_LAPACKE DYNAMIC_ARCH NO_AFFINITY Haswell MAX_THREADS=64)


Markus Mützel <mmuetzel>
Group administrator
Sat 20 Nov 2021 12:41:34 AM UTC, comment #33: 

Trying to look through the logs I find that 'test.m' is not correctly reporting the value of shared variables.  This makes it useless for actual debugging.  I filed a report at bug #61511.

Rik <rik5>
Group administrator
Fri 19 Nov 2021 10:46:49 PM UTC, comment #32: 

On i9-9880 / Fedora 35 / OpenBlas-0.3.18 also 42 out of 46 passed.
Looks the same as on Ryzen / Centos.
I attached the log for the reference.

Dmitri.
--


(file #52300)

Dmitri A. Sergatskov <dasergatskov>
Fri 19 Nov 2021 10:15:49 PM UTC, comment #31: 

@Markus: Were your results also generated with OpenBLAS?  Both Dmitri and jwe reported failures but both failing instances were using OpenBLAS.

Rik <rik5>
Group administrator
Fri 19 Nov 2021 07:48:14 PM UTC, comment #30: 

The log is attached this is with openblas 0.3.18.
With ref blas it passes all tests.

Dmitri.
--


(file #52297)

Dmitri A. Sergatskov <dasergatskov>
Fri 19 Nov 2021 07:47:39 PM UTC, comment #29: 

I see the following results on an AMD Ryzen system with current Debian testing, GCC 11.2, Lapack 3.10.0, OpenBLAS 0.3.18:


  libinterp/corefcn/gsvd.cc-tst .................................. pass   39/46
                                                    (reported bug) XFAIL   7


Log file related to gsvd.cc-tst attached.


(file #52296)

John W. Eaton <jwe>
Group administrator
Fri 19 Nov 2021 06:28:16 PM UTC, comment #28: 

@Markus: The first two reported instances would be easy to resolve by relaxing the tolerance.  The final two are very wrong with the matrix shape being incorrect.  This might have to do with the earlier failure because the BIST tests are chained such that modifications are made to the input matrix over a series of tests.  I don't like that testing strategy, but it is the structure that was already there when I started.

I'm going to wait for some more log files to come in and then adjust the tolerances and see if that fixes things.

Rik <rik5>
Group administrator
Fri 19 Nov 2021 06:12:46 PM UTC, comment #27: 

I'm also seeing a few tests with exceeded tolerances. Log is attached.

(file #52295)

Markus Mützel <mmuetzel>
Group administrator
Fri 19 Nov 2021 03:47:24 PM UTC, comment #26: 

@Dmitri: Could you run the test on Ryzen and capture the log?  My guess is the failures are simply due to the tolerance of the comparison in the assert() statements.

My own testing showed that LAPACK seems to vary quite a bit with how accurate the return values are and that the accuracy depends on the characteristics of the input.  For example, if one of the inputs is rank-deficient then it matters whether that input is the first one, matrix A, or the second one, matrix B.  The orientation of the matrix also affected results.  If A was 3x5 accuracy was one value but if it was 5x3 it was another.

When I wrote the BIST tests I updated the tolerances so the tests would pass on my machine.  I don't think there's any problem with increasing some of the tolerances by as much as 50 eps.

Rik <rik5>
Group administrator
Fri 19 Nov 2021 03:41:00 PM UTC, comment #25: 


> Should there be ";" at the end of
> <<<
> ## a few tests for gsvd.m
> %!shared A, A0, B, B0, U, V, C, S, X, old_state, restore_state
> >>>
>
> or you meant to echo all those vars?


The %!shared syntax is not Octave code parsed by the interpreter so it won't be echoed to the screen.  More of the details are in the Octave manual in Appendix B Test And Demo Functions.

Rik <rik5>
Group administrator
Fri 19 Nov 2021 12:43:08 PM UTC, comment #24: 

On Ryzen:


octave:1> system("uname -m");
x86_64
octave:2>  __octave_config_info__ ("hg_id")
ans = 4fa09c269dde
octave:3> test gsvd quiet
PASSES 42 out of 46 tests (4 known bugs)


On Raspberry Pi 4:


octave:1> system("uname -m");
aarch64
octave:2> __octave_config_info__ ("hg_id")
ans = 4fa09c269dde
octave:3> test gsvd
PASSES 46 out of 46 tests


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 19 Nov 2021 05:13:18 AM UTC, comment #23: 

Should there be ";" at the end of
<<<
## a few tests for gsvd.m
%!shared A, A0, B, B0, U, V, C, S, X, old_state, restore_state

>>>


or you meant to echo all those vars?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 19 Nov 2021 04:19:13 AM UTC, comment #22: 

Finally, I checked in the re-write of gsvd here: http://hg.savannah.gnu.org/hgweb/octave/rev/4ee01c14fccd.

There's still stuff I don't like.  In particular, if both A and B are rank-deficient then LAPACK factoring fails, but doesn't indicate that.

Also, the ordering of the multiple-return argument case is different from Matlab.  There is already bug #60274 for that so it doesn't need to be addressed here.

Rik <rik5>
Group administrator
Tue 16 Nov 2021 08:39:32 PM UTC, comment #21: 

ok, so by first and other I assume you mean the (1st) ordering and (2nd) accuracy of the X output matrix? If you're addressing that together here, should that bug be closed and pointed over here? i'm not familiar enough to know if there's overlap between the X part and discussion below.

Nicholas Jankowski <nrjank>
Group Member
Tue 16 Nov 2021 07:16:51 PM UTC, comment #20: 

@Nicholas: Yes, bug #60274 is also about gsvd.  I have changed the first part to make the eigenvalue ordering compatible with Matlab.  I haven't done the other part because I'm not sure it's worth it and I don't have the time for it just now.

Rik <rik5>
Group administrator
Tue 16 Nov 2021 07:04:41 PM UTC, comment #19: 

@rik, i think you were trying to get this wrapped up for v7.  did you also notice bug #60274?  it suggests an output ordering incompatibility vs matlab in S that I did not see mentioned below.

Nicholas Jankowski <nrjank>
Group Member
Sun 17 Oct 2021 08:09:04 AM UTC, comment #18: 

@Rik: Thank you for your hard work finding the root of this issue. 🙂

Did you push a change to the development repository, or left another description of the problem in liboctave, that I missed? 🤔

Kai Torben Ohlhus <siko1056>
Group Member
Thu 07 Oct 2021 09:39:44 PM UTC, comment #17: 

I finally located the problem in liboctave code where, in certain cases that depended on the rank of the matrices A and B, we were not correctly using the API to LAPACK.  I've now fixed the code so the correct answers are always generated.

The next step is to translate the LAPACK results, [U,V,Q,C,S,R], to Matlab-compatible return results [U,V,X,C,S].  That requires changing the liboctave API which is work, but not as much work as finding the original bug.

Rik <rik5>
Group administrator
Fri 20 Aug 2021 03:36:01 PM UTC, comment #16: 

That is definitely good news!

Thanks

Kind regards,
Leonardo

Leonardo <pocker>
Fri 20 Aug 2021 02:55:08 PM UTC, comment #15: 

I've done a lot of work on this.  I will probably get it out in time for Octave version 7 around the end of the year.

Rik <rik5>
Group administrator
Fri 20 Aug 2021 02:23:23 PM UTC, comment #14: 

Appears to be in a holding pattern for the moment. 

Regarding expected output, here's a current comparison with Matlab 2021:
Docs example 1:

>> A = reshape(1:15,5,3)
A =
     1     6    11
     2     7    12
     3     8    13
     4     9    14
     5    10    15
>> B = magic(3)
B =
     8     1     6
     3     5     7
     4     9     2
>> [U,V,X,C,S] = gsvd(A,B)
U =
    0.5618    0.6457   -0.4279   -0.0735    0.2810
   -0.8005    0.3296   -0.4375    0.1240    0.2094
   -0.0219    0.0135   -0.4470   -0.4343   -0.7816
    0.1979   -0.3026   -0.4566    0.7906   -0.1889
    0.0626   -0.6187   -0.4661   -0.4068    0.4802
V =
   -0.7071   -0.6946    0.1325
    0.0000   -0.1874   -0.9823
    0.7071   -0.6946    0.1325
X =
   -2.8284   -9.3761   -6.9346
    5.6569   -8.3071  -18.3301
   -2.8284   -7.2381  -29.7256
C =
    0.0000         0         0
         0    0.3155         0
         0         0    0.9807
         0         0         0
         0         0         0
S =
    1.0000         0         0
         0    0.9489         0
         0         0    0.1957


Octave 6.3.0:

>> A = reshape(1:15,5,3)
A =

    1    6   11
    2    7   12
    3    8   13
    4    9   14
    5   10   15

>> B = magic(3)
B =

   8   1   6
   3   5   7
   4   9   2

>> [U,V,X,C,S,R] = gsvd(A,B)
U =

  -0.427930  -0.645660   0.620200   0.120196   0.030090
  -0.437470  -0.329576  -0.678075   0.048816   0.487680
  -0.447010  -0.013492  -0.165583  -0.665944  -0.573674
  -0.456550   0.302592  -0.115408   0.704656  -0.436052
  -0.466091   0.618676   0.338866  -0.207724   0.491956

V =

   1.3251e-01   6.9458e-01  -7.0711e-01
  -9.8229e-01   1.8739e-01   2.4980e-16
   1.3251e-01   6.9458e-01   7.0711e-01

X =

   0.642906   0.648078   0.408248
  -0.060330   0.574190  -0.816497
  -0.763565   0.500301   0.408248

C =

Diagonal Matrix

   9.8067e-01            0            0
            0   3.1553e-01            0
            0            0   2.5093e-16

S =

Diagonal Matrix

   0.1957        0        0
        0   0.9489        0
        0        0   1.0000

R =

   19.3450  -29.8908    0.0000
         0   14.4676   -0.0000
         0         0   -6.9282


example 2:

Matlab 2021a

>> A = reshape(1:15,3,5)
A =
     1     4     7    10    13
     2     5     8    11    14
     3     6     9    12    15
>> B = magic(5)
B =
    17    24     1     8    15
    23     5     7    14    16
     4     6    13    20    22
    10    12    19    21     3
    11    18    25     2     9
>> [U,V,X,C,S] = gsvd(A,B)
U =
    0.4082    0.7178   -0.5639
   -0.8165    0.0109   -0.5772
    0.4082   -0.6961   -0.5906
V =
   -0.2725    0.7746    0.3339   -0.4552   -0.0843
   -0.6610   -0.4058   -0.3111   -0.5408    0.0956
   -0.0078   -0.0524   -0.1701   -0.0271   -0.9836
    0.6218    0.1439   -0.5395   -0.5408    0.0956
    0.3195   -0.4603    0.6868   -0.4552   -0.0843
X =
  -10.1340         0    0.0000  -30.7287   -4.6958
    3.3206    9.6882   11.3264  -28.5003  -11.6858
   14.8016  -11.5196    2.8654  -26.2720  -18.6758
    2.1067    1.5695  -15.0424  -24.0436  -25.6657
  -10.0949    0.2619    0.8506  -21.8152  -32.6557
C =
         0         0    0.0000         0         0
         0         0         0    0.0439         0
         0         0         0         0    0.7432
S =
    1.0000         0         0         0         0
         0    1.0000         0         0         0
         0         0    1.0000         0         0
         0         0         0    0.9990         0
         0         0         0         0    0.6690


Octave 6.3.0

>> A = reshape(1:15,3,5)
A =

    1    4    7   10   13
    2    5    8   11   14
    3    6    9   12   15

>> B = magic(5)
B =

   17   24    1    8   15
   23    5    7   14   16
    4    6   13   20   22
   10   12   19   21    3
   11   18   25    2    9

>> [U,V,X,C,S,R] = gsvd(A,B)
U =

  -0.563938   0.717849   0.408248
  -0.577248   0.010868  -0.816497
  -0.590558  -0.696114   0.408248

V =

  -0.084305  -0.455168   0.239134   0.747904   0.411301
   0.095559  -0.540792  -0.813938   0.043357  -0.184492
  -0.983627  -0.027052  -0.060572  -0.016259  -0.166771
   0.095559  -0.540792   0.511078  -0.124651  -0.649365
  -0.084305  -0.455168   0.124299  -0.650352   0.589327

X =

   0.654138  -0.521137   0.476156   0.248539   0.109654
  -0.025779  -0.447052  -0.669616   0.161852   0.569999
  -0.048443  -0.444582   0.053606  -0.892150  -0.034576
  -0.071106  -0.442113  -0.325192   0.235599  -0.798889
  -0.751023  -0.368028   0.465045   0.246160   0.153812

C =

Diagonal Matrix

   7.4324e-01            0            0
            0   4.3892e-02            0
            0            0   1.0474e-16

S =

Diagonal Matrix

   0.6690        0        0
        0   0.9990        0
        0        0   1.0000

R =

   24.4845   39.3396   -2.2522   -0.4822    8.9512
         0   59.0936    0.7180    0.1537   -2.8536
         0         0  -14.0044   -8.3199    2.8868
         0         0         0   19.8246    2.9090
         0         0         0         0   18.8836


Nicholas Jankowski <nrjank>
Group Member
Fri 20 Aug 2021 02:08:29 PM UTC, comment #13: 

Hi!!

Any news on this bug?

Leonardo <pocker>
Tue 23 Mar 2021 08:42:31 PM UTC, comment #12: 

You can try tests in gdvd.cc-tst. Or Example 1 in Matlab's doc.
Essentially they are not 0-padded.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 23 Mar 2021 08:35:51 PM UTC, comment #11: 

I have other pending changes for function handles that will affect the API and that should probably go in the next stable release (assuming there is one) so I don't object to also making the GSVD changes on stable.  It makes sense to me to have the same (or similar) interface for all the functions, so changing liboctave is probably best.  Can we also preserve (but deprecate) the previous interface?

John W. Eaton <jwe>
Group administrator
Tue 23 Mar 2021 08:23:51 PM UTC, comment #10: 

Solution #3 : change on stable in libinterp to preserve liboctave API, and then change in liboctave on dev branch.

Rik <rik5>
Group administrator
Tue 23 Mar 2021 08:21:46 PM UTC, comment #9: 

@jwe: How do you think this bug should be addressed?

Solution #1 : Change liboctave version of gsvd to return Matlab-compatible 5 outputs.

Solution #2: Change libinterp version of gsvd to calculate the 5 Matlab-compatible return outputs from the 6 outputs provided by liboctave.

It seems like the change should go on the stable branch because Octave is definitely not producing the output that it says it is, hence this is more than just Matlab-compatibility issue which could wait until next release.

Rik <rik5>
Group administrator
Tue 23 Mar 2021 08:17:56 PM UTC, comment #8: 

@Dmitri: Do you have an example that shows the size of the matrices are different from Matlab?  Always helpful if we can see what is supposed to happen.  There is already some code to adjust the size of the output matrices so it might just require tweaking of that.

Rik <rik5>
Group administrator
Tue 23 Mar 2021 06:36:33 PM UTC, comment #7: 


> B = V S R * Q' (and not V*C*R*Q')


Yes, just a typo.  I meant what you wrote.

Rik <rik5>
Group administrator
Tue 23 Mar 2021 06:27:23 PM UTC, comment #6: 

I think the size of S and C matrices is not correct (i.e. not Matlab compatible) when A and B are not square.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 23 Mar 2021 06:08:28 PM UTC, comment #5: 

Indeed.

>> [U, V, Q, C, S, R] = gsvd (A, B);
>> U*C*R*Q'

ans =

   1.0000   1.0000   3.0000
   3.0000   1.0000   2.0000
   2.0000   1.0000   1.0000

>> V*S*R*Q'

ans =

   2.0000e+00   3.8858e-16   1.0000e+00
   2.0000e+00   1.0000e+00  -1.0000e+00
   1.0000e+00   7.6328e-17  -9.3675e-17

and finally, as you pointed out,

>> Q*R' - A'*U*inv(C)

ans =

   8.8818e-16   1.7764e-15  -3.1225e-16
   2.2204e-16   6.6613e-16  -1.1102e-16
  -8.8818e-16   1.7451e-15   4.4409e-16

which confirms that

X = Q*R'

And I do agree that the documentation of GSVD should be adjusted.

BTW, it is

B = V S R * Q' (and not V*C*R*Q')

Thanks on this!

Leonardo <pocker>
Tue 23 Mar 2021 05:43:32 PM UTC, comment #4: 

Octave is definitely taking the matrix Q from LAPACK and returning it as the matrix X from gsvd which is incorrect.  Documentation on the routine that Octave calls is at https://www.math.utah.edu/software/lapack/lapack-d/dggsvd.html.

The variable naming in gsvd.cc shows that the original coder knew that 'q' was being returned.  Maybe there wasn't a realization that Matlab was not exactly mapping the outputs of LAPACK to the outputs of the Matlab function.

In any case, there is a 6th undocumented output from Octave's gsvd function which is the matrix R from LAPACK.  The documentation should really read


[U, V, Q, C, S, R] = gsvd (A, B)


If you do this then the results conform to the LAPACK documentation and


A = U * C * R * Q'
B = V * C * R * Q'


To recover Matlab's behavior


X = Q*R'



Rik <rik5>
Group administrator
Tue 23 Mar 2021 04:56:30 PM UTC, comment #3: 

From

https://www.netlib.org/lapack/lug/node36.html

it seems that matrix X is just the matrix Q because

>> inv(C)*U'*A*X

ans =

   2.6026e+00  -3.5966e+00  -2.3962e+00
  -5.3213e-16  -3.8168e+00   5.0481e-01
  -7.7716e-16  -8.8818e-16   1.6511e+00

is upper triangular.

Also, matrix X is orthogonal (in general, it should not be)

>> X'*X

ans =

   1.0000e+00  -1.8041e-16  -5.5511e-17
  -1.8041e-16   1.0000e+00   1.2490e-16
  -5.5511e-17   1.2490e-16   1.0000e+00



Leonardo <pocker>
Tue 23 Mar 2021 04:41:40 PM UTC, comment #2: 
Dmitri A. Sergatskov <dasergatskov>
Tue 23 Mar 2021 04:16:58 PM UTC, comment #1: 

Confirmed.

The problem is only with matrix X as stated.  The code in question is in liboctave/numeric/gsvd.cc.  The code there calls LAPACK to perform the actual gsvd calculation.

There are several possibilities.  1) Octave is not calling LAPACK correctly, 2) there is a bug in LAPACK, 3) or matrix X is meant to be calculated outside of LAPACK via some other method such as the suggested


X = A'*U*inv(C)


Rik <rik5>
Group administrator
Tue 23 Mar 2021 11:15:02 AM UTC, original submission:  

Hi.

From "help gsvd" it says that

[U, V, X, C, S] = gsvd (A, B)
A = U*C*X'
B = V*S*X'

But,

>> A = [1 1 3; 3 1 2; 2 1 1];
>> B = [2 0 1; 2 1 -1;1 0 0];
>> [U, V, X, C, S] = gsvd (A, B);
>> U*C*X'

ans =

0.206864 0.733236 0.430549
-0.510638 0.269817 0.312529
-0.294408 0.404150 -0.080575

which is clearly not matrix A.

The problem is with matrix X

>> X

X =

-0.186817 -0.981925 0.030379
0.865745 -0.149940 0.477496
0.464311 -0.115506 -0.878108

while it should be

>> X = A'*U*inv(C)

X =

2.9726e+00 3.7631e+00 5.0158e-02
1.6483e+00 8.1334e-01 7.8837e-01
3.7280e+00 -2.4142e-03 -1.4498e+00

After this, I get

>> U*C*X'

ans =

1.0000 1.0000 3.0000
3.0000 1.0000 2.0000
2.0000 1.0000 1.0000

which is matrix A and

>> V*S*X'

ans =

2.0000 0 1.0000
2.0000 1.0000 -1.0000
1.0000 -0.0000 -0.0000

which is matrix B.

This affects, at least, v. 6.2.0 and 7.0.0 (4a516dce916c+). Both compiled from source, debian 10.

Kind regards,
Leonardo

Leonardo <pocker>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #52300:  t_openblas_i9.log.gz added by dasergatskov (7KiB - application/gzip)
file #52297:  t_openblas.log.gz added by dasergatskov (7KiB - application/gzip)
file #52296:  fntests.log added by jwe (77KiB - text/x-log)
file #52295:  test-gsvd.log added by mmuetzel (49KiB - 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 mmuetzel (Updated the item)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pocker (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 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-11-23 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2021-11-19 dasergatskov Attached File- Added t_openblas_i9.log.gz, #52300
    2021-11-19 dasergatskov Attached File- Added t_openblas.log.gz, #52297
    2021-11-19 jwe Attached File- Added fntests.log, #52296
    2021-11-19 mmuetzel Attached File- Added test-gsvd.log, #52295
    2021-11-19 rik5 StatusConfirmed Ready For Test
    2021-03-23 rik5 Carbon-Copy- Added jwe
    2021-03-23 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code