I just note down this idea/concept for a possible improvement in the future. It might seem like a lot of work, but I think less then it seems and it can be done within 2-6 months (single person, experience dependent).
Current flaws in the design of ComPWA are:
All mathematical expressions (operators, function etc) have to be separately implemented in each evaluation/computation/calculation backend. This is not DRY and also way more error prone.
Consequently, if the user wants to implement a new model, he has to write c++ code for each of the calculation backends.
The extraction of components of a Function is currently not elegant, since they have to be extracted from the xml model file using a Builder class.
There might be more, but these are currently in my mind...
In my opinion the introduction of a ComPWA math language is able to solve all the above flaws very elegantly without introducting new flaws! You would express all of your mathematical calculations in this language. Each calculation backend has a single converter that converts a ComPWA math language expression into an Intensity or Estimator (Function interface).
Implementation details:
Use an existing, versatile and widely used Math markup language for example Content MathML. This has the advantage that the syntax is stable and calculations can easily be imported and exported to ComPWA.
Extend this language with special operators/function like a Breit Wigners and or labels to easily find tags (useful for component extraction). These special physics operations or functions are just new xml nodes that define a deeper structure. This has the advantage that the physics models are only defined once and can be used in all computation backends in the same way (single source of truth). Also the user is able to easily add new models, without having to touch any code!
Since this markup language is based on xml, the parsing and exporting is easily done with a third party library (like boost or pugixml)
These ComPWA MathML calculation objects are just handed around ComPWA until a calculation has to be performed. Then a converter (one for every calculation backend) translates this calculation object into an evaluatable c++ Function defined int the Core/Function.hpp interface.
I just note down this idea/concept for a possible improvement in the future. It might seem like a lot of work, but I think less then it seems and it can be done within 2-6 months (single person, experience dependent).
Current flaws in the design of ComPWA are:
Functionis currently not elegant, since they have to be extracted from the xml model file using a Builder class.In my opinion the introduction of a ComPWA math language is able to solve all the above flaws very elegantly without introducting new flaws! You would express all of your mathematical calculations in this language. Each calculation backend has a single converter that converts a ComPWA math language expression into an Intensity or Estimator (Function interface).
Implementation details:
Core/Function.hppinterface.