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
