native: mark internal routines #113
Conversation
|
Fixes #35. clapack is harder - maybe just ignore that. |
|
Is the policy that a function is internal by default? For example, I could see mat64 wanting to use dlatrs. If we decided that's true, we would just remove the internal comment? |
|
Yes, and we would add Dlatrs to the lapack64 interface.
I intially went through and started to make these unexported, but realised (late) that then testing would break.
|
|
ping |
|
clapack is internal by default probably. If we really want the functions to be uncallable, we could have a wrapper type that lives in native_test.go and exports them. It's not clear we want this. On the one hand, it's nice to allow direct access for advanced users, but on the other hand I don't know that we want to promise API stability for them. Maybe stability only extends to lapack64? We already can't promise to keep clapack stable. |
| // At minimum, lwork >= max(m,n) + max(m,n,nrhs), and this function will panic | ||
| // otherwise. A longer work will enable blocked algorithms to be called. | ||
| // In the special case that lwork == -1, work[0] will be set to the optimal working | ||
| // length. | ||
| // | ||
| // Dgels is an internal routine. It is exported for testing purposes. |
There was a problem hiding this comment.
It's part of lapack.Float64, so I don't think this is internal. We don't actually use it anymore in mat64, so we could remove it if we would like.
There was a problem hiding this comment.
I missed that it was there. We need to make a decision about whether to keep it before the API promise.
|
LGTM with Dgels fixed. |
These (generally) cannot be made unexported because we test via testlapack. Also fix a name and some capitalisation.
Possibly.
Yes. |
@btracey Please take a look.