I'm using the Fortran 77 version of ludcmp and when I try to run it I get the "segmentation fault" error message. I tracked the problem to the first instance of a(imax,k). It seems that imax has not been initialized and hence has a very large value, outside the bounds of the matrix.

Adding a imax=0 line seems to solve the problem. Is this a correct approach? Or should another initial value be more correct?

Thanks for your attention

David

I have to modify my previous post: indx=0 gives a wrong result. On the other hand indx=1 seems to work fine and the examples I tried give the correct solutions.

David

Dear David,

The f77 version of ludcmp has been around for a long time, and is almost certainly bug free by now. If you are having segmentation fault problems, that is often because you are calling the routine incorrectly (double vs. single precision, wrong arguments, etc.) Or if you typed in the routine by hand, you've made an error.

Good luck in sorting it out!

Saul Teukolsky

Dear Saul,
I agree with David that there is an error in ludcmp.f77 as it appears in your book (bought new in Oct 1991 at "Maryland Book Exchange"). I'd planned to include it in a larger program but first looked at it. The quantity IMAX is not initialised. Arbitrarily initialising it to 0 or 1 is not correct. Intuitively, IMAX=J looks better (as was done in http://algorithm.narod.ru/ln/crout.c). Yet this too may yield the wrong INDX array, for instance:

While in the 1st column, sweeping down through the rows, let IMAX be 4 => interchange rows 1 and 4 and set INDX(1)=4. Next, in the 2nd column, sweeping through rows 2 to N, let again row 4 (ex-row 1) provide the pivot => interchange rows 2 and 4 (row 2 is now ex-row 1 and row 4 has become row 2) and set INDX(2)=4. Continuing like this, it is possible to end with a final INDX array that has a 4 in the first four positions. This won't be of any use in the subsequent subroutine lubksb.f. Nor will the parity variable D be of any help. (D is not used at all, what is its purpose anyhow?)

Have a nice day - Rudi.

Dear Rudi and David,

I'm still skeptical there's a problem. There's nothing wrong with having duplicate entries in the indx array. These just specify the order of permutations for lubksb. (d is used if you want the determinant - see the text of NR).

If either of you have a matrix that produces a problem, I'd be happy to look at it. But as I said earlier, I doubt indx is causing any problem you're seeing.

Saul Teukolsky

Dear Saul,

When I wrote my previous email I had never used ludcmp.f77, but had thought of doing so. So I first looked through it and found, what I then thought were errors. I decided to stay with my old (1973) DP Gauss elimination with complete pivoting, but was forced to look at other options. Taking a fresh, and unstressed, look at ludcmp.f77 made me realise that it is as solid as diamond, of course!

I compared ludcmp.f77 (combined with lubksb.f77) in double precision with my old workhorse dpgeli.f77 and found no differences worth mentioning. The case which I tested involved roughly 75,000 7x7 and equally many 5x5 matrices!

My apologies for my earlier errings.

Have a nice day

i,ve a similar problem with ludcmp() in C++.
till 3 months i used the ludcmp() in FORTRAN; now i changed language and i have problem because the "segmentation fault" message appears. the strange thing is that in FORTRAN it runs.
i noted that it happens because the program don't execute the following part of routine:
if ((dum=vv[i]*Abs(sum)) >= big) {
big=dum;
imax=i;
}
and then it don't assign imax that have a random number.

someone have a suggestion?
melissa

Hi Melissa,

Do you have a sample matrix that shows the problem (the smaller the better)?

Saul Teukolsky

finally,
i succeed in doing to work my routine. it was an error in function that calculate the system solutions; i have forgotten a line when i have translated my routine.
sorry for my mistake.

Dear Saul,

I have encountered this problem on C during compilation at warning level W4 in Microsoft Visual C++ 6.00.
Indeed, compilator complains, that a variable imax is not initialized.

Probebly, You are right, that it isn't a bug according algorithm (only permutations of rows, function call should be with right parameters, etc...). However, generally, speaking, if code is not going to the for-loop operator on i or in if-operator without else branch, i_max value are not defined.

Suggested solution: initialize imax = j in any case as in court.c routine.

Thanks for a good book,
Evgeny

Dear Saul,

As addition to my previosuly e-mail: compilator complains also on not initialized l variable and nm valiable in svdcmp() routine.

Source is same. If, for example, You call svdcmp() with wrong input parameter (n=0), for-loop operator is not executed and above variables are not defined.

By the way, it is good check input parameters just at the begining of function: if (n<2) return(-1);

Evgeny