Re: inv function failing?

[Enzo Alberto Dari]

Thanks Chris, Dmitri.

Indeed, the correct behaviour is all condition numbers equal to 1. The matrix has the form: B=[b zeros; zeros eye], so the inverse can be computed as [inv(b) zeros; zeros eye] and it works ok. However inv(B) sometimes gives non-zeros on the upper right block!. So: by fail I mean incorrect results, and in that case the output is something like:

sizeb = 19
rankb = 19
diffinvs = 32.430
ans = 769.02
ans = 1.1160e+06
ans = 1.0000
ans = 1.0000
diffinvs_ = 32.430
ans = 617.64
ans = 28.923
ans = 1.0000
ans = 1.0000

I tried Dmitri's suggestion:

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0 octave-cli chkBlockedInverse.m

It still fails, but then I tried to rule out multithreading issues and ran:

OMP_NUM_THREADS=1 octave-cli chkBlockedInverse.m

And the results were:

sizeb = 19
rankb = 19
diffinvs = 2.6377e-17
ans = 1.0000
ans = 1.0000
ans = 1.0000
ans = 1.0000
diffinvs_ = 2.6377e-17
ans = 5.4962
ans = 5.5663
ans = 1.0000
ans = 1.0000

So: the blocked matrix: [b zeros; zeros eye] is correctly inverted with one thread, the other: [eye zeros; zeros, b] seems to have some problems with precision, but the main issue seems to be in the multithreading implementation!

Enzo

On Sun, Dec 4, 2022 at 6:24 PM Dmitri A. Sergatskov <dasergatskov@gmail.com> wrote:

On Sun, Dec 4, 2022 at 4:05 PM Enzo Alberto Dari <enzo.dari@ib.edu.ar> wrote:

While upgrading my debian OS from 10.x to 11.x (octave 4.4.5 to 6.2.0), one of my scripts started failing. I managed to create a simple test (attached if the mailing list doesn't block it) that reproduces the problem.

The matrix is blocked, so there is an alternate method to compute its inverse by blocks that always works. This test verifies if the computed inverse times the original matrix has condition number 1 (as it should be for the identity matrix).

To make things more complicated, I ran the test in 5 machines with debian 11.5 (octave 6.2.0) and it failed in 3 of them, working ok in the other 2. Perhaps something to do with new processor features? (apparently is failing in machines with "newer" processors):

Intel(R) Core(TM) i5 CPU         750  @ 2.67GHz: Ok.

Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz: Ok.

Intel(R) Core(TM) i5-1035G1 CPU @ 1.00GHz: Fails.

Intel(R) Core(TM) i9-7900X CPU @ 3.30GHz: Fails.

Intel(R) Core(TM) i9-9900X CPU @ 3.50GHz: Fails.

Any clue about what may be happening?

Any tips for further analysis?

Thanks in advance,

This mailing list is pretty much dead -- you should post on discourse.

In any case, what do you mean "fail"? Crash, core dump, or just a wrong answer? 

I would guess that the issue is with openblas libraries

provided by debian. You can try to override them with reference blas 

by starting octave as 

LD_PRELOAD=/usr/lib64.libblas.so octave

(adjust the path to libblas as appropriate)

And you should fill the bug against the debian package.

Your script works on i9-9880 and ryzen-9 3950 (on Fedora 37):

octave:1> chkBlockedInverse
sizeb = 19
rankb = 19
diffinvs = 3.3156e-17
ans = 1.0000
ans = 1.0000
ans = 1.0000
ans = 1.0000
diffinvs_ = 3.3156e-17
ans = 1.0000
ans = 1.0000
ans = 1.0000
ans = 1.0000
octave:2>

 

--

Enzo A. Dari

Profesor Titular

Instituto Balseiro

Dmitri.

-- 

----------
We are transitioning to a web based forum
for community help discussions at
https://octave.discourse.group/c/help

--

Enzo A. Dari

Profesor Titular

Instituto Balseiro