Re: inv function failing?
Enzo Alberto Dari <[email protected]> Sun, 4 Dec 2022 21:11:21 -0300
| Newsgroups | gmane.comp.gnu.octave.general |
|---|---|
| Message-ID | <CALOFp8fnGJu_MT6m9V0L-7q=DpoPxu=eraJowVREoiME73LasA@mail.gmail.com> |
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 <[email protected]> wrote: > > > On Sun, Dec 4, 2022 at 4:05 PM Enzo Alberto Dari <[email protected]> > 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 <http://www.ib.edu.ar/> >> > > 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 <http://www.ib.edu.ar/> ---------- We are transitioning to a web based forum for community help discussions at https://octave.discourse.group/c/help