Caching harmonic sums#202
Conversation
|
Hi @felixhekhorn thanks for this idea, looks good to me! I have two minor comments:
|
Co-authored-by: Giacomo Magni <39065935+giacomomagni@users.noreply.github.com>
|
@felixhekhorn are you sure that Numba has no issue with globals? EDIT: in particular https://numba.pydata.org/numba-doc/dev/user/faq.html#numba-doesn-t-seem-to-care-when-i-modify-a-global-variable |
|
|
4c72a96 to
07aa331
Compare
…and added harmonic constants to eko.constants module
|
Hi,
Perhaps have a look and if its alright, we could merge this also and use the new cache in the splitting functions. |
| Features | ||
| ======== | ||
|
|
||
| <<<<<<< HEAD |
There was a problem hiding this comment.
now you have some nice merge conflicts - that you need to resolve ;-) (and might it be that you're still not running pre-commit? because that should have prevented you from committing thing ...)
There was a problem hiding this comment.
I have been using pre commit for the time_like branch but not here because pydocs requires imperative statements in docstrings(for instance, it needs to be Compute xyz instead of Computes xyz), however a lot of the previous functions (such as in as2, as3, etc.) do not implement it so I just skip pre commit for this branch for the time being. Will get to it soon enough ;)
There was a problem hiding this comment.
I know - but for new code you should, of course, do it and then you are only allowed to skip pre-commit in the very last step, i.e. when no one, but pydocstyle is complaining
|
@felixhekhorn @niclaurenti @giacomomagni @alecandido I have modified the complete space-like implementation to be compatible with the new harmonic cache (ADs (ASx and AEMx) and OMEs). Please have a look. In principal it should be fine to merge in of itself, however as all the tests were based on old cache system, they are failing. I have updated many of them but there is just too many for me to update on my own. |
| ------- | ||
| ome : numpy.ndarray | ||
| matching operator matrix | ||
| <<<<<<< HEAD:src/eko/evolution_operator/operator_matrix_element.py |
There was a problem hiding this comment.
here there is an unsolved conflict. The change coming from master is the correct one (same below)
|
|
||
| @nb.njit(cache=True) | ||
| def gamma_nsm(n, nf, sx): | ||
| def gamma_nsm(n, nf, cache, is_singlet): |
There was a problem hiding this comment.
I think is_singlet should not appear as argument in any function except for nsp which can be used as singlet and as non singlet.
Calling this function with is_singlet=True is misleading, so we should not have this possibility.
Viceversa hold for gg, gq, qg, ps ...
@niclaurenti is the expert for the mixed QED QCD one.
There was a problem hiding this comment.
I agree with @giacomomagni . In this case you don't need to pass is_singlet because you already know that we are not in the singlet sector. It is better to call get with is_singlet=False (however notice that is_singlet is useless for the first harmonic sums so consider using a default argument like is_singlet=None)
|
What is actually missing from this PR? I.e. why is this still draft? Please, put checkboxes in the OP for all the items, and tick those that you believe to be completed, even if they can be improved (everything can always be improved). |
|
okay there are endless confilcts in basically all files... maybe it's easier to start from scratch? |
I was trying to merge master here again, but everything (almost all the files in
Was there anything else to save from here @felixhekhorn @t7phy ? |
Yes I agree, I think starting in new branch is simpler. The two files are the only main changes to copy. Ofcourse, you could also copy all the space like ADs and OMEs as I had already added the new harmonic sums to them. |
I agree, a clean restart might be better ... (solving the |
|
closed in favor of #252 and new PR |
Here is my proposal for a central harmonic sums cache. Main concepts:
sxarray around (and better than the two in Cache harmonics sums for the as2 anomalous dimensions #179 ); furthermore this would solve Removing deprecated list of list in harmonic cache #143 , since we resort to a plain listcache.py) (Note that the order does not matter, since we would never use the number of the key, but only its name)if key == Sm21: return get(g3)+n+zeta, or we inline the relation where the thing is needed)Please tell me what you think!
The single commit here is just to lay out the idea at LO and by no means complete ...
cc @enocera
TODO