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