84 lines
		
	
	
		
			3.5 KiB
		
	
	
	
		
			Go
		
	
	
	
	
	
		
		
			
		
	
	
			84 lines
		
	
	
		
			3.5 KiB
		
	
	
	
		
			Go
		
	
	
	
	
	
| 
								 | 
							
								// Copyright 2017 The go-ethereum Authors
							 | 
						||
| 
								 | 
							
								// This file is part of the go-ethereum library.
							 | 
						||
| 
								 | 
							
								//
							 | 
						||
| 
								 | 
							
								// The go-ethereum library is free software: you can redistribute it and/or modify
							 | 
						||
| 
								 | 
							
								// it under the terms of the GNU Lesser General Public License as published by
							 | 
						||
| 
								 | 
							
								// the Free Software Foundation, either version 3 of the License, or
							 | 
						||
| 
								 | 
							
								// (at your option) any later version.
							 | 
						||
| 
								 | 
							
								//
							 | 
						||
| 
								 | 
							
								// The go-ethereum library is distributed in the hope that it will be useful,
							 | 
						||
| 
								 | 
							
								// but WITHOUT ANY WARRANTY; without even the implied warranty of
							 | 
						||
| 
								 | 
							
								// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
							 | 
						||
| 
								 | 
							
								// GNU Lesser General Public License for more details.
							 | 
						||
| 
								 | 
							
								//
							 | 
						||
| 
								 | 
							
								// You should have received a copy of the GNU Lesser General Public License
							 | 
						||
| 
								 | 
							
								// along with the go-ethereum library. If not, see <http://www.gnu.org/licenses/>.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								/*
							 | 
						||
| 
								 | 
							
								Package pot (proximity order tree) implements a container similar to a binary tree.
							 | 
						||
| 
								 | 
							
								The elements are generic Val interface types.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Each fork in the trie is itself a value. Values of the subtree contained under
							 | 
						||
| 
								 | 
							
								a node all share the same order when compared to other elements in the tree.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Example of proximity order is the length of the common prefix over bitvectors.
							 | 
						||
| 
								 | 
							
								(which is equivalent to the reverse rank of order of magnitude of the MSB first X
							 | 
						||
| 
								 | 
							
								OR distance over finite set of integers).
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Methods take a comparison operator (pof, proximity order function) to compare two
							 | 
						||
| 
								 | 
							
								value types. The default pof assumes Val to be or project to a byte slice using
							 | 
						||
| 
								 | 
							
								the reverse rank on the MSB first XOR logarithmic disctance.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								If the address space if limited, equality is defined as the maximum proximity order.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								The container offers applicative (funcional) style methods on PO trees:
							 | 
						||
| 
								 | 
							
								* adding/removing en element
							 | 
						||
| 
								 | 
							
								* swap (value based add/remove)
							 | 
						||
| 
								 | 
							
								* merging two PO trees (union)
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								as well as iterator accessors that respect proximity order
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								When synchronicity of membership if not 100% requirement (e.g. used as a database
							 | 
						||
| 
								 | 
							
								of network connections), applicative structures have the advantage that nodes
							 | 
						||
| 
								 | 
							
								are immutable therefore manipulation does not need locking allowing for
							 | 
						||
| 
								 | 
							
								concurrent retrievals.
							 | 
						||
| 
								 | 
							
								For the use case where the entire container is supposed to allow changes by
							 | 
						||
| 
								 | 
							
								concurrent routines,
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Pot
							 | 
						||
| 
								 | 
							
								* retrieval, insertion and deletion by key involves log(n) pointer lookups
							 | 
						||
| 
								 | 
							
								* for any item retrieval  (defined as common prefix on the binary key)
							 | 
						||
| 
								 | 
							
								* provide synchronous iterators respecting proximity ordering  wrt any item
							 | 
						||
| 
								 | 
							
								* provide asynchronous iterator (for parallel execution of operations) over n items
							 | 
						||
| 
								 | 
							
								* allows cheap iteration over ranges
							 | 
						||
| 
								 | 
							
								* asymmetric concurrent merge (union)
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Note:
							 | 
						||
| 
								 | 
							
								* as is, union only makes sense for set representations since which of two values
							 | 
						||
| 
								 | 
							
								with equal keys survives is random
							 | 
						||
| 
								 | 
							
								* intersection is not implemented
							 | 
						||
| 
								 | 
							
								* simple get accessor is not implemented (but derivable from EachNeighbour)
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Pinned value on the node implies no need to copy keys of the item type.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Note that
							 | 
						||
| 
								 | 
							
								* the same set of values allows for a large number of alternative
							 | 
						||
| 
								 | 
							
								POT representations.
							 | 
						||
| 
								 | 
							
								* values on the top are accessed faster than lower ones and the steps needed to
							 | 
						||
| 
								 | 
							
								retrieve items has a logarithmic distribution.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								As a consequence one can organise the tree so that items that need faster access
							 | 
						||
| 
								 | 
							
								are torwards the top. In particular for any subset where popularity has a power
							 | 
						||
| 
								 | 
							
								distriution that is independent of proximity order (content addressed storage of
							 | 
						||
| 
								 | 
							
								chunks), it is in principle possible to create a pot where the steps needed to
							 | 
						||
| 
								 | 
							
								access an item is inversely proportional to its popularity.
							 | 
						||
| 
								 | 
							
								Such organisation is not implemented as yet.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								TODO:
							 | 
						||
| 
								 | 
							
								* overwrite-style merge
							 | 
						||
| 
								 | 
							
								* intersection
							 | 
						||
| 
								 | 
							
								* access frequency based optimisations
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								*/
							 | 
						||
| 
								 | 
							
								package pot
							 |