TODO.txt

API
===
- Change APIs to always use common PhEntryF and PhEntryDistF. -> PhTreeF + PhTreeMultiMapF
- Compile with Java 17 or 20!!! -> Faster!
- Remove (kNN).nextKey(), it doesn't help much and behavior is unclear, does it need to clone the returned key?!?!?
  -> consider removing kNN iterator.distance()  ... is that useful?

Impl
====
- Simplify minMask/maxMask calculation. -> see issue tracker
- Use min/max heap for kNN
- v13 NodeIteratorNoGC has WAY to many fields. Remove valTemplate, rangeMin, range<ax, dim, ...
- v13 Clean up mess with infixLEnStored vs infixLen
- Not optimal: all iterators locate the 'next' element before returning a current element (true?).
  This is inefficient because there a lot of iterators in a stack. Especially problematic when 
  returning nearest neighbor.
  -> Consider different type of iterator that does not extent Iterator<T>???? E>g. w/o hasNext() ?
- Not optimal: When reading NT-Nodes, the tree always applies valTemplate/hcPos etc to the result
  kdKey, even though the kdKey is already complete  
- The node iterators should know the global min/maxRange to efficiently check kdKeys without
  popping out of the local iterators and then popping in again if it is a mismatch.
  
- NodeIteratorFull: remove applying valTemplate from readingNt keys (for-loop in readValue).  
- NodeIteratorListReuse: niAllIterator: why check window here? Either check 'distance;  or do noch check at all...!!!
  
- Insert the following line into MaxKTreeI.getKdKey() and run TestRangeQuery.testNeighbour4_5of4
			System.out.println("READING: " + Arrays.toString(kdKey) + " / " + Arrays.toString(key) + " obj=" + System.identityHashCode(this));
  Then check whether it is efficient
  
 HD-Pure NT
 ----------
  - All of the above
  - Change NT-Nodes to contain only an array Entry-Elements (worse memory locality but much simpler
    to avoid GC (we don't need temporary elements anymore). This make it simpler to refactor
    iterators to only look for the next element when it is really required... -> Is this
    really an issue with 1NN? Isn't it efficient (usually required) to check all entries in a node?
    
  - Completely remove Node-Class? NtNode to have flag 'isRoot'...?
  - Or: Node to have complete Prefix? -> Avoid generating the prefix all the time (2*O(d)): 
    readHc + readInfix
    
  - applyHdPos() appears to be broken for DIM>=64. Test!