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

[David Bateman]

John W. Eaton wrote:
> On 28-Apr-2008, Jaroslav Hajek wrote:
>
> | 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.
>
> I'd really like to avoid the duplication as much as possible, even if
> it's likely that there will only be two instantiated types.
>
> Although it seems that we would need to have explicit specializations
> for functions that call BLAS and LAPACK routines, I think we can get
> the compiler to do a lot of that work for us if we use functors and
> some wrappers, though I do agree that using functors to wrap functions
> that take many arguments (like the BLAS and LAPACK functions do) will
> add some complication to the code.  Template tricks can avoid the need
> to define specific functors for each type signature we will encounter,
> but it means building up the machinery to do it (I think the text C++
> Templates: The Complete Guide by Vandevoorde and Josuttis outlines all
> the techniques we would need.
>
> Whether we use functors or not, it might be good to wrap the BLAS and
> LAPACK routines anyway, so we can avoid the details of how character
> arguments are passed.
>   
Could I avoid that at this point, at least for the functions that use
BLAS/LAPACK code in them? This seems like a lot of work to get back to a
point I'm already at..

> I'm not sure I understand the problem.  We already have some fucntions
> defined in MArray2 (for example).  If needed, there are forwarding
> functions in the Matrix class so that the return types of these
> functions are correct.  In the case of is_symmetric, the return type
> should always be bool, so I don't think a forwarding function would
> even be necessary.  I would expect inheritance rules to make this
> fairly simple.
>
>   
There is an issue in that if there is a dependency on an mx_inline
function or some such in MArray2 or MArrayN classes then the user
classes in octave-forge will be broken... If these methods aren't needed
for a user class I see no reason to have to define them.. I suppose the
right way around this is to use virtual methods in the MArray2 and
MArrayN classes to work

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