I have a private implementation of sparse matrix which works fine but would like to move to ROOT.
I need to add large sparse matrices which are of the same size but not compatible in ROOT sense, i.e., there are couple of elements filled in one matrix but not the other. How can I do that?
yes, that’s what I’ve done and I didn’t manage to find a solution to my problem. And that’s why I’m writing to this forum. Maybe I am doing something wrong.
I define 2 TMatrixDSparse matrices as
A:
1 0 0
1 0 0
0 0 0
B:
0 0 0
1 0 0
1 0 0
And when doing A+B I get
1 0 0
2 0 0
0 0 0
whereas I’d expect
1 0 0
2 0 0
1 0 0
I understood from the code that this is not a bug but rather a feature. It comes from the fact that the two sparse matrices are not compatible in ROOT sense.
My question is, in which way can I get the normal behavior for the addition, i.e., get the correctly summed matrix?
I tried 5.26 binary release on MAC OS X and I see that for some matrices it works ok but for others I still see problems. I attach an example script.
Here’s an output for one case where I see an error message while the summing is still done. However, the result is incorrect.
root [0]
Processing testSparse.C...
Matrix A:
3x3 matrix is as follows
| 0 | 1 | 2 |
--------------------------------------------
0 | 1 0 0
1 | 1 0 0
2 | 0 0 0
Matrix B:
3x3 matrix is as follows
| 0 | 1 | 2 |
--------------------------------------------
0 | 0 0 0
1 | 1 0 0
2 | 1 0 0
now do the addition
root.exe(3946) malloc: *** error for object 0x147d194: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Matrix C = A + B:
3x3 matrix is as follows
| 0 | 1 | 2 |
--------------------------------------------
0 | 1 0 0
1 | 2 0 0
2 | 0 0 0
Matrix A += B:
3x3 matrix is as follows
| 0 | 1 | 2 |
--------------------------------------------
0 | 1 0 0
1 | 2 0 0
2 | 0 0 0
root [1]
I have found at least another 3 matrix configurations for this simple example, which behave in the same way.
For another example the script simply crashes before doing the sum.
root [0]
Processing testSparse.C...
Matrix A:
3x3 matrix is as follows
| 0 | 1 | 2 |
--------------------------------------------
0 | 0 1 1
1 | 0 0 0
2 | 0 0 0
Matrix B:
3x3 matrix is as follows
| 0 | 1 | 2 |
--------------------------------------------
0 | 0 0 0
1 | 1 0 0
2 | 1 0 0
now do the addition
root.exe(3952) malloc: *** error for object 0x147d1d4: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
*** Break *** bus error
===========================================================
There was a crash (#4 0x000de038 in SigHandler ()).
This is the entire stack trace of all threads:
===========================================================
...
I have tested the trunk (from April 2) and the addition seems to work ok now. But I see a crash when doing a+=b while c=a+b works ok. The log from the error is:
[code]*** Break *** segmentation violation
===========================================================
There was a crash (#4 0x00125048 in SigHandler ()).
This is the entire stack trace of all threads:
Thread 1 (process 2395): #0 0x918aa711 in wait4 () #1 0x919197c3 in system$UNIX2003 () #2 0x00127bce in TUnixSystem::StackTrace () #3 0x00124f70 in TUnixSystem::DispatchSignals () #4 0x00125048 in SigHandler () #5 #6 0x009204f3 in G__getexpr () #7 0x009b6433 in G__exec_statement () #8 0x0096091e in G__interpret_func () #9 0x00945f5c in G__getfunction () #10 0x00913989 in G__getitem () #11 0x00918848 in G__getexpr () #12 0x00927455 in G__calc_internal () #13 0x009cd461 in G__process_cmd () #14 0x000fc781 in TCint::ProcessLine () #15 0x000fbe8f in TCint::ProcessLineSynch () #16 0x00078e05 in TApplication::ExecuteFile () #17 0x0007689b in TApplication::ProcessLine () #18 0x010f254f in TRint::Run () #19 0x00001abe in main ()
[/code]
The crash doesn’t appear when I compile the script first.
I’m running on MAC OS X 10.6.3.
Is it possible to include this fix in one of the 5.22 patches?
with the script you posted (testSparse.C) and the current trunk I do not see any crashes on Linux 64bit. Valgrind doesn’t report any problems either. I.e. I cannot reproduce it.
your script works for me even on MacOS 10.6.2 32bit and 64bit with the current trunk ; the problem was likely related to the temporary object management code within CINT which was upgraded for v5.26.
We are not putting anything into the v5.22 patches branch unless an experiment officially requests it (e.g. because ROOT crashes its trigger or something as severe Sorry, you’ll have to move to v5.26.