On Tue, Nov 10, 2009 at 12:22 PM, Jaroslav Hajek <address@hidden> wrote: > On Tue, Nov 10, 2009 at 11:48 AM, Peter L. <address@hidden> wrote:
>>> Templates could help you here. Octave 3.3.50+ provides a templatized function >>> octave_value_extract that extracts a specified matrix type from an octave_value. >>> If you want to target the 3.2.x series as well (which you probably
>>> do), you can steal these from the development sources and define them >>> conditionally. >>> >>> Using octave_value_extract, you could write something like: >>> template <class MT1, class MT2>
>>> static octave_value do_comp_dgt_fac (const octave_value_list& args, >>> const int a, const int M, >>> void
>>> (*lib_func) (/* TODO */)) >>> { >>> const MT1 f = octave_value_extract<MT1> args(0); >>> const MT2 gf = octave_value_extract<MT1> args(0); >>>
>>> >>> const int L = f.rows(); >>> const int W = f.columns(); >>> const int R = gf.rows()*gf.columns()/L; >>> >>> const int N = L/a;
>>> >>> MT2 cout(M,N*W*R); >>> >>> lib_func (...); >>> >>> return cout; >>> } >>> >>> and then call it for the 4 cases
>>> return do_comp_dgt_fac<Matrix, ComplexMatrix> (args, a, m, dgt_fac_r); >>> etc >> >> Thanks for the suggestion, this is just the sort of stuff I don't know >> about. This made me read up on trait classes.
>> >>> The C prototypes pose another problem as these use different complex >>> number type than Octave (Octave uses std::complex and assumes the >>> layout conforms to Fortran and C99).
>>> >>> A quick solution is to let these types be implied by the template, but >>> that is quite unsafe, as it will silently crash if you misspell a >>> function's name. A better solution is to provide a trait class
>>> converting Octave's types to LTFAT's. A possibly yet better solution >>> is to alter ltfat.h in such a manner that it will use a user-defined >>> complex type if one is provided via a #define:
>>> >>> #include <oct.h> >>> #define LTFAT_USER_COMPLEX Complex >>> #define LTFAT_USER_SCOMPLEX FloatComplex >>> #include "ltfat.h" // will now use Complex and FloatComplex for the prototypes
>>> >>> this can be useful in general when interfacing with other software. >> This is actually what is already being done: >> >> typedef fftw_complex ltfat_complex; >>
>> so the complex type is bit-compatible with Octave's. >> > > Yes, that is the assumption (it's not actually guaranteed by C++, but > Octave uses the same assumption), but being compatible is not enough -
> C++ still won't allow you to implicitly convert fftw_complex to > std::complex. > > I checked out ltfat and hacked together a patch (not actually tested) > demonstrating my meaning: >
Once more, this time complete and not garbled (attached).
hth -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic
url: www.highegg.matfyz.cz