issue_comments

hmm... would np.nan work?

not sure about alignment, but at least obj.sizes would break with multiple dims: while it does not compare as equal, the hash() of np.nan stays constant (same with any other object, I guess).

This reminds me of the issue with nan shaped dimensions. Where again we want to avoid automatic alignment (well in that case you can't align).

For this particular issue could we define a xr.UNNAMED that doesn't equal itself (hmm... would np.nan work?). Would that skip alignment checks?

I agree, automatic dimension only ever really made sense for interactive usecases, where a user could see and fix the default names.

It's a little late to change the default now to raising an error instead, but maybe we could add a warning?

I'd probably use itertools.count() or the uuid module to generate globally unique dimension names... something like ```python class UnnamedDimensions: def __init__(self): self.dimension_names = (f"unnamed_dim{number}" for number in itertools.count())

def __call__(self, n):
    return list(itertools.islice(dimension_names, None, n))

unnamed_dimensions = _UnnamedDimensions() or using `uuid` (probably overkill):python def unnamed_dimensions(n): return [uuid.uuid4() for _ in range(n)] you'd use it like this:python d1 = xr.DataArray(data=[1, 2], dims=unnamed_dimensions(1)) d2 = xr.DataArray(data=[[1, 2]], dims=unnamed_dimensions(2)) ``` which would make "unnamed" a bit more explicit.

Edit: that's probably not so different from what you meant with d1_i

I know it is "stale" but aligning to these "surprise dimensions" creates "late stage" bugs that are hard to pinpoint.

I'm not sure if it is possible to mark these dimensions as "unnamed" and as such, they should be "merged" into new "unnamed" dimensions that the user isn't tracking at this point in time.

Our workaround have included calling these dimensions something related to the datarray d1_i, or simply making small small "arrays" a countable number of scalar variables (d1_min, d1_max) instead of a single array containing two values d1_limits.

```python import xarray as xr d1 = xr.DataArray(data=[1, 2]) assert 'dim_0' in d1.dims d2 = xr.DataArray(data=[1, 2, 3]) assert 'dim_0' in d2.dims

xr.Dataset({'d1': d1, 'd2': d2}) ```

cc: @claydugo

In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity

If this issue remains relevant, please comment here or remove the stale label; otherwise it will be marked as closed automatically

In the specific example from your notebook, where do the dimensions lengths __variants/BaseCounts_dim1, __variants/MLEAC_dim1 and __variants/MLEAF_dim1 come from?

BaseCounts_dim1 is length 4, so maybe that corresponds to DNA bases ATGC?

In this specific example, I do actually know where these dimension lengths come from. In fact I should've used the shared dimension alt_alleles instead of __variants/MLEAC_dim1 and __variants/MLEAF_dim1. And yes BaseCounts_dim1 does correspond to DNA bases.

But two points.

First, I don't care about these dimensions. The only dimensions I care about and will use are variants, samples and ploidy.

Second, more important, this kind of data can come from a number of different sources, each of which includes a different set of arrays with different names and semantics. While there are some common arrays and naming conventions where I can guess what the dimensions mean, in general I can't know all of those up front and bake them in as special cases.

In the specific example from your notebook, where do the dimensions lengths __variants/BaseCounts_dim1, __variants/MLEAC_dim1 and __variants/MLEAF_dim1 come from?

BaseCounts_dim1 is length 4, so maybe that corresponds to DNA bases ATGC?

Thanks @shoyer.

For reference, I'm exploring putting some genome variation data into xarray, here's an initial experiment and discussion here.

In general I will have some arrays where I won't know what some of the dimensions mean, and so cannot give them a meaningful name.

No worries if this is hard, was just wondering if it was supported already.

The main problem is that unnamed dimensions (in NumPy, at least) have different semantics than named dimensions, particular for how dimensions are matched up in broadcasting. For that reason, we really want all dimensions to always be named.

We could possibly add support for unnamed dimensions in the Dataset constructor, but on the other hand it also provides a gentle nudge to chose names.

Thanks so much @rabernat for quick response.

Is there a way to create arrays and datasets with unnamed dimensions?

No. Xarray's data model requires all dimensions to have a name.

Xarray allows you to create DataArrays without specifying dimensions:

python import xarray as xr import numpy as np da = xr.DataArray(np.zeros((4, 5)))

Xarray will choose dimension names in this case (dim_0, dim_1, etc.)

This doesn't work with creating Datasets, because you have to specify all variables' dimensions in the Dataset constructor.

I imagine that unnamed dimensions would break lots of internal Xarray logic.