Provides LAPACK.stein!() and hooks in SymTridiagonal

[jiahao]

Squashes and cleans up commits from #2654 to date.

[ViralBShah]

Thanks. Do we know why this is failing? Is it the stebz thing?

[jiahao]

Summary to date: the test fails because _stein in LAPACK throws a -6 error, which I think means it doesn't like the iblock input to it. iblock is supposed to be returned from _stebz and says something about the subspace of the matrix the desired eigenvectors reside. I have two variants of stein! which either accepts iblock input or creates iblock manually to tell _stein to look in the entire vector space spanned by the matrix. There are two tests testing each variant. Both of them currently fail with the same error. On x86_64/OpenBLAS and OSX 10.8.3/OpenBLAS this error doesn't occur. @andreasnoackjensen has observed this error with MKL so this appears to be a MKL-specific issue?

[ViralBShah]

If this is one of those travis-only errors, we may need to comment out the tests - or else every single build will fail. I will take a look too.

[ViralBShah]

It seems that stein expects iblock to be of size n, but stebz is returning iblock[1:m[1]]. Could that be a problem?

[jiahao]

I don't think so. In lapack.jl:1427 iblock_in is explicitly padded with zeroes to become of length n.

[andreasnoack]

@ViralBShah It is related to 32 bit LAPACK. I have just tried this branch on julia.mit.edu with USE_LIB64 = 0 and there I get the error.

[jiahao]

@andreasnoackjensen how did you get a 32-bit compile on julia.mit.edu? I tried this with make USE_LIB64=0 but it keeps wanting to compile 64-bit objects.

I am beginning to wonder if the problem might be iblock being declared as an array of Int64 even for the 32-bit platform, and if this can be fixed by explicitly declaring iblock and isplit as Array(BlasInt,n) and then populating its entries explicitly rather than with the concatenations in linalg.jl:1424-33.

[ViralBShah]

In all the BLAS and LAPACK wrappers, you should always use BlasInt.

[andreasnoack]

@jiahao You'll need to delete the dynlibs in deps/openblas* for USE_LIB64=0 to have effect.

[andreasnoack]

@jiahao You were right about the declaration of the variables. By defining iblock=[ones(BlasInt, m), Array(BlasInt,n-m)] the error disappears. If you change that line, hopefully the Travis tests will pass and your branch can be merged. However, we are having a very open issue in #1804.

[jiahao]

We have finally trapped the hideous beast which has been so hard to capture these past few days.

[jiahao]

@ViralBShah the error was in assuming that concatenation would return an array of the correct BlasInt type.

[ViralBShah]

Thanks for persisting through with this one.