>
> I think you can solve the holes on delete by permuting the removed element
> with the last element and keeping a map from value to their index.
>
Good idea!
Thanks you very much for these suggestions.
>
You're welcome. The hashtrie is a much better idea for this situation, of
course.
Couldn't you just slightly extend Rich's PersistentHashMap? (Maybe I'm
misunderstanding what you're looking for or what PersistentHashMap is all
about.)
Just brainstorming now:
If you did extend Rich's, it would be pretty cool to build a generalized
version of Clojure's hash-map construction function ("hash-map-searchable"
or something) that took two extra arguments: a function called by a leaf
node on its value and a function called by a non-leaf node on a coll of its
subnodes. On every update, every node in the update path would call one of
these functions and store the result in the node.
(If your objects are maps with key :mass, then the first function would be
:mass, and the second function would be #(reduce + %).)
Then one could build a general function "search-map" taking a hash-map and a
search function. The search function would accept a coll of stored node
values (the values of a node's subnodes) and return the index of the subnode
to follow down the tree. The search function would be called on the root
node on down, following the returned index each time, until it hit a leaf
node, which it would return. You could implement your case really easily in
this framework, I think, and it might also make it easy to build other kinds
of more complicated search down the branches of a hash-map hashtrie.
Garth
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
