Why is shape a separate member in tensor?

[tgkolda]

It seems that having shape as a separate member in the tensor class is redundant. I could only imagine that it might be for tracking 0-dimensional shapes, but this doesn't seem to be checked for or happening in any consistent way.

For example:

print('Creating a tensor with no arguments')
X = ttb.tensor()
print(X.data)
print(X.shape)

print('Creating a tensor with an empty numpy array')
X = ttb.tensor(np.array([]))
print(X.data)
print(X.shape)

Produces:

Creating a tensor with no arguments
[]
()
Creating a tensor with an empty numpy array
[]
(0,)

Is it possible to remove this and instead make shape a function that returns the shape of the data?

Also, is there a reason to allow for empty tensors?

[tgkolda]

Related, why is order being tracked as a separate property? I think we should just use the numpy facilities for these (shape and order) rather than duplicating.

[ntjohnson1]

There are a few questions here spanning design choices and implementations.

Design Decisions:

1. It seems that having shape as a separate member in the tensor class is redundant. I'd disagree, every tensor should have its own shape without digging into internal details. This makes things more consistent across our different tensor types.
2. I think we should just use the numpy facilities for these (shape and order) rather than duplicating. For order numpy switches between C and fortran order as convenient (for instance in a matrix transpose). I think with higher order tensors and indexing we need to be a little more careful than they are. Additionally, numpy supports arbitrary stride patterns (C,F, and custom). I don't expect us to attempt to support arbitrary strides so I don't think we can just use numpy's strategy.
3. is there a reason to allow for empty tensors? I can't recall a NEED for them, but if there isn't a conceptual reason to block their existence it seems reasonable to have a default empty option.

Implementation details:

1. The delta in your code example should be resolved. That looks like a bug.
2. We could probably make shape a property where we just extract it every time from our underlying data source. But besides the edge case you mentioned I'm not sure how high of a priority this is since I only see it slightly cleaning up the tensor class.

[tgkolda]

This is helpful. Thanks!

The reason for the shape is that there is redundancy in keeping the shape twice and ensuring they're consistent. Would there be any objection to such a change if I implemented it? (Not promising to do so, but I might give it a whirl.)

[ntjohnson1]

No objection. It would be good to make an issue for it first.

I expect that you'll need to convert the numpy shape (that I think that comes as an array) to a tuple of ints and annotate the return correctly on the property in order for the static inspection from mypy to confirm everything is consistent. We can discuss further on the issue or PR if the typing part causes problems.