I’m assuming that’s short for coordinates?
Yes, I think they call these values coordinates, and use “coords” in function/property names.
I think there’s been a misunderstanding here. We already have agreed to dimnames for that use case. What this discussion is referring to has a label for each value along an axis. It’s often not a symbol or string.
1 Like
Ohhh, sorry for the noise.
Coordinates conflicts with its use in the geometry ecosystem.
FWIW, I voted for axiskeys, and I still prefer it over axislabels. As someone above said, it can be argued that it’s Base.keys that should have been Base.indices, with keys being more appropriate for the more generic use here. Regardless of that, even as things stand currently, I see the similarity with keys as a feature of axiskeys, not a bug.
axislabels is a sort of vague and generic name that one could get used to - the positive side of that is that it isn’t misleading like axisvalues or axisnames. But the negative is that, by itself, it doesn’t invoke an image of what it is.
axiskeys is much closer to being self-documenting in that regard.
1 Like
I understand where you’re coming from but I think we need to accept that there were logical reasons keys ended up being defined in base the way it is (even if we don’t find that logic particularly compelling) and we need to accept that it isn’t going to change anytime soon. I think the the issue with axiskeys isn’t really that it’s a bug. It just sounds like it means keys(axes(data, dim)). It’s also arguable that what we are discussing isn’t considered “keys” in the fullest sense of the term.
Depending on where you stand both “labels” and “keys” are ambiguous terms for this application. The question really is which of these will be the most comfortable to use by everyone for the foreseeable future.
1 Like
I think the the issue with
axiskeysisn’t really that it’s a bug.
Just to be clear, I didn’t mean “bug” in a literal sense there. I was using the “it’s a feature, not a bug” idiom/meme to say that axiskeys sounding similar to keys is a positive, not a negative.
It’s a good thing in design when we can re-use existing mental models, and Julia programmers have a mental model about keys - something that’s on the index side of a collection rather than on the value side (whether that’s hashable keys on a Dict or symbols in a NamedTuple).
So, I think it’s more likely that the name axiskeys helps people understand it more easily, based on that conceptual idea of what keys are. The positives of reusing that mental model are significant, and overweigh the chances that someone takes a more literal interpretation like keys(axes(data, dim)).
All that said, I don’t strongly dislike axislabels as the term for this. It would be my second choice among the discussed options. But axiskeys seems clearer and crisper (as in less vague) to me.
For the most part I agree with this and have mostly just been trying to give a fair voice to all sides of the discussion.
The one compelling reason I personally have for avoiding “keys” is that the entire dictionary interface isn’t fully developed in Julia. There may be future requirements for that interface relating to keys and we might end up building a set of methods that are somewhat ill fit for this hypothetical dictionary interface.
1 Like
What exactly is the conflict? Yes, the “coordinates” term is used in geometry as well — but to me, it seems the same kind of “conflict” as “labels” are with plot and table labels. That is, not really confusing at all.
And compared to labels, coordinates have the benefit of being more general, in my opinion.
Curious if there’s anything to read on this. There are alternative dict implementations/interfaces such as GitHub - andyferris/Dictionaries.jl: An alternative interface for dictionaries in Julia, for improved productivity and performance, but they all seem to share the same concept of keys. What kind of conflict do you foresee? And what’s the relation between dicts and “axis arrays”?
Coordinates is more problematic because an array can have a coordinate system that isn’t this axis lookup/label we are after. It is also more confusing if we have an array of coordinates with coordinates. Yeah we know what it means because of the context and functional definition we’ve created, but I think it loses all intuitive meaning at that point.
I’m not aware of any effort to standardize the dictionary interface to the extent that Dictionaries.jl has. As far as conflicts, even conforming to Dictionaries.jl would be problematic because the keys would need to subtype Dictionaries.AbstractIndices. Even using a similar approach would be problematic because the Dictionary.jl approach to keys requires that key(dict)[key] == key, which is not how a lot of people want this particular feature to work.
I still don’t get how the Dict/Dictionary interface is related to this discussion of arrays…
The argument for keys is that it’s self documenting because we use the term keys in Julia as the look up associated with a value. Keys are really defined as part of the dictionary interface though and as it becomes more well defined keys can take on a stricter meaning in Julia. As that interface matures our intent to self document this feature as returning a set of keys may be misleading. People may wonder why the indexing operation on keys isn’t reflective like we see in Dictionaries.jl or returns a hash look up into the buffer of values.
The point is that if the interface for dictionaries develops anymore (which we probably all want) then keys will take on additional meaning that we aren’t prepared to commit to for this new syntax we’re discussing. When that happens some people will be returning something that isn’t really what Julia defines as “keys” anymore.
Ah, now I see why you mentioned dicts at all.
As this thread is about arrays, I only thought of regular array keys: Julia uses keys and indices as basically synonyms. Then something like axiskeys can be read as a generalization of array keys/indices, which it actually is.
Not sure if dict-related considerations should be taken into account here. The Julia array interface is very stable and is (I hope) unlikely to change, should only be extended when needed. And keys are an integral part of this interface, so their meaning will stay in the array context.
But isn’t it effectively the same with “labels”? You can have an array of labels for plotting/drawing/printing/whatever.
It should only be taken into account because it effects the entire motivation for using the term “keys” as self documenting what it returns.
The most commonly used parts of the array interface are stable but there are aspects that are ill defined or need some light reworking.
No because the axis labels of labels are both conceptually the same. If you get the axis coordinates of coordinates then you are ascribing two completely different meanings of coordinates. One is this label/key like thing and the other may be referring to real world space.
So my issue with keys is that it’s ambiguous whether it will continue to be as clear of a self documenting syntax. My issue with coordinates is that at its best it is interpreted as the computational index positions when it’s already used to refer to real world coordinate systems. The meaning of a label for the x axis and labels along the x axis aren’t semantically different or very confusing. Its slightly less specific than what some people have in mind than keys but that is good to some and bad to others.
@aplavin did I address your concerns here
Now for something completely different.
From an ontological perspective, what you are specifying for an axis is its domain — the valid set that can be used for that axis.
How we describe those items in the set is typically different based on the context — they could be described as values, labels, levels, ids, types, etc.
So how about axisdomain() ?
This naming could also let you throw a descriptive error like “index is not in axis domain.”
Wouldn’t the axis be the domain (possibly the dimension name) and what we are discussing would be the contents within a domain along the axis?