Closed szabo137 closed 1 month ago
@AntonReinhard I think this is ready for review. You are right, deleting lots of code is a lot of fun 😆
BTW: In contrast to #57 the functions _incoming_flux
and _total_probability
can not be defined on PhaseSpacePoint
, because the latter always contain outgoing momenta, which these functions do not depend on. In general, there are cases, where one wants a PhaseSpacePoint
but only with the incoming particles: an IncomingPhaseSpacePoint
, maybe.
In contrast to #57 the functions
_incoming_flux
and_total_probability
can not be defined onPhaseSpacePoint
, because the latter always contain outgoing momenta, which these functions do not depend on. In general, there are cases, where one wants aPhaseSpacePoint
but only with the incoming particles: anIncomingPhaseSpacePoint
, maybe.
That makes sense. I think it would be nice to have an IncomingPhaseSpacePoint
, but if that one exists, then an OutgoingPhaseSpacePoint
probably should too, and having three times the essentially same struct seems bad for code duplication.
I think there are a few options to consider:
PhaseSpacePoint
be made up of an incoming and an outgoing PhaseSpacePoint
. Those two should be symmetric, so only one definition is really needed. Problem: There'll likely be more memory footprint and checking required, since a PhaseSpacePoint
would need to make sure that the process
, model
, and ps_def
of the incoming and outgoing parts are the same. I think this would also nicely allow to have a product definition of vectors of incoming and outgoing halves.PhaseSpacePoint
to have 0 length in or out particle vectors. We could then add some functions like has_incoming
and has_outgoing
to make sure the required parts are given where needed. Since the length of the vectors are part of the type info it should be possible to dispatch on this too, though I'm not sure if partial template specializations are a thing in Julia. Otherwise, the function definitions might get long again... Something like these:
const IncomingPSP = PhaseSpacePoint{PROC, MODEL, PSDEF, PSELT, IN_P, 0} where {PROC, MODEL, PSDEF, PSELT, IN_P}
const OutgoingPSP = PhaseSpacePoint{PROC, MODEL, PSDEF, PSELT, 0, OUT_P} where {PROC, MODEL, PSDEF, PSELT, OUT_P}
There might be more ideas, but these two came to mind.
In contrast to #57 the functions
_incoming_flux
and_total_probability
can not be defined onPhaseSpacePoint
, because the latter always contain outgoing momenta, which these functions do not depend on. In general, there are cases, where one wants aPhaseSpacePoint
but only with the incoming particles: anIncomingPhaseSpacePoint
, maybe.That makes sense. I think it would be nice to have an
IncomingPhaseSpacePoint
, but if that one exists, then anOutgoingPhaseSpacePoint
probably should too, and having three times the essentially same struct seems bad for code duplication.I think there are a few options to consider:
- Have the current
PhaseSpacePoint
be made up of an incoming and an outgoingPhaseSpacePoint
. Those two should be symmetric, so only one definition is really needed. Problem: There'll likely be more memory footprint and checking required, since aPhaseSpacePoint
would need to make sure that theprocess
,model
, andps_def
of the incoming and outgoing parts are the same. I think this would also nicely allow to have a product definition of vectors of incoming and outgoing halves.- Allow our
PhaseSpacePoint
to have 0 length in or out particle vectors. We could then add some functions likehas_incoming
andhas_outgoing
to make sure the required parts are given where needed. Since the length of the vectors are part of the type info it should be possible to dispatch on this too, though I'm not sure if partial template specializations are a thing in Julia. Otherwise, the function definitions might get long again... Something like these:const IncomingPSP = PhaseSpacePoint{PROC, MODEL, PSDEF, PSELT, IN_P, 0} where {PROC, MODEL, PSDEF, PSELT, IN_P} const OutgoingPSP = PhaseSpacePoint{PROC, MODEL, PSDEF, PSELT, 0, OUT_P} where {PROC, MODEL, PSDEF, PSELT, OUT_P}
There might be more ideas, but these two came to mind.
Understood! I agree that having two distinct types for incoming and outgoing phase spaces adds some duplications and boilerplate code.
Having the special cases in the current implementation, which switch off the in- or out-channel seems reasonable. But we should be careful that we do not end up checking for has_incoming
over and over again because this adds lots of indirections. Intuitively, having some type of product type sounds like the best solution, but I currently can't see the solution of the cost-benefit calculation.
Having the special cases in the current implementation, which switch off the in- or out-channel seems reasonable. But we should be careful that we do not end up checking for has_incoming over and over again because this adds lots of indirections.
Since we have all the information in the type info now, it should be enough to dispatch on IncomingPSP
and have any necessary checks done at compile time. I think I like the idea of the aliases.
With this, we update the process and cross-section interface to adopt the new phase space points. This solved #57.
TODOs