Repository navigation
Rename MLOperandDescriptor's dimensions to shape #669
Description
Activity
shape is widely used by other ML frameworks
Seems like a tossup, as "dimensions" is widely used by ML libraries too: XNNPACK
dims, ANNdimensions, DMLDimensionCountandSizes, MPSMPSNDArraySizes, CudNNCUDNN_ATTR_TENSOR_DIMENSIONS, OneDNNdnnl_dims_t. 🤷♂️"dimensions" is ambiguous, since it can mean [rank or list of dimensions] ...
Interestingly that ambiguity also applies to a field named
cats, as you can have a list of cats (std::vector<Cats> cats = {"Fido", "Garfield", "Heathcliffe"}) or a count of cats (uint32_t cats) depending on vector vs scalar usage. 😺 Really though, we should shore up the specification to consistently use rank when we mean rank, not sometimes loosely refer to "dimensions" to mean rank.Updated my comment with everyone's pro's/con's statements so far, but I have one other idea on #676 (comment)... 🔍.
🤔 Have you considered
sizes? It avoids the concern withdimensions(list of dimensions vs dimension count), it's equally short asshapeand easy to spell, and it avoids the grammatical issues withshape("... shape excludes information about the object's location, scale, orientation, and reflection... [unlike a] figure [which] is a representation including both shape and size..." [1]).Using
sizesinstead ofdimensionsindeed avoids some confusion, but adds some other... and it's less "standard" (de facto) thanshapeis. All these terms are overloaded. Since Web NN is targeting framework developers, and the termshapeis well known among them (list of tensor component dimension counts, whose length is the rank and whose indices are the axes), I'd slightly prefershape, but I'd not be confused usingsizes, provided we include definitions in the spec.
As discussed in #666:
"shape" is the more widely used term, so I propose we align on that. WDYT?