Open standy66 opened 4 years ago
The reasoning behind this is mostly a game theory thing.
The tensor.Slice
interface is the primary method in which tensors are sliced. That means anything that implements the tensor.Slice
interface can be passed into a .Slice(...)
method as required by the tensor.Tensor
interface.
The main reasoning behind the Slice
interface is so that a Gorgonia Op
(*sliceOp
) can implement tensor.Slice
. This is to facilitate a symbolic representation of operations in package tensor
.
Not exposing the internal concrete structures was basically a way to enforce that a proper think through is required when using slices. For example, in a logic programming language I created using package tensor
, I had to think hard about using slices. In the video I linked, I mentioned that the CKY parse produces a matrix of something called a CatSpanner
. A CatSpanner
also implements tensor.Slice
. It's a pretty sophisticated use. Had I exposed the internal concrete structure I would have used it but then I would have to create a new type that does something different for CatSpanner
.
Furthermore, exposing the internal concrete type that implements Slice would simply add to the confusion - e.g. why are there so many types of notion of slice!?
Now, I will admit that this causes usability issues - if you have to reimplement the interface every time it would be very inconvenient!
I'm open to suggestions - the best suggestion so far was that we should have another package - a tensorutils
package, which comes with all the helpers.
Another suggestion is something like gorgonia.S which simply exports makeRS
.
Happy to hear your thoughts. @standy66
Hi! I would like to use this library for tensor manipulations in Golang. Is there any reason as to why range slices and single element slices are not exported in slice.go? It would be very convenient if they were exported, e.g. like this: