octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John W. Eaton
Subject: Re: [CHANGESET]: First attempt at a single precision type.
Date: Tue, 29 Apr 2008 03:58:06 -0400

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?

| 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?  Changes like
this can be done incrementally.

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.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]