Sure, agreed.
On Fri, Mar 6, 2015 at 3:44 AM, Antony Polukhin
2015-03-05 20:48 GMT+03:00 Cosmin Boaca
: On 5 March 2015 at 19:15, Kenneth Adam Miller < kennethadammiller@gmail.com
wrote:
Ok, where is the repo?
Cosmin: Are you open to the idea of having the trie act as a container and sort of adopt a superset of the operations that work on traditional STL containers?
Are you open to the idea of having the trie be parameterizable with concurrency strategies? With value strategies that can even be an additional data structures?
I am not quite experienced in concurrent data structures. Honestly I have never thought of that but I am open to any discussion about implementation strategies. Maybe Anthony could help us taking design decisions and some plan of implementation.
Well, usually you make a data structure concurrent after you've polished the implementation, removed the unnecessary fields, tuned structure for size. Big problem with concurrent data structures - is that generic solution would probably be much slower than a problem-tuned solution.
Making a concurrent trie is discussable, but in any case tuning the current implementation must be done first.
I'm interested in each of these. And I have ideas about how to move forward
implementing them. I'd also like to work on applying what we make toward several already open libraries, by writing some bindings to python and some other languages. I'm interested in writing some protobuf/capnproto specifications and some data-type translations between the vernacular too.
I am not familiar with protobuf / canproto.
Trie's API is not stable yet, so do not rush with that task.
-- Best regards, Antony Polukhin
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost