Implement the light part of the polarized coefficient functions

[Radonirinaunimi]

Implement the massless spin-dependent coefficient functions $g_1$, $g_4$ and $g_L$ (up to NNLO).

Status of the NC implementation:

SF	LO	NLO [NS, Gluon]	NNLO [NS, Gluon, S]
g1	✅	[✅, ✅]	[✅, ✅ , ✅]
g4	✅	[✅, 0]	[✅, 0 , 0]
gL	0	[✅, 0]	[✅, 0 , 0]

TODO:

• Apfel++ benchmark and parity violating couplings fixes.
• Target Mass Correction (implemented for $g_1$)
• CC implementation (should be straight forward) same relations ad NC (Omitted)
• TMC for polarized observables (delegated to Polarized FONLL coefficient functions #187)

[Radonirinaunimi]

Also, while wanting to document the polarized TMC (given that the approximations were not available, for example), I noticed that there were materials in extra/TMC that are out of date/no longer needed. I assume that these should be cleaned up?

[alecandido]

Also, while wanting to document the polarized TMC (given that the approximations were not available, for example), I noticed that there were materials in extra/TMC that are out of date/no longer needed. I assume that these should be cleaned up?

extras/ is mostly preserving the historic memory of yadism development, to reconstruct how and why we did things.
For sure at some point we might want to clean up things, but for the time being we are busy enough with higher priorities, so personally I will not invest much energy in it soon.

[Radonirinaunimi]

extras/ is mostly preserving the historic memory of yadism development, to reconstruct how and why we did things. For sure at some point we might want to clean up things, but for the time being we are busy enough with higher priorities, so personally I will not invest much energy in it soon.

I understand, it was more of since I will be touching that folder I might as well do so. Just wanted to know if you'd agree that this should be taken care of in the future.

[alecandido]

I understand, it was more of since I will be touching that folder I might as well do so. Just wanted to know if you'd agree that this should be taken care of in the future.

In the future for sure (something we'll want to keep, but definitely there are stuffs to be dropped).

For the time being, my advice is to just open a new folder inside, name after your topic, and put your stuffs in. Just forget about the rest 😅

[felixhekhorn]

Convert comments on 9943e65#comments to review (sorry)

[Radonirinaunimi]

Are you happy with these now @felixhekhorn?

[felixhekhorn]

apart from the potential $F_3$ bug this should be fine ...

[giacomomagni]

apart from the potential F3 bug this should be fine ...

Do you mean g1 == F3 for the NS ?

[Radonirinaunimi]

apart from the potential F3 bug this should be fine ...

Do you mean g1 == F3 for the NS ?

No, I believe Felix meant this comment:

https://github.com/NNPDF/yadism/pull/173/files#r1183519543

[Radonirinaunimi]

@felixhekhorn, I agree that the h3_ker should be equal to k1_ker and I have fixed it in da50b10.

With this, this PR could now be merged.

[alecandido]

Part of the breaking tests are breaking because we do not support py3.7 any longer, at least in EKO (and consequently also in yadism, at least because of the dependency).

It should be sufficient to upgrade the version range of regression to be the same of unit tests.

However, even py3.8-9 are failing, and here the workflow complains about a missing requirements.txt file.
Should we disregard these tests at all (then deactivating), solve here, or solve in a further PR (i.e. open now an issue)?

[alecandido]

I haven't reviewed yet the NNLO numbers (and I won't do it, of course) and TMC.

However, what I saw is perfectly fine, so you could also consider merging :)

[alecandido]

Not a strong opinion, but for these names I usually prefer dropping the is_ for simplicity.
On one side it is more or less the same, on the other it is slightly more consistent, because it is a property (the is_something() is more consistent for a function, since it is an action, but a property is supposed to be a pseudo-attribute, so it should pretend to be an entity, not an action).

[Radonirinaunimi]

This, I do not also have a strong opinion, but at least doing it this way is consistent with what are currently there:

yadism/src/yadism/observable_name.py

Lines 113 to 114 in 0e0dc11

	@property
	def is_heavy(self):

yadism/src/yadism/observable_name.py

Lines 125 to 126 in 0e0dc11

	@property
	def is_raw_heavy(self):

yadism/src/yadism/observable_name.py

Lines 130 to 131 in 0e0dc11

	@property
	def is_asy(self):

yadism/src/yadism/observable_name.py

Lines 135 to 136 in 0e0dc11

	@property
	def is_heavylight(self):

yadism/src/yadism/observable_name.py

Lines 140 to 141 in 0e0dc11

	@property
	def is_composed(self):

So, in order to be consistent everywhere we'd also need to replace the rests, which probably should better be done in a different PR.

[Radonirinaunimi]

Part of the breaking tests are breaking because we do not support py3.7 any longer, at least in EKO (and consequently also in yadism, at least because of the dependency).

It should be sufficient to upgrade the version range of regression to be the same of unit tests.

However, even py3.8-9 are failing, and here the workflow complains about a missing requirements.txt file. Should we disregard these tests at all (then deactivating), solve here, or solve in a further PR (i.e. open now an issue)?

I was indeed wondering about this, but honestly I think that doing it in another PR would be the best course of actions, if not for the git history.

[alecandido]

I was indeed wondering about this, but honestly I think that doing it in another PR would be the best course of actions, if not for the git history.

The main reason why I pointed it out, it's exactly that those workflows are not running in master, so they are being reintroduced by this PR.

[felixhekhorn]

I was indeed wondering about this, but honestly I think that doing it in another PR would be the best course of actions, if not for the git history.

The main reason why I pointed it out, it's exactly that those workflows are not running in master, so they are being reintroduced by this PR.

Well I deactivated them (as said in #190 ) in master because I realised here they were failing and they were stupid - just merge master here (dropping the workflow)

[Radonirinaunimi]

@alecandido Are you happy for this to be merged now?

[alecandido]

About TMC, I have the feeling there might be too much copy-pasting around, but in general (it has been simply passed a lot of time since I took a look at it).

I would not block this PR certainly because of that, and other refactors are better coupled to numerical FONLL implementation, rather than polarized.

[Radonirinaunimi]

About TMC, I have the feeling there might be too much copy-pasting around, but in general (it has been simply passed a lot of time since I took a look at it).

I would not block this PR certainly because of that, and other refactors are better coupled to numerical FONLL implementation, rather than polarized.

Ok, I'm merging this now.

As for the TMC, apart from the bug in $F_3$ that has already been there, there isn't that much. There is only the _k functions implemented in the base class, which currently could be moved outside as they are only used by $g_1$, but when $g_2$ will be implemented in the future these functions will have to be in the base class.