RFC: NamedIndex and NamedVector types

[HarlanH]

These are relatively simple data types that are useful for data structures that are worked with in the REPL. NamedIndex is a mapping from either names (strings) or integer indexes to integer indexes. NamedVector wraps that in a type that also includes an arbitrary vector. These structures also include grouped names, which refer to groups of other names, and can be used transparently. The majority of this code is by Tom Short @tshort. NamedIndex is used by JuliaData.

NamedVector is missing most functionality but the basics, but thought I'd get comments before writing that code.

Simple example of NamedVector (see also the test suite):

julia> nams = ["one", "two", "three", "four"]
4-element ASCIIString Array:
 "one"  
 "two"  
 "three"
 "four" 

julia> vals = [11, 22, 33, 44]
4-element Int64 Array:
 11
 22
 33
 44

julia> t1 = NamedVector() # need constructors other than the default empty constructor!


julia> for i = 1:4
           t1[nams[i]] = vals[i]
       end

julia> print(t1)
1, one: 11
2, two: 22
3, three: 33
4, four: 44

julia> t1["one"]
11

julia> t1[2]
22

julia> t1[1:3]
3-element Any Array:
 11
 22
 33

julia> t1[["four", "two"]]
2-element Any Array:
 44
 22

[StefanKarpinski]

Love it.

[StefanKarpinski]

I'm completely down to merge this, but I'm holding off because of the RFC subject line. Whenever you're good to go, Harlan, this is in. I've always wanted this kind of thing. Very handy.

[toivoh]

Where does the mapping from name to index come from? Insertion order?

[HarlanH]

@toivoh , yes, mostly. Typical use cases are setting all the names at once, replacing a name, or appending a new index. For the applications we've used this for (DataFrame and a project I'm doing for work), inserting in the middle hasn't come up.

[timholy]

Looks nice. I presume the main extra functionality this adds over Dict is the ability to access elements either by index or name?

Very minor suggestion: you can avoid two Dict lookups, the first for checking to see if it has a name and the second to find the index associated with it, using code like this (cribbed from the options code):

index = Base.ht_keyindex(o.key2index,s)
    if index > 0
...

[HarlanH]

@timholy Yes, that's right. It has fast access by name (via a Dict) and even faster access by index. It just passes integers (and Ranges, and Boolean vectors...) through to the usual array referencing code. Thanks for the reminder on ht_keyindex()! I'll take a look and see where that can be used.

[HarlanH]

Jeff/Tom, I pushed some changes here that pull the implementation of groups out into a separate Dict, as suggested. Seems to work fine. I want to do one more thing on this before it could be merged in, which is make groups work for NamedVectors.

[StefanKarpinski]

This is why we definitely need multiple inheritance. Huge language change though.

[JeffBezanson]

I don't think something can be both a Vector and Associative, the way we've defined them so far. A vector implicitly has consecutive integers as keys, and an Associative has arbitrary keys. Iterating an Associative yields (key,value) tuples, and a vector just gives values.

[HarlanH]

Yes, that's right. My intention for this data type (or, really, Tom's
intention), is a vector that has subsidiary and less-efficient associative
elements for (mostly) interactive use. Iterating should give values, not
tuples.

I've been slammed and haven't been able to work on this stuff recently.
Hopefully soon!

On Wed, Sep 12, 2012 at 3:13 PM, Jeff Bezanson [email protected]:

I don't think something can be both a Vector and Associative, the way
we've defined them so far. A vector implicitly has consecutive integers as
keys, and an Associative has arbitrary keys. Iterating an Associative
yields (key,value) tuples, and a vector just gives values.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1190#issuecomment-8506417.

[tshort]

It can still inherit from an AbstractVector and have iteration defined like an Associative type. I'm not sure whether Vector or Associative iteration is best in this case. The main reason for inheriting from an AbstractVector is so that sum(nv) works and nv1 .* nv2 works. I'd probably lean towards vector-style iteration in this case to make such operations more likely to work without defining a custom method.

One option to make these two types of iterations more compatible is to switch the (k,v) order around to (v,k) on Associative iteration. Then, if you leave off the key, you still get the value, and it would be like vector indexing.

[HarlanH]

OK, could use some more feedback. See the comments on the most recent commit. Added groups for NamedVector, changed NamedVector to inherit from AbstractVector, and added more tests.

[HarlanH]

Will make this a package instead. Closing pull request.