-
Notifications
You must be signed in to change notification settings - Fork 133
Provide "rightmost key at most" and "leftmost key at least" queries (feature request) #37
Comments
There is import pygtrie
trie = pygtrie.CharTrie({'ra': 1, 'rabar': 2, 'rabarbar': 3})
assert 'ra' == trie.longest_prefix('ra').key
assert 'ra' == trie.longest_prefix('rab').key
assert 'rabar' == trie.longest_prefix('rabar').key
assert 'ra' == next(iter(trie.keys(prefix='ra')), None)
assert 'rabar' == next(iter(trie.keys(prefix='rab')), None)
assert 'rabar' == next(iter(trie.keys(prefix='rabar')), None) Though to guarantee ordering for the latter you’d need to enable sorting in the trie. |
So that’s
That wouldn’t quite work the way you’ve showed then. Without sorting there’s no reason that I’m not convinced this make sense for a trie though. Typical solution when moving to previous or next key is required is to use a binary search tree. Trie addresses different needs. Is there a practical case you need those operations for? |
Sorry, I misspoke a bit. Lower bound is the smallest key that is greater or equal given key. Upper bound is smallest key that is greater than the given key. So operations you’re describing are ‘predecessor of lower bound’ and ‘lower bound’. Can’t you just rely on |
Oh, okay, thanks for the clarification about the names! What do you mean about relying on
Then of course I get a (Just an aside: the more I think about my own problem, the more I think I do want to use the parity approach. So perhaps I’ll end up making my own “parity-encoding trie” structure. However, implementing this bst-like search behavior could still be useful for someone else.) |
Given a Trie, I'd like to be able to search for a key
k
, and get either k or the closest thing on either side ofk
.More precisely, the query would yield one of these:
k
and its value, ifk
is in the trie,k
if one exists, ork
.(When I say "lexicographical" I'm talking about the ordering given by the structure of the trie.)
Currently I can see how to implement it by iteratively calling
has_node
, or iteratively callingiterkeys
(oriteritems
), building up a larger and larger prefix and maybe handling KeyError exceptions to decide when to go forward. Or it could be implemented naively by traversing over all keys linearly (but that wouldn’t take advantage of the convenient structure of a trie). Finally, I’m half-sure it could be implemented by usingtraverse
, but it’s not obvious how. Thetraverse
function seems to work likefoldr
on the path to a key—which should be enough, as long as you also implement a "rightmost child" or "leftmost child" query.All of these options (except the naive one) involve non-trivial work that deals with the structure of the tree, so I think these queries should be handled internally by the class.
The text was updated successfully, but these errors were encountered: