LAPACKE.sgesdd returned -5 (LA::LinAlgError)

[yxhuvud]

So, I'm playing around with fairly large arrays and keep getting the following stacktrace while invoking svd when working with large but not super large matrixes (around 25k rows x 200-500 columns):

LAPACKE.sgesdd returned -5 (LA::LinAlgError)
  from /usr/share/crystal/src/crystal/main.cr:0:3 in 'main'
  from /usr/share/crystal/src/io/file_descriptor.cr:86:5 in 'seek'
  from _start
  from ???

I have tried reading both the code (linalg.cr) and sgesdd.f, but I havn't been able to figure out what the actual problem is. The actual point where it crashes seem to be very variable, I've seen everything from 150 to 500 columns both work and crash, but more crashes on large values.

[konovod]

-5 in lapack means "5-th argument has the wrong value". 5-th argument of sgesdd is LDA (= ncolumns). I'm not sure what this can mean, will try to investigate.

I think i should note the general problem of the library - it is using row major matrix storage (because well, lapacke allowed me to do it). Now i know that (aside from incompatibility with OSX) this means that most LAPACKE routines transpose the matrix, calls fortran code and then transpose result. I don't think it can cause your particular problem. but still isn't good for big matrices and i'm going to fix it (perhaps just convert everything to column major storage).

[yxhuvud]

-5 in lapack means "5-th argument has the wrong value". 5-th argument of sgesdd is LDA (= ncolumns).

Yes, that is about how far I got when investigating. I also tried putting in nrows there (in case it was a typo or misunderstanding), but no obvious change of results.

Oh well, I think my problem is big enough that I need sparse matrix representation anyhow. I wonder if there exist any open source library using newer algorithms than svdlibc - there has been quite a lot of research in the area since the 90s when it was originally written. Oh well.