On Monday, November 10, 2014 10:07:46 PM UTC+1, Milan Bouchet-Valat wrote:
>
> Le lundi 10 novembre 2014 à 10:07 -0800, David van Leeuwen a écrit :
> > Hello,
> >
> > On Monday, November 10, 2014 11:01:59 AM UTC+1, Milan Bouchet-Valat
> wrote:
> > Le dimanche 09 novembre 2014 à 23:48 -0800, David van Leeuwen a
> écrit :
> > > Hello,
> > >
> > > On Monday, November 10, 2014 1:43:57 AM UTC+1, Dahua Lin
> wrote:
> > > NamedArrays.jl generally goes along this way. However,
> it
> > > remains limited in two aspects:
> > >
> > >
> > > 1. Some fields in NamedArrays are not declared of
> specific
> > > types. In particular, the field `dicts` is of the type
> > > `Vector{Dict}`, and the use of this field is on the
> critical
> > > path when looping over the table, e.g. when counting.
> This
> > > would potentially lead to substantial impact on
> performance. >
> > >
> > > I suppose the problem you indicate can be alleviated by making
> > > NamedArray parameterized by the type of the key in the dict as
> well.
> > Right. Sounds reasonable.
> >
> >
> >
> > I've been pondering over how this could be done. NamedArray has a type
> > parameter N, and it should then further have N type parameters
> > indicating the dictionary type along each of the N dimension. So I
> > figure this is going to be a challenging type definition.
> A tuple type could be used to give the type of the dimension names.
>
> But there's another issue: `dicts::Vector{Dict}` cannot be defined more
> precisely than that if heterogeneous types are allowed for different
>
This is exactly what I was referring to. Not all dimensions will have the
same type, so the number of types that are parameterizing NamedArrays
depends on N, yet another parameter of the type. I am not sure how to
define a variable number of parameters for a type. Maybe something
recursive will do.
> dimensions. Is this a case where staged functions could be used to
> generate efficient functions to access dictionaries?
>
>
> Regards
>
