Skip to content
This repository was archived by the owner on Nov 24, 2018. It is now read-only.

Conversation

@btracey
Copy link
Member

@btracey btracey commented Aug 10, 2015

No description provided.

@kortschak
Copy link
Member

kortschak commented Aug 10, 2015 via email

@btracey
Copy link
Member Author

btracey commented Aug 10, 2015

It does? From Netlib Dgels: "The leading dimension of the array B. LDB >= MAX(1,M,N)."

B is an M x NRHS matrix. X is an N x NRHS matrix. Both of these matrices have to fit into B, so the number of rows has to be at least max(m,n)

@kortschak
Copy link
Member

The issue is that NETLIB makes the check of ldb against max(m, n), but uses mn = min(m, n) for checking against lwork.

      INFO = 0
      MN = MIN( M, N )
      LQUERY = ( LWORK.EQ.-1 )
      IF( .NOT.( LSAME( TRANS, 'N' ) .OR. LSAME( TRANS, 'T' ) ) ) THEN
         INFO = -1
      ELSE IF( M.LT.0 ) THEN
         INFO = -2
      ELSE IF( N.LT.0 ) THEN
         INFO = -3
      ELSE IF( NRHS.LT.0 ) THEN
         INFO = -4
      ELSE IF( LDA.LT.MAX( 1, M ) ) THEN
         INFO = -6
      ELSE IF( LDB.LT.MAX( 1, M, N ) ) THEN
         INFO = -8
      ELSE IF( LWORK.LT.MAX( 1, MN+MAX( MN, NRHS ) ) .AND. .NOT.LQUERY ) THEN
         INFO = -10
      END IF

cgo/lapack.go Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks to me like the real fix is to change the line below (no comment available there) to checkMatrix(max(m, n), nrhs, b, ldb), and revert this.

@btracey
Copy link
Member Author

btracey commented Aug 12, 2015

Yep. You're totally right. Sorry. Fixed.

@btracey
Copy link
Member Author

btracey commented Aug 12, 2015

Again, I don't understand, one fails on 1.4, the other on 1.5rc1.

@btracey
Copy link
Member Author

btracey commented Aug 12, 2015

Ah, I see what you mean by "real failure". It's a time out test failure, and doesn't seem to be consistent as to which test it fails on. Maybe we should increase the test timeout to 20minutes?

@kortschak
Copy link
Member

What concerns me is the fact that there is such a discrepancy in the amount of time it takes to complete cgo tests on travis compared to a local machine - it's seconds on my laptop and ~ten minutes on travis. This really indicates to me something is not right.

@kortschak
Copy link
Member

LGTM

@btracey
Copy link
Member Author

btracey commented Aug 13, 2015

I agree that it's weird. It seems like it has to be a cgo problem or a travis problem. If it's a travis problem there's nothing we can do about it. I don't know how to test if it's a cgo problem. We're running on different operating systems and it's fine 100% of the time (so far) on my machine.

btracey added a commit that referenced this pull request Aug 13, 2015
Fix Dgels to check the correct dimension
@btracey btracey merged commit e171b40 into master Aug 13, 2015
@btracey btracey deleted the fixdgels branch August 13, 2015 00:04
@kortschak
Copy link
Member

I think Seb's answer is probably the reality.

@btracey
Copy link
Member Author

btracey commented Aug 13, 2015

Seb's answer?

@kortschak
Copy link
Member

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants