-
Notifications
You must be signed in to change notification settings - Fork 8
TiledArray code generation #321
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
base: master
Are you sure you want to change the base?
Conversation
|
@Krzmbrzl I think export framework will be useful here? I tried a couple approaches to support this in one sitting, but the splitting up of single term evaluation into intermediary steps only when strictly necessary turned out to require non-trivial amount of coding. It is doable for sure, but better made use of the export framework. |
What exactly do you mean by that? |
Look at the generated code for the first term and the last term in the example above. |
|
So you want to have binary contractions only when this allows intermediate reuse and otherwise want to use the unfactorized equations? Why? At the moment the export framework is based on evaluation trees and hence is restricted to binarized contractions as input. Technically, you could probably re-assemble the original expression in the backend and only export that but that seems like a fair amount of work to get right in general. |
Not exactly what I meant. In TArray R; // the final result is in R
TArray I1;
I1("a1,b1") = A("a1") * B("b1");
R("a1,b1,c1") = I1("a1,b1") * C("c1");However, TArray R;
R("a1,b1,c1") = (A("a1") * B("b1")) * C("c1");No need to create the temporary PS I added the missing parenthesis in the last statement of the generated example code.. |
|
I see. Does that mean there is an actual disadvantage in creating the intermediates explicitly even in cases where it's not necessary? I mean, other than code readability But I guess the bottom line is that it can likely be done right now by adding some logic into the backend generator but it kinda goes against the design philosophy of the export framework (backend generators should contain only a minimal amount of logic in order to be easily written). I would propose focusing on getting the export framework with its current abilities and restrictions merged first and then think of how to generalize it to support non-binary contractions as well. I think this would also be nice for generating code that is interpreted by a specialized tensor compiler. |
|
I agree, minimal binarized TA code emission should be the initial goal. Dispatch to more general backends capable of evaluating whole TNs is longer term. |
Consider the following sum of tensor networks:
This PR attempts to support
TiledArraycode generation from it that looks like the following or its equivalent.