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

[David Bateman]

John W. Eaton wrote:
> 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).
>   
Well easy is relative it was still a couple of days of solid work.
Agreed that there is the issue of maintenance to address, but if there
has to be specializations for the LAPACK/BLAS codes that won't go away.
Even functors will just increase the amount of code to maintain in my
opinion in that case, and the calling conventions of some complex LAPACK
functions are not the same as their real counterparts and so the methods
with functors in those cases could even be included in the
MArray2/MArrayN classes. There is also still the issue of the effect
such changes would have on the maintainability of user types in
octave-forge.

So therefore I think sure we should try and more some duplicated code
into MArray2/MArrayN classes, we should be careful about the external
types and probably left the specializations for the LAPACK/BLAS based
methods.

> | 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.
>   
Yes that is pretty much want I thought to do with all of these methods..
I'll work on move the others in my repository.
> | 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?
>   
Consider

bool Matrix::operator == (const Matrix& a) const

for example that depends on the function mx_inline_equals. There are
other examples as well such as the fourier methods that I wouldn't want
to move with using functors (though the complex and real versions of the
FFTPACK code would be different and cause problems), and the lapack/blas
code I'd prefer not to move at all.

D.


-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary