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 it does 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 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, and to also handle the
return type automatically by using a traits class.

| 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