Add flag to CompareWorkspaces so users can specify NaN == NaN behavior

[rboston628]

Description of work

Summary of work

Adds a flag to set whether NaN values should be considered equal to the CompareWorkspaces algorithm.

Purpose of work

When CompareWorkspaces was originally written, it was written so that if two workspaces had NaN for a value, the two NaN values would compare as equal. This is contrary to the IEEE 745 specification, which says that NaN compares false against everything, including other NaNs, so that NaN == NaN should evaluate as false.

In attempting to fix this, it was found there are at least a few tests relying on the old behavior of comparing NaNs. Therefore, this provides a flag to CompareWorkspaces so that users can elect for NaNs to be considered equal.

Further detail of work

Within CompareWorkspaces, the methods to check if two values are within a tolerance have been replaced to rely on the FloatingPointComparison operators, with a check to return true if both values are NaN and the NaNsEqual flag was set to true.

The CheckAllData flag will now work on two type of peaks workspaces.

More tests were added for CompareWorkspaces and FloatingPointComparison, to handle more cases involving NaNs or extreme numbers.

A few cppcheck suppressions were removed.

Also, some comments were added in some parts of the code. These places were found using a search for abs( and fabs( within the code for possible replacements with withinAbsoluteDifference. While not suitable for replacements, they could lead to improvements in the code.

To test:

New tests were added to

• CompareWorkspacesTest.h
• TableColumnTest.h
• FloatPointComparisonTest.h
  covering several situations with NaNs and also with extreme values.

These tests should be convincing that the behavior of NaNs with and without the flag is as expected.

---

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.