-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Indexing with tuples as keys #15
Comments
Sorry for the delayed response - apparently I wasn't "watching" this github repository. Currently multi-dimensional indexing is reserved as we may wish to implement "multi dimensionsal dictionaries" in the future and the API for that hasn't been sorted out yet. It is a very important item on the TODO list but there are some more fundamental concerns with 1D containers to be ironed out first (for example, in #13 we are ensuring the iteration order of all dictionaries is stable and predictable, which will allow other things like sorting and permuting and so-on, and has implications on mapping and broadcasting, etc). I'm imagining something like the keys being some variant of |
some interesting use cases of multitimensional dictionaries:
I=Index([3 4;5 1; 3 1])
I=Index([Set(4,3,2),Set(5,1,2,6,7),Set(5,9)]) undirected Hypergraphs are generalization of undirected graphs: graphs have edges with exactly 2 nodes, hyperedges can have arbitrarily nodes of course other methods for the index could be contains, not contains, etc ... Dictionaries.jl is a very nice approach. Also with respect to genericity. In my opinion the way to go for the standard. Many thanks to the contributor(s)!! |
Yes, in a lot of ways a dictionary with 2-tuple keys is a much more natural way to think about a graph than a sparse matrix, since the keys values can be meaningful. Hopefully the token approach can make it just as fast yet easier to code. Still, the internal representation matters - being able to find I think there's a lot of interesting work to do with both Cartesian products of keys as well as subsets of such products (the "sparse" approach). |
With dictionaries, I'm used to being able to write stuff like this:
This isn't possible with this package:
Maybe this isn't possible or not what this package is designed to do, but I thought I'd bring it up.
The text was updated successfully, but these errors were encountered: