Add Logarithmic event grouping to CompressEvents

[rosswhitfield]

Description of work

Summary of work

SNAPRed would like to intelligently use CompressEvents where the criteria for Time-of-flight compression follows the logarithmic mode used for histogramming TOF/d-spacing. This allows the retention of progressively finer compression tolerance at low times-of-flight, where Bragg peaks are sharper. This should be done in a way that is consistent with the existing output of the histogram representation of the output of Rebin. When possible, parameters should mimic the analogous versions in Rebin. This requires one additional parameter "BinningMode" with the possible values of "Linear" (the default) and "Logarithmic" (the new mode).

For a single spectrum with a minimum TOF=TOFmin, the following two workspaces are expected to give the same y-values in the histogram representation

CreateSampleWorkspace(OutputWorkspace="eventWS", WorkspaceType="Event", Xmin=300, XMax=20000)
ExtractSpectra(InputWorkspace="eventWS", OutputWorkspace="eventWS", StartWorkspaceIndex=0, EndworkspaceIndex=0) # get first spectrum
# create histogram
Rebin(InputWorkspace="eventWS", OutputWorkspace="histoWS", Params=(300,-0.001,2000), PreserveEvents=False)
# compress events
CompressEvents(InputWorkspace="eventWS", OutputWorkspace="eventWS", tolerance=0.001, BinningMode="Logarithmic")
Rebin(InputWorkspace="eventWS", OutputWorkspace="eventWS", Params=(300,-0.001,2000))
# compare
np.all(mtd["eventWS"].readY(0) == mtd["histoWS"].readY(0))

Fixes EWM3030

Further detail of work

To test:

---

Reviewer

Please comment on the points listed below (full description).
Your comments will be used as part of the gatekeeper process, so please comment clearly on what you have checked during your review. If changes are made to the PR during the review process then your final comment will be the most important for gatekeepers. In this comment you should make it clear why any earlier review is still valid, or confirm that all requested changes have been addressed.

Code Review

• Is the code of an acceptable quality?
• Does the code conform to the coding standards?
• Are the unit tests small and test the class in isolation?
• If there is GUI work does it follow the GUI standards?
• If there are changes in the release notes then do they describe the changes appropriately?
• Do the release notes conform to the release notes guide?

Functional Tests

• Do changes function as described? Add comments below that describe the tests performed?
• Do the changes handle unexpected situations, e.g. bad input?
• Has the relevant (user and developer) documentation been added/updated?

Does everything look good? Mark the review as Approve. A member of @mantidproject/gatekeepers will take care of it.

Gatekeeper

If you need to request changes to a PR then please add a comment and set the review status to "Request changes". This will stop the PR from showing up in the list for other gatekeepers.

[sf1919]

pre-commit.ci run

[peterfpeterson]

This does the job, but I think it could be reduce duplicate code it used a function pointer to calculate the upper bound for the current group of events being accumulated. For log binning

double [tolerance](const double lastTof){ return lastTof * (1 - tolerance); }

and for linear binning

double [tolerance](const double lastTof{ return lastTof + tolerance; }

with an analogous variant for the fat events. Using a function pointer would also make it much more obvious to future developers that it is only the right boundary that is different between the two branches.

[rosswhitfield]

This does the job, but I think it could be reduce duplicate code it used a function pointer to calculate the upper bound for the current group of events being accumulated. For log binning

double [tolerance](const double lastTof){ return lastTof * (1 - tolerance); }

and for linear binning

double [tolerance](const double lastTof{ return lastTof + tolerance; }

with an analogous variant for the fat events. Using a function pointer would also make it much more obvious to future developers that it is only the right boundary that is different between the two branches.

It's not that simple, the comparator is also different, linear is using <= (because that is how it was designed) and log is using < so that it matches what Rebin does for log binning.

Finding the next bin_end is also more complicated for log binning.

But I have it all working now with less code duplication. So take another look.

[peterfpeterson]

There is an infinite loop hiding in this, when the first event has time-of-flight is zero. This should only be valid for positive time-of-flight. My suggestion is that (for log compression) if the smallest "tof" is negative, throw an exception, if it is zero, move the smallest to be fabs(tolerance).

[peterfpeterson]

Looks good to go. I like the extra test.