I don't think having both dimension names and permutation is
redundant...dimension names can also serve as human-readable tags that help
a human interpret the values. If reading a NetCDF, for example, one might
store the dimension variable names. When determining type equality it may
be useful that {..., permutation = [2, 0, 1], dim_names = ["C", "H", "W"]}
is not equal to {..., permutation = [2, 0, 1], dim_names = ["x", "y", "z"]}.On Wed, Feb 22, 2023 at 4:56 AM Rok Mihevc <rok.mih...@gmail.com> wrote: > > > > > > > > > > Should we rule that `dim_names` and `permutation` are mutually > > exclusive? > > > > > > > > > > Since `dim_names` have to "map to the physical layout (row-major)" that > > > means permutation will always be trivial which indeed makes it > > unnecessary > > > to store both. > > > > I don't think it is necessarily needed to explicitly make them > > mutually exclusive. I don't know how useful this would in practice, > > but you certainly *can* specify both in a meaningful way. Re-using the > > example of NHWC data, which is physically stored as NCHW, you can keep > > track of this by specifying a permutation of [2, 0, 1], but at the > > same time you could also still save the dimension names as ["C", "H", > > "W"]. > > > > I'll advocate for the original comment, but I'm ok either way. Having both > `dim_names` and `permutation` is redundant - if the user knows their > desired order of `dim_names` they can derive the permutation. If they don't > use `dim_names` they probably don't want them. >
