You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Eventually we're going to have to propagate Shape and Allocator instances through the expression layer. This issue is for Shape.
IMHO propagation is easier if we define arithmetic operations for Shape. For example:
// Let these be the shapes for tensors A, B, and C respectively
Shape a, b, c;
// Now if we want c to be the shape C has after doing C("i,j") = A("i,j") + B("i,j")// we compute that by:
a.add("i,j", "i,j", c, "i,j", b);
The syntax here mirrors that of the Buffer class.
For implementing the arithmetic it's a matter of working out the dimensions given the input indices and the operation. The trickiest part is going to be accounting for sparsity in the derived class if need be.
The text was updated successfully, but these errors were encountered:
Issue Description
Eventually we're going to have to propagate
Shape
andAllocator
instances through the expression layer. This issue is forShape
.IMHO propagation is easier if we define arithmetic operations for
Shape
. For example:The syntax here mirrors that of the
Buffer
class.For implementing the arithmetic it's a matter of working out the dimensions given the input indices and the operation. The trickiest part is going to be accounting for sparsity in the derived class if need be.
The text was updated successfully, but these errors were encountered: