WIP: trying to implement amplitude normalization

[phdargen]

• Adding a method to renormalize the amplitudes prior to the fit such that: int |A_i(x)|^2 dx = 1.
  This has the advantage that the amplitude couplings are all on a comparable scale what makes it somewhat easier to set reasonable start values.
  If for example the coefficient of the largest amplitude is fixed to 1, the magnitudes of all others can be restricted to the range 0 < |c_i| < 1.

• The current implementation does not work yet.
  If all coefficients are fixed to one, all fit fractions are equal as expected
  but when a fit is performed, it can't find the same minimum as without the amplitude renormalization.
  So I suspect some part of the caching logic is not updated properly.

• It might also be worth to update the normalization on-the-fly (if e.g masses or widths are changing) as I think this could reduce the correlation between amplitude coefficients and lineshape parameters to some extend.

[tevans1260]

So ASFAIK the reason this is not working is that the probExpression for PolarisedSum is an AmpGen expression, i.e. dividing everything by a double will be the value of that double when you compile the thing, not when you later evaluate it, i.e. L133. The solution is to promote your m_scale to an expression (valued at 1 if this stuff is switched off, a parameter if it is switched on) in the changes around L140 of the confusingly named AmplitudeRules.cpp . The thing I'm not sure how to then do is to pass the value of this parameter given that it isn't a fit parameter (in other cases, its just been made a constant fit parameter to avoid this difficulty, but this an ugly hack so I try to think of something prettier, probably a new expression type with lambda function support.. ). This would also fix the third bullet point.

Lastly, could you use English spelling of normalise for consistency.

[tevans1260]

I just committed a new feature that should be helpful to resolve this; LambdaExpressions are a new type that can capture a lambda function (or similar) provided they return a double with no arguments - that can be used when evaluating expressions; by this mechanism you should be able to insert the additional normalisation terms into the probExpression and have them have the correct values / be updated. For example see test/test_Expression.cpp

[phdargen]

Thanks a lot for implementing this new feature. I was playing around a bit with it but can't get the normalisation to work.
I tried like this in AmplidueRules.cpp:

Expression TotalCoupling::to_expression() const
{
LambdaExpression scale( [this](){ return m_scale; } );
Expression val = std::accumulate( couplings.begin(), couplings.end(), Expression(1), [](auto& prod, auto& coupling ) { return prod * coupling.to_expression(); } );
auto f = scale * val;
return f;
}

It is my understanding that the TotalCoupling Expression is made a CompiledExpression in PolarisedSum.cpp, so this implementation should be similar as in test/test_Expression.cpp.
But this doesn't seem to do anything and produces the warning:
__cxx11::string LambdaExpression::to_string WARNING Not clear what is is you're trying to do here

I've also got a bit confused about the difference between Expressions and CompiledExpressions and their interplay. Maybe some insight here could help me to resolve this.

[tevans1260]

Strange; it should work in exactly the way you describe, with an expression being used as a placeholder that gets converted into a part of a compiled expression that gets evaluated. The warning is harmless - and easy enough to fix, its just from the handling of sub expressions not dealing with Lambda's properly yet (but this shouldn't make a difference..). Perhaps add a print statement to the Lambda to check that it gets called?
Also, this mechanism will only work (at the moment) for the PolarisedSum, as the handling of couplings is a bit different in the (In)coherentSum.

[phdargen]

Ah you are right, it actually does work as intended. The reason I thought it didn't was a bug in some other part of the code and I got spooked by the warning. I will see if I can also implement the normalisation on the fly. Concerning the CoherentSum, is it really necessary to have them both as the PolarisedSum evaluated with only spin-0 particles presumably should give the same result as the CoherentSum?

[tevans1260]

Yep, you're again quite right - CoherentSum should eventually be removed in favour of a renamed PolarisedSum, as its much cleaner and more generic, and as you say does exactly the same stuff. I just didn't get around to doing it yet (by v3 perhaps..)