flat id definition

Tensor exposes two reciprocal functions getIdx and getCoord that convert between tensor coordinates and "flat id".
To this day, the flat id is not formally defined and is implemented as the index of the given data coordinates in the storage associated to the tensor.
Yet, in recommended new tensor design, storage may encompass an area larger than the one exposed by the tensor (for instance, if the tensor is only a view inside a larger tensor). This has three major consequences:

• for a given tensor, its first data (lexicographical order) has a flat id that is >= 0 but not necessarily 0;
• more important: this id may not be computable while data is not actually allocated;
• this id may change in time if storage is reallocated.

No concrete use case of these functions were available so far so this issue went undetected. But now, functions such as computeReceptiveField are relying on this flat id.

Thus 2 questions are occurring:

• why would this flat id be required (in computeReceptiveField for instance) instead of plain coordinates (for efficiency reasons?)?;
• shouldn't the flat id definition be modified as follow: 0-based index in the tensor exposed area, in lexicographical order (thus, the first data, lexicographical order, of the tensor would have flat id 0 and the last one (same order) would have, as value, the number of visible data in the tensor, minus 1 (ie the result of size()))?

changed milestone to %v0.1.0

added Discussion Important LanguageC++ RefactoringDesign 🎨 ObjectTensor labels

assigned to @pineapple, @cmoineau, and @olivierbichler

changed the description

mentioned in issue #60 (closed)

computeReceptiveField() will be changed in the near future to return plain coordinates.

Indeed in the case of TensorViews pointing to parts of a Tensor, there are two possibilies:

• return the id of the original greater Tensor contiguous in memory
• return an abstract 0-based flat id like if the TensorView was contiguous in memory

Did I understand the two possibilities correctly?

Yes.
In #42 (closed), first hypothesis is implemented. As a consequence, returned ID depends on the actual TensorImpl. Yet, as far has I can guess actual user needs, I think that the second hypothesis should be enforced EXCEPT if it is eventually concluded that flat id should nether be used in the API (only coordinates).

NB getter and setter function are also concerned by this issue (see #60 (closed)) and are used in FuseBatchNorm operator.

Regarding the efficiency question, you need to write loops that are aware of the memory layout in order to be efficient (see #49 (closed)). Otherwise, access through flat id will require additional tests and computation to compute the memory id which would defeat the expected execution gain.

Thus I would be inclined to use

an abstract 0-based flat id like if the TensorView was contiguous in memory

or remove totally the flat id from high-level API.
A flat id at TensorImpl level could be used by operator implementers in order to write fast loops (see #49 (closed) again).

And how do you handle looping through tensor in the case of FuseBatchNorm ? Or if a user wants to easily access/modify tensor values ?

From how I understand it, this proposition bring to much complexity IMO.

On how to loop efficiently on non-totally contiguous data structure: #49 (closed)

On Tensor values access: getter and setter are still available (#60 (closed))

I don't "add complexity", I provide the most straightforward and generic solution to parse tensor that are only contiguous up to some dimension (which will necessarily appear at some point (tiling, extract, view, whatever...).

!13 (closed) has been updated to implement 0-based lexicographic flat id for Tensor.

Again and again: I don't propose "exotic designs" but well known ones, for instance in multi-spectral imagery.

mentioned in commit f757aa48

mentioned in merge request !13 (closed)

unassigned @cmoineau

Currently, this issue seems obsolete considering the current design of Tensor where the flat id is well defined: it is the 0-based index in the tensor exposed area, in lexicographical order.

See code documentation:

    /**
     * @brief From the the 1D contiguous index, return the coordinate of an element in the tensor.
     * Beware: do not use this function with the storage index!
     *
     * @param flatIdx 1D contiguous index of the value considering a flatten, contiguous, tensor.
     * @return std::vector<DimSize_t>
     */
    std::vector<std::size_t> getCoord(std::size_t flatIdx) const;

    /**
     * @brief From the coordinate returns the 1D contiguous index of an element in the tensor.
     * If the number of coordinates is inferior to the number of dimensions,
     * the remaining coordinates are assumed to be 0.
     * Beware: the contiguous index will only correspond to the storage index
     * if the tensor is contiguous!
     * Note that the coordIdx may be an empty vector.
     *
     * @param coordIdx Coordinate to an element in the tensor
     * @return DimSize_t Contiguous index
     */
    std::size_t getIdx(const std::vector<std::size_t>& coordIdx) const;

    }

    /**
     * @brief From the coordinate returns the 1D storage index of an element in the tensor.
     * If the number of coordinates is inferior to the number of dimensions,
     * the remaining coordinates are assumed to be 0.
     *
     * @param coordIdx Coordinate to an element in the tensor
     * @return DimSize_t Storage index
     */
    std::size_t getStorageIdx(const std::vector<std::size_t>& coordIdx) const;

closed