Conversation
This commit adds a new crate to the qiskit crate collection for defining the BackendV3 interface in Qiskit. The backendv3 interface will be a Rust first construct that will expose a shared interface to both Python and C, while the current BackendV2 interface is only exposed to Python. As a first step to facilitate it's development this commit adds a new empty crate where we'll slowly build up the functionality of that interface. Right now it's just empty but in subsequent commits we'll add onto it.
This commit adds a new data structure to the new providers crate DataTree. The DataTree is a generic tree structure that will be used to define the operation ports in the QuantumProgram's tensor compute graph's nodes. Right now this is just one of the building blocks towards defining the QuantumProgram. As it isn't being used right now since the rest of the components don't exist yet, this is solely self tested. When subsequent components are added tests using the DataTree as part of Operation types and eventually in a QuantumProgram will be needed as well.
mtreinish
added
on hold
|
One or more of the following people are relevant to this code:
|
|
I think we could do with a public textual overview of what all these data structures are, and are going to be. It's pretty hard to comment on / review any PR that adds core data structures without any use of them. |
|
This is still a draft. There will be an issue with epics outlining the high level structure of what we're building for the tensor compute graph |
| /// let result = tree.get_by_str_key("x.y").unwrap().as_leaf_ref(); | ||
| /// assert_eq!(*result.unwrap(), 10); | ||
| /// ``` | ||
| pub fn get_by_str_key(&self, key: &str) -> Option<&TreeEntry<'_, T>> { |
There was a problem hiding this comment.
This method looks like a useful component of an end-user API for accessing deep leafs. However, it only works if every node in the path can be accessed by a string key. I wonder if we can consider replacing this method with one that works in terms of a new struct TreePath that handles indexing by both string and integer?
I suggest "replace" because the string-splitting seems very useful, but it also seems very user-focused, so that I wonder whether it should be delegated to the bindings rather than the core object. Let me know if I'm thinking about this wrong.
There was a problem hiding this comment.
Yeah that's fair. I was thinking too mechanically about what the prototype was doing a path struct that can handle either index or string key based access is a more natural pattern for the rust data structure and should be good building block for the Python API and C APIs we'll build on top of this.
4 participants
Summary
This commit adds a new data structure to the new providers crate
DataTree. The DataTree is a generic tree structure that will be used to
define the operation ports in the QuantumProgram's tensor compute
graph's nodes. Right now this is just one of the building blocks towards
defining the QuantumProgram. As it isn't being used right now since the
rest of the components don't exist yet, this is solely self tested. When
subsequent components are added tests using the DataTree as part of
Operation types and eventually in a QuantumProgram will be needed as
well.
Details and comments
This is based on top of #15892 and will need to be rebased after that PR merges. To view just the contents of this PR you can refer to the HEAD commit: 6433027