Introduce new field type double

[fjlinz]

With this MR, I bring the possibility to use double as field type.

In addition, following changes are introduced:

• struct FICS in GenericContainerFiller renamed to LeafBuffer, and functions accordingly: SetAddressFICS -> SetLeafAddress, SetFieldFICS -> SetFieldsFromLeaves
• LeafBuffer and IndexMap now in the AnalysisTree namespace
• Bugfix: VectorConfig::RemoveField now correctly subtracts N-1 from the saved number of fields N (new field will then get the value N again, instead of N+1 before)
• New Tests introduced for the double type and RemoveField

[fjlinz]

@lubynets Could you have a look to the proposed changes?

[lubynets]

Hi @fjlinz, thanks for the development!
The PR generally looks good to me, with one minor comment, which I left in the code.
But I am curious about the motivation: why storing of double fields is needed? I know that some algorithms (e.g. KF) are more stable with double instead of float, but is it the case, that the tree is supposed to store some floating-point values, which are known with such precision that float is not sufficient?

[fjlinz]

Hi @fjlinz, thanks for the development! The PR generally looks good to me, with one minor comment, which I left in the code. But I am curious about the motivation: why storing of double fields is needed? I know that some algorithms (e.g. KF) are more stable with double instead of float, but is it the case, that the tree is supposed to store some floating-point values, which are known with such precision that float is not sufficient?

HI @lubynets,
the issue is with how we define our time in the time-based digitization mode, the absolute time stamp is exceeding the floating precision. If you want to compute any dT's (hit time to event T0; diff to timeslice start time etc.), this does not work after AnalysisTree, so either I would have to provide a lot of dT-like floating fields in AnalysisTree, or just few and user can do calculation on their own, but this required to store double precision.
In principle, the price to pay is mostly compatibility, in terms of computing and storage, this should only have negligible impact.

[lubynets]

Hi @fjlinz, thanks for the development! The PR generally looks good to me, with one minor comment, which I left in the code. But I am curious about the motivation: why storing of double fields is needed? I know that some algorithms (e.g. KF) are more stable with double instead of float, but is it the case, that the tree is supposed to store some floating-point values, which are known with such precision that float is not sufficient?

HI @lubynets, the issue is with how we define our time in the time-based digitization mode, the absolute time stamp is exceeding the floating precision. If you want to compute any dT's (hit time to event T0; diff to timeslice start time etc.), this does not work after AnalysisTree, so either I would have to provide a lot of dT-like floating fields in AnalysisTree, or just few and user can do calculation on their own, but this required to store double precision. In principle, the price to pay is mostly compatibility, in terms of computing and storage, this should only have negligible impact.

Hi @fjlinz,
I am still wondering about the floating-point precision at CBM. Is the bottleneck for precision (1) the floating-point value per se or (2) the result of any arithmetic / algebra performed on floating-point values? If the case is (1) then storing doubles in the tree is ok. If the (2) is the case, one can store floats and simply static_cast them to double before the calculation, see the attached code snippet for example.
floating_precision.cpp
P.S. I do not object against the merged PR, just wanted to suggest using option (2) if it will solve the problems with time variables.

[fjlinz]

Unfortunately, its really case (1) since in the time-based mode, the absolute times for timeslice start/end time & event time very quickly exceed the floating precision.
TOF or so one could store relative to the event T0, event T0 relative to the timeslice start time, but for the latter at least there is no good solution, maybe a workaround using run start time + i * timeslice length. So I would argue, the double field will be very much needed here!

Thanks for having a look and merging already!

[fjlinz]

@lubynets Could you create a new release tag such that I can use this new feature within cbmroot?

Update [O.L.]: Done