[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
- Re: [CHANGESET]: First attempt at a single precision type., (continued)
- Re: [CHANGESET]: First attempt at a single precision type., David Bateman, 2008/04/29
- Re: [CHANGESET]: First attempt at a single precision type., David Bateman, 2008/04/30
- Re: [CHANGESET]: First attempt at a single precision type., John W. Eaton, 2008/04/30
- Re: [CHANGESET]: First attempt at a single precision type., John W. Eaton, 2008/04/30
- Re: [CHANGESET]: First attempt at a single precision type., David Bateman, 2008/04/30
- Re: [CHANGESET]: First attempt at a single precision type., John W. Eaton, 2008/04/30
- Re: [CHANGESET]: First attempt at a single precision type., David Bateman, 2008/04/30
- Re: [CHANGESET]: First attempt at a single precision type., John W. Eaton, 2008/04/28
- Re: [CHANGESET]: First attempt at a single precision type., Jaroslav Hajek, 2008/04/28
- Re: [CHANGESET]: First attempt at a single precision type., David Bateman, 2008/04/29
- Re: [CHANGESET]: First attempt at a single precision type.,
John W. Eaton <=
- Re: [CHANGESET]: First attempt at a single precision type., David Bateman, 2008/04/29
- Re: [CHANGESET]: First attempt at a single precision type., Peter L., 2008/04/29
- Re: [CHANGESET]: First attempt at a single precision type., Jaroslav Hajek, 2008/04/29
- Re: [CHANGESET]: First attempt at a single precision type., David Bateman, 2008/04/29
- Re: [CHANGESET]: First attempt at a single precision type., John W. Eaton, 2008/04/29
- Re: [CHANGESET]: First attempt at a single precision type., David Bateman, 2008/04/29
Re: [CHANGESET]: First attempt at a single precision type., Jaroslav Hajek, 2008/04/28