Hi kortschak, thanks for replying. Please correct me if I'm not following this right. So on Line 290 <https://github.com/gonum/gonum/blob/620965de6d2b527d48f4f32daec0a38fe341da1c/mat/dense.go#L285> of the Dense.Slice() method, the receiver is copied into the variable 't' by dereferencing the pointer, then the underlying data slice is sliced (easy to slice rows vs cols) with the method you have used. I do not understand what is happening with the capRows and capCols. Seems to me that there are two types of dimensions being maintained here. One for the underlying General datatype and another for the Dense type. It would be great if you could help me understand this so that I may be able to adapt it to my <https://play.golang.org/p/TQMdNLBbCi>implementation linked to in the question. Here <https://play.golang.org/p/vTvlYpWL40> is my attempt at adapting the Slice method you pointed. I'm not getting the right answer, meaning I'm missing something. Could you please point it out?
On Saturday, August 12, 2017 at 11:50:59 PM UTC+1, kortschak wrote: > > We implement this for first and second order tensors in > gonum.org/v1/gonum/mat[1] <http://gonum.org/v1/gonum/mat%5B1%5D>, which > you are welcome to borrow from to > extend to third order. Our slice operation[2] is in principle non- > allocating (though we do allocate a container for generality - a non- > allocating version would simply not return the pointer type for the > Dense). > > [1]https://godoc.org/gonum.org/v1/gonum/mat > [2]https://godoc.org/gonum.org/v1/gonum/mat#Dense.Slice > > On Sat, 2017-08-12 at 07:14 -0700, chatrapa...@gmail.com <javascript:> > wrote: > > So I've written a small Tensor library for purposes of various > > computations > > inside a hardware product that my startup is working on. I've > > implemented > > in the library, the functionality to slice a matrix similar to matlab > > using > > a proxy. The implementation, I have works just fine and does exactly > > what I > > want, albeit with one hiccup, every time I slice the matrix, it > > allocates > > for the proxy. This caused a problem inside hot loops. Hence, I > > implemented > > the same functionality by allowing the user to pre-allocate the proxy > > and > > slice the matrix into it, thus eliminating the problem. However, I'd > > like > > to know if the size of the proxy can be reduced any further or a > > more > > efficient way to achieve the same functionality? Relevant runnable > > code can > > be found here <https://play.golang.org/p/TQMdNLBbCi> > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
