You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 27, 2023. It is now read-only.
Note: this is a backwards-incompatible change in the interface, but shouldn't change the commitment so long as the library is used the same way.
Currently (as of #37), values are stored in a map hash(key) -> value. This allows constant-time reads. However, an outstanding change is using the raw key instead of the hash of the key: #14 (comment)
This is needed to allow applications to store certain entries at specific keys in the tree, which also allows for algorithms that operate over subtrees (see above-linked comment for more context). Users who do not want to use this functionality can simply hash their keys before passing them to the library, resulting in an identical tree as before the change proposed here.
Note: this is a backwards-incompatible change in the interface, but shouldn't change the commitment so long as the library is used the same way.
Currently (as of #37), values are stored in a map
hash(key) -> value. This allows constant-time reads. However, an outstanding change is using the raw key instead of the hash of the key: #14 (comment)This is needed to allow applications to store certain entries at specific keys in the tree, which also allows for algorithms that operate over subtrees (see above-linked comment for more context). Users who do not want to use this functionality can simply hash their keys before passing them to the library, resulting in an identical tree as before the change proposed here.