Defaults and null

In CBMT each object kept track of its status - whether it was a valid value or not. This was potentially useful but brought a lot of code overhead and little benefit, so I have changed the strategy in Euclid.

Java is keen that objects are initialised, even if only to null or a deafult. null has its problems in that it causes null pointer Exceptions, which is virtually impossible to trap. The alternative (if foo==null ... throughout the code) is also unrealistic, and so I have given all objects well-defined defaults.

In many cases the default is sensible and causes no problems. Thus a default Complex is simply (0.0, 0.0), which could be useful in some places. Arrays are usually set to valid arrays with a size() of zero - the routines are written so that adding data to such an array is allowed and gives the natural result (an array of 1 element!).

In a few cases the default can give problems. Thus a Range cannot be initialised to a sensible default (0.0, 0.0 would imply that 0.0 could reasonably be a data point). In this case the range is set to impossible values (max < min) and the user can easily detect this. However, adding a value to such a range is allowed and it behaves quite as expected - the max and min are set to the new value.

With others, the default is sensible, but could cause problems in some routines. Thus the default Vector3 is (0.0, 0.0, 0.0), but if this is normalised (to a unit vector) it throws a ZeroLengthVector exception (of course any zero-length vector - e.g. that between coincident points - will also do this.)

In some cases the default is a reasonable place to start at, but unless modified will throw an Exception. Thus the default Univariate has no data points and so getMean() will throw an Uninitialised exception. Adding points to the default object would give valid results for getMean().

Good luck!

PeterMR, July 1996.