Wishlist - various plans & ideas - what do users want?

[tzaeschke]

At anyone reading this: please feel free to put suggestions & endorsements into comments below

Here are some assorted ideas / plans for the future:

API:

• [ ] Think about providing find_navigable() / erase_navigable() that return truly iterable iterators. Probably not goping to happen, we have lower_bound() now.
• [ ] Add performance_hints() that checks for various performance issues (and returns a list of <string, bool> checks. E.g.
  • [ ] Is the value trivially copyable or movable? (TBC)
  • [ ] Is the value "small" in size? -> Use pointer instead
  • [ ] Suggest using std::vector for high-dim keys (TBC)
• [ ] self_join() function?
• [ ] Check R-Tree (std std::...) direct access to nodes. What do people use it for? Should we provide it?
• [ ] Similar to previous: Support custom data (and possibly functions) in nodes. Examples for functions + data would be to store aggregate information (total child count, total area of boxes, some kind of aggregate running on the values associated with keys...).

Internally:

• [ ] Make std::vector the default key for high dimensions (verify the idea first). On hold: No benefit for DIM < 30 and only marginal (i.e. only for insertion but not query/kNN) above 30.
• [ ] Make Entry & Node trivially copyable

Documentation:

• [ ] Document prominently that PhPoint/Box are only "default" keys
• [ ] Document more prominently that find/erase do not return real iterators
• [ ] Provide example + documentation for multi-map

[iegorval]

Hello. If you are accepting proposals, I would vote for more examples and documentation. I fail completely to understand how multi-map works, for example. If there is some way to have maximum allowed number of values for specific keys and so on.

[tzaeschke]

@iegorval Thanks. Indeed, the example.cc is quite outdated and doesn't cover mutli-map. Unfortunately, I am quite busy at the moment, so I am not sure when I get around to do that.

Maybe

For example, the default version of PhMultiMapD<DIM, T> uses internally something similar to a std::set<T> to store multiple entries per coordinate. This default version does not have a maximum number of entries per coordinate. I see two ways for limiting the number of entries:

1) Before inserting an entry, you can call find(key) or count(key) to find out how many elements are already at a given coordinate. 2) You can use your own implementation of set that has an upper limit for the number of entries and use this with PhTreeMultiMap, see here how the default is declared. 3) You can use a normal PhTree<DIM, std::vector> and manage the maximum entry count yourself.

If you have more questions, maybe you can open a separate issue or you can ask questions on Discord. I hope that helps?