Investigate performance inplications of current ArbitrarilyDiscretizedFunction implementation

[Kevin Milner]

The current ArbitrarilyDiscretizedFunction? implementation uses a list of Point2D instances, which may not be efficient for hazard calculations

[Kevin Milner]

For all benchmarks I will be calculating 8 UCERF3 hazard curves in a single thread. Here are some initial test results:

With arbitrarily discretized functions: 92 s
With arb discr function passed in, fixed X function used internally: 87 s
With fixed X function passed in and used interally: 84 s

So this simple change can save over 6 % off of the calculation speed. The fixed X values class I'm using right now is org.opensha.commons.data.function.LightFixedXFunc, which is a mostly complete implementation. This doesn't include investigation of the constant creation/destruction of Point2D values used in the DiscretizedFunction? interface.

[Peter Powers]

Notes on LightFixedXFunction:

The drop in substitution of this into HazardCurveCalculator? broke code that (probably shouldn't have been) dependent on the write through ability of the Point2Ds returned by ArbDiscrFuncs? iterator(). I've made appropriate fixes, but it should probably be documented that the Point2D iterators are not write-safe.

The documentation states that the function x-values can not be changed, yet the getXValues method returns the internal mutable array. Is there something wrong with using the xValues and yValues methods of XY_DataSet instead (that return immutable lists)?