-
Notifications
You must be signed in to change notification settings - Fork 32
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
parsing files into tensor networks #5
Comments
So import opt_einsum as oe
eq, shapes = oe.helpers.rand_equation(10, 3)
path, info = oe.contract_path(eq, *shapes, shapes=True) This is the function that
If there is a specific filetype you want to work with, hopefully it is just a matter of converting it into the |
I think some sort of file format that can be parsed into something like
for each tensor. That way there's no need to assume the expression in the event a partial contraction of the network is desired. The |
Is your initial thought to easily load 'hmetis' files to find contraction orders for, or are you wanting to try hmetis itself as a hypergraph partitioner? In the later case cotengra has In the first case, it would be very simple to write a function to do the opposite that translates the hmetis format to (By the way, contract_path(shapes[0], inds[0], shapes[1], inds[1], ..., shapes=True) ) Or possibly you are suggesting a canonical file format for these libraries...? Along these lines it might be best to open an issue in |
More the former, indirectly, to prepare input as you've outlined for |
I think On the other hand, if it is deemed not a good fit in |
I was wondering if there exists functionality in
cotengra
orquimb
oropt_einsum
to parse a file for the purposes of calculating contraction costs alone, without needing or caring about the elements contained within the tensors themselves.For instance,
networkx
has aread_edgelist
function andkahypar
has a way to parse files in thehMetis
format to build hypergraphs. One or both of these could be used to construct tensor networks with arbitrary elements where the aim is to optimize contraction costs.If something like this doesn't exist, I'd be interested in working on it. Please advise.
The text was updated successfully, but these errors were encountered: