Should we use 64 bit float to represent event weights, instead of 32 bit?

[SimonHeybrock]

scn.load and scn.load_nexus currently use float32 to repsent the event weights. These all default to 1.0 so this is fine. However, when summing events later the user may encounter a surprising precision loss.

We should carefully consider the tradeoff between risk for bugs and memory use. Reduction operations use double precision for intermediate values so many problems are avoided. Nevertheless final results can be affected significantly. For example:

import numpy as np
np.float32(75893996)

gives 75894000.

[nvaytet]

Reduction operations use double precision for intermediate values

Does this mean that if we sum all the events in a bin, then the sum correctly produces 75893996, but then it converts it back to float32 just before returning to match the dtype of the initial Variable, and this is where it goes wrong?

We could consider always make reduction operations return float64, but that behaviour may be surprising?

[SimonHeybrock]

Yes, that is where it goes wrong.

We could consider always make reduction operations return float64, but that behaviour may be surprising?

I think we had this discussion and decided against at that point, but we may reconsider.

[nvaytet]

I guess this is something surprising to developers, but maybe the vast majority of the users will not care about (or even notice) the difference between 32 and 64 bit?
Or at least they will care less about it than getting the wrong result?