-
Notifications
You must be signed in to change notification settings - Fork 4
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
Formulate List[StateTransitionGraph] in terms of a class #26
Comments
@spflueger moving the discussion of ComPWA/expertsystem#328 (review) here for now The
If I understand correctly, only 1. and 4. are useful once there are solutions, while 2. and 3. are of use only when there are no solutions. To me that suggests it's better that what is currently the |
The |
I thought about this a bit more. I think the only thing that makes this difficult is that the spin projections have different meanings in the different formalisms. So in the helicity formalism its helicities, while in the canonical its spin projections onto some fixed axis. To generate a result that is "independent" of the formalism, which could be put into any of the amplitude builders. I currently do not see a way around this other than computing the spin projections in parallel. Or some kind of adapter would be needed to convert. The good thing is that we currently do not support the canonical formalism natively, but put the canonical formalism on top of the helicity formalism (substituting helicity amps with a sum of canonical ones). Hence we only have the helicity spin projections and do not run into the problem above. Long term this problem will arise though. |
Generally good concept. I don't like the code raising exceptions on common or natural cases. Not executed rules should never happen (i dont really have proof for this, but thats at least to expect as a user). Hence an exception makes perfect sense here. However violated rules are very common, and also part of the responsibility of the framework. I think it would be much nicer to have this information in the "result" somehow instead of raising an Error for that |
Additional benefit: Still, it would be better to keep |
* refactor: remove particle_list.xml attributes * refactor!: remove XML attributes internally * fix: input filename for write to XML * refactor: extract load_default_particle_list * ci: do not check docstrings in tests * test: add I/O test for particle_list Closes ComPWA#25, closes ComPWA#26, and closes ComPWA#31
I think it would be safer to wrap the allowed transitions (currently represent by a
list
ofStateTransitionGraph
s) into a class, something likeStateTransition
. This object can then contain more advanced methods to give info about thelist
ofStateTransitionGraph
s it contains, as well as some checks when adding newStateTransitionGraph
s (for instance to enforce that the initial state and final state particles are consistent).The idea is that a
StateTransition
instance becomes the product that thereaction
module delivers.The text was updated successfully, but these errors were encountered: