Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: James Avery <avery@di...>  20111007 04:11:04

Hi all, I'm writing code that implements time critical parts of a large octave program in C++. The SWIG wrappers work very well, except for the most important aspect when interfacing with Octave: passing vectors and matrices back and forth over the SWIG interface. For some reason, no matter what I do, SWIG will ignore any typemaps I come up with. The SWIG+Octave documentation has stated the following ever since version 1.3: "29.3.17 Matrix typemaps Octave provides a rich set of classes for dealing with matrices. Currently there are no builtin typemaps to deal with those. However, these are relatively straight forward for users to add themselves (see the docs on typemaps). Without much work (a single typemap decl say, 5 lines of code in the interface file), it would be possible to have a function double my_det(const double* mat,int m,int n); that is accessed from Octave as, octave:1> my_det(rand(4)); ans = 0.18388" Can anyone with a better understanding of how SWIG and Octave interact shed some light on what those 5 lines of code could possibly be? I've been fighting with this for days. In addition: does there exist some way of finding out why a typemap is never used, or why one typemap is chosen over another? Thanks ever so much in advance for your help, James 
From: Karl Wette <karl.wette@gm...>  20111007 13:24:10

Hi James, If your SWIG is relatively new (I think the 2.0.* series), you can use these options to debug which typemaps SWIG is using: debugtypemap  Display typemap debugging information debugtmsearch  Display typemap search debugging information debugtmused  Display typemaps used debugging information For the example you give, I think something like this should convert an Octave matrix into a double*: %typemap(in) (double*, int, int) (Matrix mat) { mat = $input.matrix_value(); $1 = malloc($2 * $3 * sizeof(double)); for (int i = 0; i < $2; i++) { for (int j = 0; j < $3; j++) { $1[i*$3 + j] = mat(i,j); } } } where the first "int" is number of rows, second "int" is number of columns. I've haven't actually tested the above code, so it's probably got bugs in it, but hopefully this gives you an idea. For the "out" typemap, you would do the reverse i.e. copy the contents of the double* to a Matrix, then return the result as: $result = octave_value(mat); Hope this helps, Cheers, Karl On 7 October 2011 06:10, James Avery <avery@...> wrote: > Hi all, > > I'm writing code that implements time critical parts of a large octave > program in C++. The SWIG wrappers work very well, except for the most > important aspect when interfacing with Octave: passing vectors and > matrices back and forth over the SWIG interface. For some reason, no > matter what I do, SWIG will ignore any typemaps I come up with. > > The SWIG+Octave documentation has stated the following ever since version 1.3: > > "29.3.17 Matrix typemaps > > Octave provides a rich set of classes for dealing with matrices. > Currently there are no builtin typemaps to deal with those. However, > these are relatively straight forward for users to add themselves (see > the docs on typemaps). Without much work (a single typemap decl say, > 5 lines of code in the interface file), it would be possible to have a > function > > double my_det(const double* mat,int m,int n); > that is accessed from Octave as, > > octave:1> my_det(rand(4)); > ans = 0.18388" > > Can anyone with a better understanding of how SWIG and Octave interact > shed some light on what those 5 lines of code could possibly be? I've > been fighting with this for days. In addition: does there exist some > way of finding out why a typemap is never used, or why one typemap is > chosen over another? > > Thanks ever so much in advance for your help, > > James > >  > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunkd2dcopy2 > _______________________________________________ > Swiguser mailing list > Swiguser@... > https://lists.sourceforge.net/lists/listinfo/swiguser > 
From: James Avery <avery@di...>  20111009 02:40:25

Hi Karl, thanks very much for your reply! > If your SWIG is relatively new (I think the 2.0.* series), you can use > these options to debug which typemaps SWIG is using: Thanks very much. I've now installed the latest SWIG, and the debug options are tremendously useful! > For the example you give, I think something like this should convert > an Octave matrix into a double*: Thanks a lot. It looks quite close to what I concocted (in many, many variations) myself, yet seemed to partially do the trick. However, I'm still having some (for me) hard to understand problems with this, which seem to be the root of my problem. I'm now trying to use the following typemap (which, once it works, I have to template to allow std::complex<double> and various integer type matrices): %typemap(in) (const double *v, unsigned int n) { const octave_value mat_feat=$input; if (!mat_feat.is_matrix_type()  !mat_feat.is_double_type()  mat_feat.rows()!=1) SWIG_fail; const Array<double>& m(mat_feat.vector_value()); $1 = (double*)m.fortran_vec(); $2 = mat_feat.columns(); } %typemap(typecheck, precedence=SWIG_TYPECHECK_POINTER) (const double *v, unsigned int n) { const octave_value& m($input); $1 = (m.is_matrix_type() && m.is_double_type() && m.rows()==1) ? 1 : 0; } But for some reason, it works in some cases but not in others. I mainly need it in order to wrap the input for the second constructor in the following class: template <typename Space> class gridfunction : public std::vector<typename Space::value_t> { public: typedef typename Space::value_t value_t; typedef typename Space::scalar_t scalar_t; gridfunction operator + (const gridfunction& g) const; gridfunction operator  (const gridfunction& g) const; gridfunction operator * (const gridfunction& g) const; gridfunction operator * (const scalar_t& g) const; gridfunction(const Space& space) : std::vector<value_t>(space.Nx) { fprintf(stderr,"constructor gridfunction(space)\n"); } gridfunction(const value_t *v, unsigned int n) : std::vector<value_t>(v,v+n) { fprintf(stderr,"constructor gridfunction(pointer) : size(%d)\n",this>size()); } std::vector<value_t> get_data() const { return std::vector<value_t>(this>begin(),this>end()); } }; As it stands, SWIG cannot find my typemap (when instantiating such that value_t = double) no matter what I do. However, if I brutally change the constructor prototype to gridfunction(const double *v, unsigned int n) it magically works, and SWIG finds the typemap like so: grid1d/grid1d.hh:31: Searching for a suitable 'in' typemap for: double const *v Looking for: double const *v Looking for: double const * Looking for: double *v Looking for: double * Looking for: SWIGTYPE const *v Looking for: SWIGTYPE const * Looking for: SWIGTYPE *v Looking for: SWIGTYPE * Multiargument typemap found... Using: %typemap(in) (double const *v,unsigned int n) and everything works beautifully for the doubletype Octave arrays. However, I can't actually do this, since it prevents the class from compiling with other value types. Usually, SWIG doesn't mind typedefs, and in fact, it does translate the value_t type correctly. But for some reason, this stops it from finding the typemap. The failed search looks like this: grid1d/grid1d.hh:31: Searching for a suitable 'in' typemap for: gridfunction< Grid1D< double > >::value_t const *v Looking for: gridfunction< Grid1D< double > >::value_t const *v Looking for: gridfunction< Grid1D< double > >::value_t const * Looking for: gridfunction const *v Looking for: gridfunction const * Looking for: gridfunction< Grid1D< double > >::value_t *v Looking for: gridfunction< Grid1D< double > >::value_t * Looking for: gridfunction *v Looking for: gridfunction * Looking for: Grid1D< double >::value_t const *v Looking for: Grid1D< double >::value_t const * Looking for: Grid1D const *v Looking for: Grid1D const * Looking for: Grid1D< double >::value_t *v Looking for: Grid1D< double >::value_t * Looking for: Grid1D *v Looking for: Grid1D * Looking for: double const *v Looking for: double const * Looking for: double *v Looking for: double * Looking for: SWIGTYPE const *v Looking for: SWIGTYPE const * Looking for: SWIGTYPE *v Looking for: SWIGTYPE * Using: %typemap(in) SWIGTYPE * I have a hard time understanding why the typemap can't be found in the second case, since it correctly reduces the prototype to 'double const *v', like in the first case. But why, then, does it not from there reach the same result? Sorry for the very long post, but I hope you (or someone else) will be able to help. I seem to be too inexperienced with SWIG's typemap system to crack this myself. With very best regards, James  Med venlig hilsen, James Avery <avery@...> 
From: Soeren Sonnenburg <sonne@de...>  20111013 22:39:36
Attachments:
signature.asc

On Sun, 20111009 at 15:39 +1300, James Avery wrote: > Hi Karl, thanks very much for your reply! Hi James, maybe https://github.com/shoguntoolbox/shogun/blob/master/src/interfaces/octave_modular/swig_typemaps.i is of help to you. Soeren > > If your SWIG is relatively new (I think the 2.0.* series), you can use > > these options to debug which typemaps SWIG is using: > > Thanks very much. I've now installed the latest SWIG, and the debug > options are tremendously useful! > > > For the example you give, I think something like this should convert > > an Octave matrix into a double*: > > Thanks a lot. It looks quite close to what I concocted (in many, many > variations) myself, yet seemed to partially do the trick. However, I'm > still having some (for me) hard to understand problems with this, > which seem to be the root of my problem. I'm now trying to use the > following typemap (which, once it works, I have to template to allow > std::complex<double> and various integer type matrices): > > %typemap(in) (const double *v, unsigned int n) > { > const octave_value mat_feat=$input; > if (!mat_feat.is_matrix_type()  !mat_feat.is_double_type()  > mat_feat.rows()!=1) > SWIG_fail; > > const Array<double>& m(mat_feat.vector_value()); > $1 = (double*)m.fortran_vec(); > $2 = mat_feat.columns(); > } > > %typemap(typecheck, precedence=SWIG_TYPECHECK_POINTER) > (const double *v, unsigned int n) > { > const octave_value& m($input); > > $1 = (m.is_matrix_type() && m.is_double_type() && m.rows()==1) ? 1 : 0; > } > > But for some reason, it works in some cases but not in others. I > mainly need it in order to wrap the input for the second > constructor in the following class: > > template <typename Space> > class gridfunction : public std::vector<typename Space::value_t> { > public: > typedef typename Space::value_t value_t; > typedef typename Space::scalar_t scalar_t; > > gridfunction operator + (const gridfunction& g) const; > gridfunction operator  (const gridfunction& g) const; > gridfunction operator * (const gridfunction& g) const; > gridfunction operator * (const scalar_t& g) const; > > gridfunction(const Space& space) : std::vector<value_t>(space.Nx) { > fprintf(stderr,"constructor gridfunction(space)\n"); > } > > gridfunction(const value_t *v, unsigned int n) : > std::vector<value_t>(v,v+n) { > fprintf(stderr,"constructor gridfunction(pointer) : > size(%d)\n",this>size()); > } > > std::vector<value_t> get_data() const { > return std::vector<value_t>(this>begin(),this>end()); > } > }; > > As it stands, SWIG cannot find my typemap (when instantiating such > that value_t = double) no matter what I do. However, if I brutally > change the constructor prototype to > > gridfunction(const double *v, unsigned int n) > > it magically works, and SWIG finds the typemap like so: > > grid1d/grid1d.hh:31: Searching for a suitable 'in' typemap for: double const *v > Looking for: double const *v > Looking for: double const * > Looking for: double *v > Looking for: double * > Looking for: SWIGTYPE const *v > Looking for: SWIGTYPE const * > Looking for: SWIGTYPE *v > Looking for: SWIGTYPE * > Multiargument typemap found... > Using: %typemap(in) (double const *v,unsigned int n) > > and everything works beautifully for the doubletype Octave > arrays. However, I can't actually do this, since it prevents the class > from compiling with other value types. Usually, SWIG doesn't mind > typedefs, and in fact, it does translate the value_t type > correctly. But for some reason, this stops it from finding the > typemap. The failed search looks like this: > > grid1d/grid1d.hh:31: Searching for a suitable 'in' typemap for: > gridfunction< Grid1D< double > >::value_t const *v > Looking for: gridfunction< Grid1D< double > >::value_t const *v > Looking for: gridfunction< Grid1D< double > >::value_t const * > Looking for: gridfunction const *v > Looking for: gridfunction const * > Looking for: gridfunction< Grid1D< double > >::value_t *v > Looking for: gridfunction< Grid1D< double > >::value_t * > Looking for: gridfunction *v > Looking for: gridfunction * > Looking for: Grid1D< double >::value_t const *v > Looking for: Grid1D< double >::value_t const * > Looking for: Grid1D const *v > Looking for: Grid1D const * > Looking for: Grid1D< double >::value_t *v > Looking for: Grid1D< double >::value_t * > Looking for: Grid1D *v > Looking for: Grid1D * > Looking for: double const *v > Looking for: double const * > Looking for: double *v > Looking for: double * > Looking for: SWIGTYPE const *v > Looking for: SWIGTYPE const * > Looking for: SWIGTYPE *v > Looking for: SWIGTYPE * > Using: %typemap(in) SWIGTYPE * > > I have a hard time understanding why the typemap can't be found in the > second case, since it correctly reduces the prototype to 'double const > *v', like in the first case. But why, then, does it not from there > reach the same result? > > Sorry for the very long post, but I hope you (or someone else) will be > able to help. I seem to be too inexperienced with SWIG's typemap > system to crack this myself. > > With very best regards, > James > >  For the one fact about the future of which we can be certain is that it will be utterly fantastic.  Arthur C. Clarke, 1962 
From: James Avery <avery@di...>  20111016 03:45:14

On Fri, Oct 14, 2011 at 11:39 AM, Soeren Sonnenburg <sonne@...> wrote: > On Sun, 20111009 at 15:39 +1300, James Avery wrote: >> Hi Karl, thanks very much for your reply! > > Hi James, > > maybe > > https://github.com/shoguntoolbox/shogun/blob/master/src/interfaces/octave_modular/swig_typemaps.i > > is of help to you. Thanks, Søren! That's an incredibly helpful file. It doesn't seem to help with my problem of getting SWIG to locate the typemaps (the problem appears to be non Octaverelated, but a general problem to do with typedefs in templates, so I'll submit it as a separate question). But the Shogun typemaps are certainly going to be extremely helpful for making all the types work. Thanks for the pointer! Also, the Shogun project itself looks very interesting.  Med venlig hilsen, James Avery <avery@...> 
Sign up for the SourceForge newsletter:
No, thanks