For formulae, used Markdown math mode
This commit is contained in:
parent
6d4c471ff6
commit
5c5c264241
1 changed files with 5 additions and 5 deletions
|
@ -17,13 +17,13 @@ implement a dictionary. Just a few are:
|
|||
* Many, many more ....
|
||||
|
||||
Each of these approaches has their own performance characteristics,
|
||||
memory footprints etc. For example, a table of size n with open
|
||||
addressing has no collisions and holds up to n elements, with a single
|
||||
comparison for successful lookup, and a table of size n with chaining
|
||||
and k keys has the minimum max(0, k-n) collisions and O(1 + k/n)
|
||||
memory footprints, etc. For example, a table of size $n$ with open
|
||||
addressing has no collisions and holds up to $n$ elements, with a single
|
||||
comparison for successful lookup, and a table of size $n$_ with chaining
|
||||
and $k$ keys has the minimum $\max(0, k-n)$ collisions and $\mathcal{O}(1 + k/n)$
|
||||
comparisons for lookup. While for skip lists the performance
|
||||
characteristics are about as good as that of randomly-built binary
|
||||
search trees - namely (O log n). So the choice of which to select
|
||||
search trees - namely ($\mathcal{O}(\log n)$). So the choice of which to select
|
||||
depends very much on memory available, insert/read characteristics,
|
||||
etc. So delegating the choice to a single point in your code is a very
|
||||
good idea. Unfortunately, in Erlang that's so easy to do at the moment.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue