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

[David Bateman]

John W. Eaton wrote:
> On 29-Apr-2008, David Bateman wrote:
>
> | John W. Eaton wrote:
> | 
> | > 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..
>
> Yes, I don't think wrappers for these are absolutely necesary, I was
> just thinking of what might be better/easier to work with.  Maybe
> using the C-blas interface would also solve this problem?  Does it
> avoid the character string issues in a clean way?
>   
Hey I started programming in Fortran.. I'm so used to the Fortran BLAS
interface and have never used the cblas interface.. I have no idea :-)
> | 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
>
> OK.  It seems the primary use is in mx-op-defs, so maybe we could just
> avoid using these functions directly in the Array class hierarchy?
> With a better use of templates, maybe we would avoid most
> duplication.  For example, mx_inline_equal is used in the operator=
> methods in the following files:
>
>   CColVector.cc
>   CDiagMatrix.cc
>   CMatrix.cc
>   CRowVector.cc
>   boolMatrix.cc
>   chMatrix.cc
>   dColVector.cc
>   dDiagMatrix.cc
>   dMatrix.cc
>   dRowVector.cc
>
> Could we just forward from the functions in those files that
> use it to an operator== method in the Array<T> class?  
Sure..
> Changes like
> this can be done incrementally.
>   
I couldn't agree more.. Slower is better in a case like this..

> BTW, my approach to getting single working might have been to convert
> the current double classes to a use template class instantiated with
> double, then generate the corresponding single class.  But what you've
> done also seems reasonable to me, as it gets something working
> faster.  As I see it, given the changes you've made, we can also work
> toward a template version by pushing duplicate code to a template base
> class, and that's something that we can also do incrementally.
>   
Ok, in this case let me start on the first increment, and get the rest
of the code converted to single precision before you import the code
into your repository. I'd also like to add test code, though I suppose
that can wait as well, though is essential prior to a release. Give me a
couple of days..

D.


> jwe
>
>   


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