Re: [CHANGESET]: First attempt at a single precision type.

[John W. Eaton]

On 28-Apr-2008, David Bateman wrote:

| The code duplication is not a big issue to me.. Templates are suppose to
| make it easy to add new code based on existing templates.. With existing
| untemplated code its easier just to copy the code and do regexp
| replacement on
| 
| double -> float
| Complex -> FloatComplex
| Matrix -> FloatMatrix
| NDArray -> FloatNDArray
| RowVector -> FloatRowVector
| ColumnVector -> FloatColumnVector
| ComplexFloat -> Complex
| ieee_lo - > ieee_lo_float
| octave_Inf -> octave_Float_Inf
| octave_NaN -> octave_Float_NaN
| octave_NA -> octave_Float_NA
| 
| and 99% of the conversion on the liboctave code is already done..

I agree that this is easy to do initially, but I think it could lead
to a maintenance problem later.  I generally don't enjoy having to fix
a bug in multiple places and having multiple versions of essentially
the same function makes it much more likely that there will be some
divergence and the risk of subtley different bugs in each.  As you
say, it makes sense to push as much as possible to the MArray2 and
MArrayN classes.  I just think we should try to use templates for even
some of those functions where it might not be immediately obvious that
a template solution is possible (for example, due to the need to call
different BLAS or LAPACK functions).

| That being said, I'd suggest the way forward is to take the existing
| code, and migrate as appropriate some of the untemplated code into the
| MArray2 and MArrayN classes. Good candidates for this are is_symmetric
| and fill. Other code such as append, stack, imag, real, etc might be
| made a template function, but there would need to have untemplated
| versions to convert the MArray2<T> and MArrayN<T> return types to the
| derived class.

I would expect we could handle those with simple inline wrappers
defined in .h files.  For example, see the attached patch.  It would
not be difficult to extend this to mixed types (complex/float/double),
and to also handle the return type automatically by using a traits
class.  It will take a little more work to handle stacking matrices
and row/column vectors and diag matrices.

| Should changes would also introduce dependencies of the
| MArray2 and MArrayN classes on the mx_* functions and so this might
| cause issues with the user types for galois, fixed, symbolic, etc in
| octave-forge. So maybe just to functions that don't introduce such
| dependencies should be templated..

Which functions are you thinking of that might cause trouble?

jwe