Open redeboer opened 2 weeks ago
Note: HS3 specifications probably won't help us here yet, because complex-valued functions are not supported.
I see great benefits in defining all functions fully in the format, there are cons as well. It would make it possible for different files to have different "BreitWigner"s, which is something I would not want.
I see that it might be challenging to convince the community to stick with a single definition of the BW. But it would be nice. For now, I would like to try that, i.e. treat all non-standard parametrization as exceptions
Btw, there is already a way to code simple functions in HS3. They are strings.
"distributions": [
{
"expression": "1/((m*m-s)^2+(m*G)^2)",
"name": "BreitWigner",
"type": "generic_dist"
}
],
The section
functions
defines the lineshapes that should be inserted intoparametrization
of the propagators. Example:https://github.com/RUB-EP1/amplitude-serialization/blob/9fcd26e8c7cd487d93f902529c5513c977e03e62/Lc2ppiK.json#L42
https://github.com/RUB-EP1/amplitude-serialization/blob/9fcd26e8c7cd487d93f902529c5513c977e03e62/Lc2ppiK.json#L756-L776
Currently, the format specifications do not yet include an exact definition of the function tree, only a
type
description (here:BreitWigner
). Some solution ideas:functions
. Disadvantage: the JSON file might become very large (human-readable?). Advantage: all information is contained within a single file.In either case, we preferably serialize to a common mathematical markup language. Afaics, for JSON, there is only MathJSON, which is not widely adopted. OpenMath and MathML are more widely adopted (especially in web applications), but use XML, which is hard to read. But then again, lineshape expressions can be large and JSON won't be pretty either.