help-octave
[Top][All Lists]
Advanced

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

Re: single/double precision in C++


From: Jaroslav Hajek
Subject: Re: single/double precision in C++
Date: Tue, 10 Nov 2009 12:27:10 +0100



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

Attachment: ltfat.diff
Description: Text Data


reply via email to

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