Provides LAPACK.stein!() and hooks in SymTridiagonal #2678

Merged
merged 2 commits into from Mar 26, 2013

Conversation

Projects
None yet
3 participants
@jiahao
Member

jiahao commented Mar 25, 2013

Squashes and cleans up commits from #2654 to date.

Provides LAPACK.stein!() and hooks in SymTridiagonal
Provides eigvecs() methods to return just the eigenvectors

in lapack.jl:
Changed LapackException to LAPACKException
Changed LapackDimMisMatch to DimensionMismatch

in tridiag.jl:
new eigvec method() to return just eigenvectors
optionally takes eigenvalues to return corresponding eigenvectors
@ViralBShah

This comment has been minimized.

Show comment Hide comment
@ViralBShah

ViralBShah Mar 25, 2013

Member

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

Member

ViralBShah commented Mar 25, 2013

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

@jiahao

This comment has been minimized.

Show comment Hide comment
@jiahao

jiahao Mar 25, 2013

Member

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?

Member

jiahao commented Mar 25, 2013

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

This comment has been minimized.

Show comment Hide comment
@ViralBShah

ViralBShah Mar 25, 2013

Member

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.

Member

ViralBShah commented Mar 25, 2013

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

This comment has been minimized.

Show comment Hide comment
@ViralBShah

ViralBShah Mar 25, 2013

Member

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

Member

ViralBShah commented Mar 25, 2013

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

This comment has been minimized.

Show comment Hide comment
@jiahao

jiahao Mar 25, 2013

Member

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

Member

jiahao commented Mar 25, 2013

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

@andreasnoack

This comment has been minimized.

Show comment Hide comment
@andreasnoack

andreasnoack Mar 25, 2013

Member

@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.

Member

andreasnoack commented Mar 25, 2013

@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

This comment has been minimized.

Show comment Hide comment
@jiahao

jiahao Mar 26, 2013

Member

@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.

Member

jiahao commented Mar 26, 2013

@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

This comment has been minimized.

Show comment Hide comment
@ViralBShah

ViralBShah Mar 26, 2013

Member

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

Member

ViralBShah commented Mar 26, 2013

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

@andreasnoack

This comment has been minimized.

Show comment Hide comment
@andreasnoack

andreasnoack Mar 26, 2013

Member

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

Member

andreasnoack commented Mar 26, 2013

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

@andreasnoack

This comment has been minimized.

Show comment Hide comment
@andreasnoack

andreasnoack Mar 26, 2013

Member

@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.

Member

andreasnoack commented Mar 26, 2013

@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

This comment has been minimized.

Show comment Hide comment
@jiahao

jiahao Mar 26, 2013

Member

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

Member

jiahao commented Mar 26, 2013

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

@jiahao

This comment has been minimized.

Show comment Hide comment
@jiahao

jiahao Mar 26, 2013

Member

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

Member

jiahao commented Mar 26, 2013

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

ViralBShah added a commit that referenced this pull request Mar 26, 2013

Merge pull request #2678 from jiahao/stein2
Provides LAPACK.stein!() and hooks in SymTridiagonal

@ViralBShah ViralBShah merged commit e722a20 into JuliaLang:master Mar 26, 2013

1 check passed

default The Travis build passed
Details
@ViralBShah

This comment has been minimized.

Show comment Hide comment
@ViralBShah

ViralBShah Mar 26, 2013

Member

Thanks for persisting through with this one.

Member

ViralBShah commented Mar 26, 2013

Thanks for persisting through with this one.

@jiahao jiahao deleted the jiahao:stein2 branch Mar 26, 2013

@jiahao jiahao referenced this pull request Apr 11, 2013

Closed

0.2 release notes #2581

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment