Re: single/double precision in C++

[Peter L.]

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

Is there a way of getting around the

  (ltfat_complex*)f.data()

construction when ever I need a pointer to the actual data? It should be
easy as you suggest to change the typedef "ltfat_complex" to point to
the correct Octave complex format, so perhaps the ugly typecast in the
above line could go away. 

Cheers,

Peter.