Brendan Tracey

We understand the importance of sparse matrices, but there is a significant coding burden in creating them. For one, there is a large diversity in sparse kinds. We are close...

The trick though is that there are so many kinds of sparse matrix. At least in my world of PDEs, it's almost always block-structured rather than random access. GMRES is...

Note that we already have this capability here: https://pkg.go.dev/gonum.org/v1/gonum/stat/sampleuv#WithoutReplacement Maybe we can just improve the implementation? I haven't read about the algorithm yet, so am unsure how vital the choose...

In the meantime, you could also use `LBFGS` or `Newton`. They both take advantage of gradient information and so should be much faster.

I'm not sure it fits into the current optimize package, just because it needs to take a specific functional form. I'm not sure if it should be in its own...

I would love there to be constrained optimization in Gonum. We already have an implementation of the Simplex algorithm, https://godoc.org/gonum.org/v1/gonum/optimize/convex/lp . It should be updated to work better with interfaces...

There's room in `convex/lp` more more algorithms. I'd be happy to work help change the API that's more amenable to sparse matrices if you're interested in helping build the package.

I don't mean a sparse matrix package itself, but re-designing Simplex such that it takes in an appropriate interface type instead of `*Dense`. See https://github.com/gonum/exp/tree/master/linsolve for one example of this....

Linear programs should not implement `optimize.Method`. `optimize` is built for nonlinear optimization. LPs are a specific class of optimization problem, and so should have their own specialized signature. Please take...

Maybe. It could be useful. It also seems possible that we can code re-use by just using functions rather than having a `Method` interface. The big utility in `Method` for...