Returns NaN for all of the elements.

This is a reminder issue that arose in #160

In lapack.go, maybe some types can be removed/merged, maybe there are better names for the types and constants, ...

• Dlarfb
• Dlarfg
• Dlarft
• Dlacn2
• Dlapy2
• Dlascl
• Dlaset
• Dlasrt
• Dlaswp
• Dorgql
• Dorgtr
• Dsteqr
• Dsterf
• Dsytrd

This is a complicated issue. The tests for Dormbr and Dormlq are commented out with reference to OpenBLAS issues and PRs. The issues have been closed and the PRs have been merged. This would suggest that these tests could and should be uncommented. I have just tried that, and they fail.

$ CGO_LDFLAGS="-L/usr/local -lopenblas" go test -run Dormlq
*** Error in `/tmp/go-build141511666/github.com/gonum/lapack/cgo/_test/cgo.test': free(): invalid next size (fast): 0x00000000028bb7b0 ***
[more]

$ CGO_LDFLAGS="-L/usr/local -lopenblas" go test -run Dormbr
 ** On entry to DORMBRP parameter number 13 had an illegal value
[more]

All values of ul are valid, not only U and L.

1. Why use int32, why not int?
2. In case of iwork or ipiv parameters, they are arrays of int. However, in ?trexc, ifst and ilst are just single in/out integers, so using a slice for them seems inappropriate.

All of clapack can be noted as not really for public consumption (though not in flux - essentially the same as the std syscall package).

Methods in native are present in many cases because they are dependencies for routines that are published in lapack.Float64. We can either unexport them in the short term (probably the correct answer for things like Ilaenv that have been noted as targets for removal) or just document them as internal.

A NaN matrix is orthonormal according to isOrthonormal.

dggsvd3 implements Generalised Singular Value Decomposition that has uses in signal processing and genomics.

• dggsvd3
• - dtgsja
• -- dlapll
• -- dlags2
• - dggsvp3
• -- dlapmt
• -- dgeqp3
• --- dlaqps
• --- dlaqp2
• -- dgerq2
• -- dormr2
• --- dgerqf (required for testing)

Reference LAPACK allows any value of INCX.

How do we decide which of the lapack functions to include in the interface?
Should we just do it on a per need basis?

• dgecon.go
• dpocon.go
• dgetf2.go
• dlaev2.go
• dlansy.go
• dtrcon.go
• dlantr.go
• drscl.go
• dgetrs.go
• dtrti2.go
• dgetri.go
• dlacpy.go
• dtrtri.go
• dgetrf.go

In some places '(' and ')' are used, while in others '[' and ']' are used. We should be consistent, but a choice needs to be made first.

Debugging build failures is very difficult without this information.

As has been mentioned and approved elsewhere (#161), lapacke seems to be a more accurate name for the package.

LAPACK is an acronym for Linear Algebra PACKage and should be in all caps. Go is a proper noun and should begin with a capital. There is no way to modify it with a pull request so this issue will be used instead.

PTAL

The comment says:

// ... lwork == -1 will not run Dormqr but will instead write the minimum
// work necessary to work[0]. If len(work) < lwork, Dormqr will panic.

The code does:

        if lwork == -1 {
                 if left {
                         work[0] = float64(m)
                         return
                 }
                 work[0] = float64(n)
                 return
         }

         if left {
                 if lwork < n {
                         panic(badWork)
                 }
         } else {
                 if lwork < m {
                         panic(badWork)
                 }
         }

That is,

1. Values put into work[0] and checked values of lwork seem to be swapped.
2. len(work) < lwork is not checked.

We do pass provided work slices to LAPACKE functions since #137.

There are a number of routines in native that have naked returns or returns that are unnecessary because of other flow control:

Dgetrf, Dlacpy, Dlaswp, Dlatrs, Dorml2, Dormlq, Dormqr and Dtritri.

If a test is run with m=3, p=3, n=5 the code at line 264 panics with a bounds check failure.

--- FAIL: TestDggsvp3 (0.00s)
panic: runtime error: slice bounds out of range [recovered]
	panic: runtime error: slice bounds out of range

goroutine 5 [running]:
testing.tRunner.func1(0xc4200724e0)
	/home/daniel/Development/go/src/testing/testing.go:622 +0x29d
panic(0x6a1fc0, 0x895c00)
	/home/daniel/Development/go/src/runtime/panic.go:489 +0x2cf
github.com/gonum/lapack/native.Implementation.Dggsvp3(0x515655, 0x3, 0x3, 0x5, 0xc420080980, 0xf, 0xf, 0x5, 0xc420080a80, 0xf, ...)
	/home/daniel/Development/src/github.com/gonum/lapack/native/dggsvp3.go:264 +0xcf0
github.com/gonum/lapack/native.(*Implementation).Dggsvp3(0x8b84e8, 0x515655, 0x3, 0x3, 0x5, 0xc420080980, 0xf, 0xf, 0x5, 0xc420080a80, ...)
	<autogenerated>:25 +0x28b
github.com/gonum/lapack/testlapack.Dggsvp3Test(0xc4200724e0, 0x857340, 0x8b84e8)
	/home/daniel/Development/src/github.com/gonum/lapack/testlapack/dggsvp3.go:109 +0xd20
github.com/gonum/lapack/native.TestDggsvp3(0xc4200724e0)
	/home/daniel/Development/src/github.com/gonum/lapack/native/lapack_test.go:116 +0x5b
testing.tRunner(0xc4200724e0, 0x6e5600)
	/home/daniel/Development/go/src/testing/testing.go:657 +0x96
created by testing.(*T).Run
	/home/daniel/Development/go/src/testing/testing.go:697 +0x2ca
FAIL	github.com/gonum/lapack/native	0.005s

genLapack.pl gives comp? named variables always the type lapack.CompSV. ?trexc routines are not related to SVD, so a better type would be lapack.EigComp.

Dormqr computes the maximum number of columns of a work matrix nwxnb that fits into available workspace. If lwork is not long enough to hold the optimum block size nb, nb is reduced. The code however doesn't update ldwork, leaving it at the previous, unnecessarily large value. If the workspace is long enough to use the blocked code but not long enough to hold the nwxnb matrix, Dlarfb will panic later.

    ldwork := nb // nb is the optimal block size as returned from Ilaenv.
    if nb > 1 && nb < k {
        iws := nw * nb
        if lwork < iws {
            nb = lwork / nw
            // ldwork = nb // <--- Uncommenting fixes the issue.
            nbmin = max(2, impl.Ilaenv(2, "DORMQR", opts, m, n, k, -1))
        }
    }

Speaking of Dormqr, why is t allocated in Dormqr and not taken from work as in the reference LAPACK, @btracey ?

Sorry if I'm out of place here, but can you refer me to a simple "main.go" that uses the lapack package you've contributed? It's really enticing, but I don't have anywhere to start (in go).