[Rd] dict package: dictionary data structure for R
sfalcon at fhcrc.org
Mon Jul 23 19:29:43 CEST 2007
Duncan Temple Lang <duncan at wald.ucdavis.edu> writes:
> The HashFunc typedef in hashfuncs.h would be more flexible if it
> took an additional argument of type void * to allow for user
> defined data. Alternatively, it might take the hash table
> object itself. The function might want to do some
> updating of the table itself, or look at some table (e.g. for perfect
> hashing). And if we had a place to provide additional information, it
> is easy to allow the hash function object to be an R function.
Worth considering. I don't think perfect hashing is in scope here,
but would need to give it more thought -- seems to me that perfect
hashing would be better served by something separate.
> Also, you are using a "global" table of hash functions
> (i.e. Dict_HashFunctions) and looking up the C routine using
> which is tied to the integer indexing for this global table.
> Why not use the C routines directly from R, i.e. using
> getNativeSymbolInfo and pass this from R to the newly created
> dict. This avoids the lookup, the global table and makes things
> extensible with routines in packages and simply extends to allowing
> R functions to be passed instead of C routines.
> It also removes the need to synchronize the labeling system in
> R and in C, i.e. that 0L corresponds to PJW. The reliance on
> synchronized names rather than direct handles is unnecessary
> although widely used in S/R code.
Why not? Only because I didn't think of it ;-)
> I'm more than happy to give some code to illustrate what I mean
> more precisely if you'd like it.
Sure. At the same time, I'm a bit hesitant to invest further in dict
until I get a sense of whether or not it might actually be useful to
people. It's main use may turn out to be for investigating hash
functions behavior and for a test tool it may be sufficient as-is.
Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
More information about the R-devel