Documentation

An index function is a mapping from a multidimensional array index space (the domain) to a one-dimensional memory index space. Essentially, it explains where the element at position [i,j,p] of some array is stored inside the flat one-dimensional array that constitutes its memory. For example, we can use this to distinguish row-major and column-major representations.

An index function is represented as a sequence of LMADs.

LMAD's representation consists of a general offset and for each dimension a stride, rotate factor, number of elements (or shape), permutation, and monotonicity. Note that the permutation is not strictly necessary in that the permutation can be performed directly on LMAD dimensions, but then it is difficult to extract the permutation back from an LMAD.

LMAD algebra is closed under composition w.r.t. operators such as permute, index and slice. However, other operations, such as reshape, cannot always be represented inside the LMAD algebra.

It follows that the general representation of an index function is a list of LMADS, in which each following LMAD in the list implicitly corresponds to an irregular reshaping operation.

However, we expect that the common case is when the index function is one LMAD -- we call this the "nice" representation.

Finally, the list of LMADs is kept in an IxFun together with the shape of the original array, and a bit to indicate whether the index function is contiguous, i.e., if we instantiate all the points of the current index function, do we get a contiguous memory interval?

By definition, the LMAD denotes the set of points (simplified):

{ o + Sigma_{j=0}^{k} ((i_j+r_j) mod n_j)*s_j, forall i_j such that 0<=i_j<n_j, j=1..k }

Compute the flat memory index for a complete set inds of array indices and a certain element size elem_size.

iota.

iota with offset.

Permute dimensions.

Rotate an index function.

Reshape an index function.

Slice an index function.

Rebase an index function on top of a new base.

Shape of an index function.

The number of dimensions in the domain of the input function.

If the memory support of the index function is contiguous and row-major (i.e., no transpositions, repetitions, rotates, etc.), then this should return the offset from which the memory-support of this index function starts.

Similar restrictions to linearWithOffset except for transpositions, which are returned together with the offset.

Is this is a row-major array?

Is this a row-major array starting at offset zero?

Substitute a name with a PrimExp in an index function.

Generalization (anti-unification)

Anti-unification of two index functions is supported under the following conditions: 0. Both index functions are represented by ONE lmad (assumed common case!) 1. The support array of the two indexfuns have the same dimensionality (we can relax this condition if we use a 1D support, as we probably should!) 2. The contiguous property and the per-dimension monotonicity are the same (otherwise we might loose important information; this can be relaxed!) 3. Most importantly, both index functions correspond to the same permutation (since the permutation is represented by INTs, this restriction cannot be relaxed, unless we move to a gated-LMAD representation!)

When comparing index functions as part of the type check in KernelsMem, we may run into problems caused by the simplifier. As index functions can be generalized over if-then-else expressions, the simplifier might hoist some of the code from inside the if-then-else (computing the offset of an array, for instance), but now the type checker cannot verify that the generalized index function is valid, because some of the existentials are computed somewhere else. To Work around this, we've had to relax the KernelsMem type-checker a bit, specifically, we've introduced this function to verify whether two index functions are "close enough" that we can assume that they match. We use this instead of `ixfun1 == ixfun2` and hope that it's good enough.