3fd5f breaks Dtrsm via gonum/matrix/mat64 tests about blas

[btracey]

I do not see this panic on my machine, either with cblas or goblas. Which cblas implementation are you using?

On Jun 5, 2014, at 5:08 PM, kortschak [email protected] wrote:

It seems we didn't test cblas in the context of mat64 for 3fd5f07; there was no commit to matrix reflecting the changes in blas. I have made those changes and now we get an out of range in TestSolve and TestLQD. TestLQD hides the panic, but TestSolve shows it to be in the Dgemv. This is not observed in a36aa1f.

—
Reply to this email directly or view it on GitHub.

[kortschak]

OK, this is down to the clever use of blas.ColMajor in mat64.LQFactor.applyQTo(). cblas looks fine - mat64 needs fixing.

[btracey]

I lied. Ignore my comment about the tests passing. Did you push the matrix changes up? I still see them in dense_arithmetic (for example).

On Jun 5, 2014, at 5:35 PM, kortschak [email protected] wrote:

OK, this is down to the clever use of blas.ColMajor in mat64.LQFactor.applyQTo(). cblas looks fine - mat64 needs fixing.

—
Reply to this email directly or view it on GitHub.

[kortschak]

No, I have made not changes to the upstream master - I'd like to get this fixed first, but it might be something for @dane-unltd since he wrote that code. I'll see what I can do.

[kortschak]

I believe I have fixed this. Will close.