Revert `ev_op_max_order` to integer

[felixhekhorn]

• during the developments for QED ev_op_max_order has become a tuple (QCD, QED), because we thought we needed it
• recall that ev_op_max_order is the maximum perturbative order in which we expand the $U$ matrices for "perturbative-exact" - see also https://eko.readthedocs.io/en/latest/theory/DGLAP.html#id7
• however, later we found out that there is no "perturbative-exact" solution for QED, but only the iterated one - see QED paper

Question: do we want to change ev_op_max_order back to just an integer? @tgiani @giacomomagni

This would be of course a breaking change (and thus directly related to #417) and to make it even more explicit we could also rename it to ev_op_max_order_qcd

[giacomomagni]

Since we need to do a compatibility layout in any case we can add this additional conversion...

[scarlehoff]

Just to say, the mismatch of ev_op_max_order being an integer here:

eko/src/eko/evolution_operator/__init__.py

Line 372 in c08fc01

ev_op_max_order : int

but being passed here:

eko/src/eko/evolution_operator/__init__.py

Line 415 in c08fc01

ev_op_max_order,

to a function that understand it as a tuple:

eko/src/eko/kernels/singlet.py

Line 584 in c08fc01

ev_op_max_order : tuple(int,int)

it's making the tests fail in my computer for python 3.13

From what I can see numba is constructing a path by which it arrives with an int to a place where it is used as a tuple:

E            >>> getitem(int64, Literal[int](0))
E           There are 22 candidate implementations:
E                - Of which 22 did not match due to:
E                Overload of function 'getitem': File: <numerous>: Line N/A.
E                  With argument(s): '(int64, int64)':
E                 No match.
EE
E           File "../src/eko/kernels/singlet.py", line 371:
E           def r_vec(gamma_singlet, beta, ev_op_max_order, order, is_exact):
E               <source elided>
E               r = np.zeros(
E                   (ev_op_max_order[0] + 1, 2, 2), dtype=np.complex128

[felixhekhorn]

I wouldn't rely on the documentation, that might well be outdated - instead, one would needs to look at the code.

1. I don't understand how this can be a Python version issue: if it is a type mismatch, it is so in any version (types are built-in things and unlikely to change: ints and tuples are there since the start)
2. then looking to the code quoted by numba, I see it does want a tuple:

   eko/src/eko/kernels/singlet.py

   Line 371 in c08fc01

   (ev_op_max_order[0] + 1, 2, 2), dtype=np.complex_

3. then I bubble up and see that it should be passed to quad_ker (the function you quote first) as a tuple:

   eko/src/eko/evolution_operator/__init__.py

   Line 845 in c08fc01

   ev_op_max_order=tuple(self.config["ev_op_max_order"]),

   (so indeed documentation is outdated)
4. this then seems to imply that you are not using the correct config, which should map 1:1 onto operator_card
5. one trivial possibility is of course, that the test is just wrongly written

PS: This is to say: this issue will require some actual changes and not work out of the box

[scarlehoff]

that the test is just wrongly written

I'm surprised it passes in the CI then.

[felixhekhorn]

can you please give more context: when, where exactly does the error appear? e.g. if you open a PR we could see precisely from the CI 🙃

[scarlehoff]

#470