Consistent Class dtypes

[garrettwrong]

While beginning to work with the code and make minor changes I found several areas (both new classes and Matlab ports) where numerically reasonable dtype handling did not exist or was inconsistent. IE a lot of silent mixed mode.

For example, some classes do not have a dtype attribute, but clearly should. In other cases, a class may be instantiated as, or with, single precision, but internally creates arrays or invoke functions which use/return a default datatype which is double, without warning. Some cases are setup to use doubles, but then instantiate classes that default in some internal way to single.

Besides being confusing, it creates problems that will become increasingly harder to find.

I propose the following:

• Classes that handle ndarray like things should have a dtype attribute
• This attribute should handle numpy defined dtypes, but may admit (with polite deprecation warning) 'single'/'double' to support old code.
• If a class is instantiated with or passed arrays, we should check their dtypes are consistent, and inherit that type if it is a constructor.
  • Otherwise default to double, unless there is strong proponent of singles.
• Any mixed mode encountered should generate a warning or raise error.
  • Halting is simpler. To generate warnings we need to decide whether we want to upcast or downcast on mix. Both have concerning implications. By halting, maybe with a suggestion, we let the user decide.

[garrettwrong]

In our 10/15 dev meeting we decided to migrate the default ASPIRE dtype to single precision. Currently we're mostly doubles, so this may involve working around a few tests that are currently sensitive to numerical precision.

[garrettwrong]

This has been covered by #296 .