Should Julia choose either of the terms indices
or indexes
as preferred when talking about arrays? From a usability point of view, it is probably desirable to choose one of the terms and stick with it, especially when it comes to name publicly visible functions in the base language or commonly used packages.
Currently, looking for either term finds about the same number of occurrences (in both local variables, argument names, and documentation combined). Some other languages (e.g. Fortran, Python) prefer indices
, database systems seem to prefer indexes
. Google tells me that common language prefers "indexes" while math and computer science prefer "indices".
I'm terribly guilty of using both semi-interchangeably. I think I have some sort of rule in my head, where indices are abstract and indexes are a concrete collection with more than one index, but it drives me batty looking back and seeing a mix. +1 to standardizing on just one or the other.
$ ack indexes base | wc -l
99
$ ack indices base | wc -l
75
We should stick with "indexes".
Base
API consistently uses "indexes", even if the internal variables, comments and docs don't always. Consider the functions localindexes
and parentindexes
for example.In current use the plural is indices in senses 8, 9, and usually in other senses except 5, in which indexes is usual.
Senses 8 and 9 refer to usage in mathematics and the sciences; 5 is the bibliographic sense (book indexes).
+1 for indices
I'm surprised it's weighted so heavily towards indices in registered packages:
$ ack indexes --type=julia ALL_PACKAGES | wc -l
324
$ ack indices --type=julia ALL_PACKAGES | wc -l
1339
I'd favor indexes
. I think I tend to use indices only in prose.
Given that indices is more the norm for math/sciences/technical meaning, and that crowd has a very high representation among Julians, I'm not surprised by that result in the registered packages (also due to the very international following that Julia has, I suppose).
Also, some people make a distinction between database indexes, and array indices. Kind of crazy, but it happens.
Being a non-English speaker by nature indexes is significantly easier for me to notice without a single though that it's about indexing, than indices which requires slight amount of brain work to realize what it's about.
Down with irregular plurals!
Flip a coin, and decide. I'll be happy to help change things either direction.
+1 for indices. It is a bit easier to pronounce.
In Portuguese ans Spanish (I think) it's indices, so that one is naturally easier for us.
+1 for array indices as well. Fortran, Matlab, Python, R all seem to use "indices".
Note that simple searches do not give clear results, as "indexes" has a second meaning that shouldn't be counted: "the variable i
indexes into the array", i.e. third person singular of the verb "to index".
In matters Julia, I am greatly reluctant to advocate other than @JeffBezanson's sense of appropriateness.
__with great reluctance__
(This plural of index quandry is something I have examined deeply, so _fwiw_)
When I have more than one index, say an index of people and an index of topics then I have two indexes; when I have more than one item gathered in a well-ordered, addressable collective then I have some indices.
@J-Sarnoff's definition makes the most sense to me.
(Definitions)
In Sweden we have it nice. Singular and plural of index is the same, it's just "index".
+0.1 for indices, (0.1 since I believe my Swedish vote is of little importance).
+1 for indices
+1 for indices
+1 for indices (I always cringe when I see "indexes")
Make no mistake, my preference for "indexes" is pure linguistic activism; I don't claim it's more correct according to current standards, but that it _should_ be.
We can skirt the issue in some cases, particularly for local variables — ind/inds
or idx/idxs
work nicely and are both commonly used. But unfortunately they don't make for nice conjugate word APIs: the abbreviations make it harder for me to read localinds
and parentidxs
without adding an underscore.
I imagine that the slight preference for "indexes" in Base (98 to 75 by my count) is due to the influence of a certain linguistic activist (and gets multiplied because most occurrences are due to functions having indexes
in the name, which is then repeated multiple times in documentation), and the much larger preference of "indices" over "indexes" among registered packages is due both to the math/scientific/technical background of most Julians, and large number of people outside the US/Canada .
It seems there is a majority for indices
.
This leads to the next question: Should the functions in Base
that have currently indexes
in their name receive counterparts with indices
? And should the indexes
versions be deprecated?
+1 for indices
Any decision yet? Once a decision is made, at least all the error messages and documentation can be updated in a PR (changes to function names will need separate PRs and deprecations, IMO).
indices
Case Singular Plural
nominative index indicēs
genitive indicis indicum
dative indicī indicibus
accusative indicem indicēs
ablative indice indicibus
vocative index indicēs
+1 for indices
My matrices have indices. Do your matrixes have indexes?
Two not irrelevant historical facts from my recent research:
Now that DistributedArrays
have been extricated from Base
, the only remaining function clinging on to the regular plural is parentindexes
.
Oh, and now there is a method with a keyword argument using indices
:
Base.SparseArrays.sortSparseMatrixCSC!(A, sortindices = :sortcols)
so whatever we decide on is guaranteed to break some API.
In my mind, "indices" is what a matrix or vector has, while a "indexes" is what a database table has if there's more than one index. Perhaps this is a made up distinction.
@StefanKarpinski It is "a distinction with a difference."
This issue now appears to be blocking :smile: for #16260.
In my mind, "indices" is what a matrix or vector has, while a "indexes" is what a database table has if there's more than one index. Perhaps this is a made up distinction.
👍 to this interpretation
There seems to be more consensus behind indices
, so I went with that in #16260.
Interestingly, we're talking about indices and indexes in base quite a bit more than we were when this issue was opened… but we added them in almost exactly equal number:
134 indexes (up 35 from 99)
109 indices (up 34 from 75)
In #16251 I get rid of a whole slew of indexes, just barely bringing indices into the lead (97 - 102). The remaining major uses of indexes are: parentindexes
, localindexes
, to_indexes
, and SubArray's indexes
field. The most annoying cases are those like to_indexes
, where there's also a singular name in the code base that it refers to.
It's rather remarkable how much more we're talking about indices
a little over a year later:
$ ack indexes base | wc -l
82
$ ack indices base | wc -l
607
I think the only things left to do are update a few docstrings and deprecate (and maybe rename) parentindexes
and localindexes
. I'd be inclined to leave subarray's indexes
field as it is; it's internal.
What advantage obtains by getting this consistent vocabulary almost consistent within Julia?
An internal field name that has yet to be brought into the fold should be at task front:
for work as important as is Julia, the inside is as guardian of best practice for the outside.
Let's go ahead and change all of them, including the field name.
Most helpful comment
Let's go ahead and change all of them, including the field name.