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

[David Bateman]

Jaroslav Hajek wrote:
> On Mon, Apr 28, 2008 at 9:04 AM, David Bateman <address@hidden> wrote:
>   
>> John W. Eaton wrote:
>>  > On 27-Apr-2008, David Bateman wrote:
>>  >
>>  > | Basically, as this is just a copy of the double precision type I'd
>>  > | always thought it would be relatively easy to add this. With that idea I
>>  > | didn't attempt to make template versions of the copied code to reuse it
>>  > | and just copied it as the easier fashion to get this working. Therefore,
>>  > | there might be some simplifications that might be done..
>>  >
>>  > I'd been hoping to do this with templates and specializations.  Do you
>>  > think it is worth doing that eventually?  It seems you should now have
>>  > all (or most) of the specializations.
>>
>>  In fact most of the stuff in liboctave it probably doesn't make sense to
>>  have templates as there is a lot of cases where the underlying code is
>>  different (eg a call to sgetrf rather than dgetrf)..
>>
>>     
>
> still, the code duplication seems to be massive. The different Fortran
> function names can be handled by overloaded wrappers. OTOH, it is
> certainly desirable to have as much code compiled as possible, and
> users aren't supposed to instantiate Matrix for anything other than
> float and double.
> Is there any possibility to put a template for a method in a .cc file,
> explicitly instantiate there, and just export the explicit instances?
>
> I'm thinking about something like this:
> file RealMatrix.h:
>
> template <typename T>
> class RealMatrix
> {
>   bool is_symmetric(void) const;
> };
>
> template class RealMatrix<float>;
> typedef RealMatrix<float> FloatMatrix;
>
> template class RealMatrix<double>;
> typedef RealMatrix<double> Matrix;
>
> // external explicit instances ????
> template void RealMatrix<float>::is_symmetric();
> template void RealMatrix<double>::is_symmetric();
>
> file RealMatrix.cc:
>
> # include RealMatrix.h
> template<typename T>
> void
> RealMatrix<T>:: is_symmetric(void)
> {
>  // code here
> }
>
>
> It seems not to be possible with g++. In that case, the best way to
> keep maximum code precompiled is probably David's, despite the code
> duplication.
>
>   
This is pretty much what is already done in the MArray2 and MArrayN
classes.. Anything that we can make templates of in the Matrix,
ComplexMatrix, FloatMatrix and FloatComplexMatrix classes should be
included in the MArray2 class and the same for the NDArray versions with
the MArrayN class. There is probably some of the code that might be
converted to a template function that could be pushed from the derived
classes to MArray2 and MArrayN..

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.. There
are a couple more regexps for the liboctinterp code for the array_value,
etc methods, but this was my basic technique of writing this code.. As I
said minimum work for me :-)

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. 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..

Regards
David

-- 
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