-
Notifications
You must be signed in to change notification settings - Fork 3
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
Computing $L_i$ instead of $L$ #151
Comments
Maybe I am missing some motivation; what would be the advantage of doing this? Here Anyway I think we already do something very similar: the preimages are computed branch-by-branch, so we compute those terms separately, store them in the In other words, the elements of our "dual" are already the functions |
Oh OK maybe I get it now; your plan is having this part when we split the assembly over branches as a "common sub-factor" of For the future my suggestion would be instead having completely separated And in a sense |
I am thinking about the fact that each one of the branches can be computed in parallel, mostly, but I need to think more about it... |
Note that at least for Apart from that, I agree that preimages along different branches could be computed in parallel, and then afterwards also |
A first modification we could do, in the long refactor of Dual+iterate could be the following.
If$T$ satisfies the following assumption there exists a partition ${P_i}$ of $M$ of full measure such that
then we can write
where
to each branch is associated an operator, and the discretized operator is the sum of these operators.
The text was updated successfully, but these errors were encountered: