With the danger that this thread becomes slightly off-topic, I would just
want to add that I believe that most of the issues raised w.r.t.
NamedArrays are addressed in NamedArrays v0.4.0, which is now in METATDATA.
Specifically,
- the type is now parameterized by its member variable types for Array and
Dict
- which can be any AbstractArray and Associative
- keys to the index names can be of any type, although some types (e.g.,
arrays) will probably lead to trouble. But integers, rationals or floats
can be used without too much semantic ambiguity.
As a bonus, I changed the license to a more Julia-friendly one.
Cheers,
---david
On Thursday, December 4, 2014 1:24:03 AM UTC+1, David van Leeuwen wrote:
>
> Hello Milan,
>
> I just uploaded a new version of NamedArrays to github. I've
> reimplemented the getindex() mess---the never ending chain of ambiguities
> was unworkable. It is much cleaner now, I believe, and I've replaced the
> `negative index' implementation with a simple `Not()` type for performance
> reasons. So now you can say
>
> n[Not(1),:]
>
> to remove the first row, or equivalently use
>
> n[Not("one"),:]
>
> if you happened to have indexed with strings. You should be able to use
> an associative index now with all kinds of types, e.g., rationals or
> perhaps even integers---I haven't tested that yet.
>
> The standard travis test includes a simple getindex performance benchmark,
> indexing with integers is slightly slower than for normal arrays, but
> indeed quite a bit slower for names.
>
> On Sunday, November 30, 2014 11:22:39 AM UTC+1, Milan Bouchet-Valat wrote:
>>
>> Le mercredi 26 novembre 2014 à 09:30 -0800, David van Leeuwen a écrit :
>> > Hello again,
>> >
>> >
>>
>> The idea is that any type could be used instead of a Dict, as long as it
>> can be indexed with a key and return the index. For small NamedArrays,
>> doing a linear search on an array is faster than using a Dict. And when
>> computing frequency tables from PooledDataArrays, we could reuse the
>> existing pool instead of creating a Dict from it, it would save some
>> memory.
>>
>>
>> Also, John suggested that the array that a NamedArray wraps could be of
>> any AbstractArray type, not just Array. Sounds like a good idea (e.g. to
>> wrap a sparse matrix).
>>
>> I tried replacing Array by AbstractArray and Dict by Associative in the
> type definition, and all works fine, except that plain indexing becomes
> very slow again. So I left that out for now. The array and associative
> types themselves should probably become part of the type parameter list.
>
> ---david
>
>
>
