Re: [Rcpp-devel] Using complex numbers and functions in Rcpp

[Baptiste Auguie]

Hi,

I think you can/should use std::complex, see for example the types used in

https://github.com/baptiste/rcppfaddeeva/blob/master/src/callFaddeeva.cpp

In general I prefer to work with RcppArmadillo for numerical (including
complex) computations, its syntax closely follows R and Matlab. See for
instance

https://github.com/baptiste/cda/blob/master/src/cda.cpp
https://github.com/baptiste/planar/blob/master/src/fresnel.cpp

for some examples.

HTH,

baptiste



On 22 February 2017 at 04:46, Martin S Ridout  wrote:

> Apologies if this is a naive  question - I'm a beginner with Rcpp.  I did
> see some earlier discussion on similar topic, but I don't think it answered
> my questions.
>
> I am trying (on Windows) to speed up a function currently written in R.
> This works very well for real-valued arguments of the function. But it
> needs to work for complex arguments as well. Here is a stripped down (but
> still non-working) example of what I am trying to do
>
> cppFunction('
>   ComplexVector test(ComplexVector s, ComplexVector lambda) {
>
> int n = s.size();
> int m = lambda.size();
> ComplexVector out(n);
>
> for (int i=0; i < n; ++i) {
>   for (int j=0; j < m; ++j) {
>  out[i] = out[i] - log(s[i] + 1/lambda[j]) / 2;
>   }
> }
> return out;
>   }
> ')
>
> I have (at least) 2 problems
>
> i) Are the logarithm and exponential functions implemented for complex
> arguments? If not is there a work-around?
>
> ii) What is the best way to specify constants like 1 and 2  as complex
> constants? This must be easy, but everything I tried so far gives an
> error (except passing them into the function via an extra ComplexVector
> argument, but there must be a better way).
>
> Many thanks for any help,
> Martin Ridout
>
>
>
> ___
> Rcpp-devel mailing list
> Rcpp-devel@lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Parallel R::bessel_k function in Rcpp

[Baptiste Auguie]

Hi,

Check also the Bessel package from Martin M.,
https://cran.r-project.org/web/packages/Bessel/index.html
It wraps some C code; maybe a C++ interface wouldn't be too hard to write.
There's also the GSL package apparently.

Cheers,

baptiste

On 24 March 2016 at 13:20, Hoang Nguyen  wrote:

> Thank Dirk,
> I check Boost and they only have the Modified Bessel Functions of the
> First and Second Kinds. I have to read more to find how to derive the third
> kind.
> Best regards.
>
> On Thu, Mar 24, 2016 at 1:17 AM, Dirk Eddelbuettel  wrote:
>
>>
>> PS Looks like Boost has Bessel functions:
>>
>>
>> http://www.boost.org/doc/libs/1_60_0/libs/math/doc/html/math_toolkit/bessel/bessel_over.html
>>
>> So maybe try that.  We should have access to that in the BH package.
>>
>> Dirk
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>>
>
>
> ___
> Rcpp-devel mailing list
> Rcpp-devel@lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] lighter source package

[Baptiste Auguie]

On 1 March 2016 at 04:21, Dirk Eddelbuettel <e...@debian.org> wrote:

>
> On 29 February 2016 at 09:48, Simon Urbanek wrote:
> |
> |
> | > On Feb 28, 2016, at 2:59 PM, Kevin Ushey <kevinus...@gmail.com> wrote:
> | >
> | > What about having a 'configure' script that generates this header file
> | > on package install?
> | >
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup
> | >
> |
> | You don't even need that - it's much easier to simply add a rule to
> Makevars along the lines of:
> |
> | foo.h: foo.bz2.h
> |   ${R_BZIPCMD} -d foo.bz2.h
>
> I think you want foo.h.bz2 in both places.
>
> Dirk
>
> Thanks both, I like the simplicity of it. And sorry the link is now dead
since I removed the file from the repo (
https://github.com/baptiste/planar/blob/8c2000c39307d991f1ed237b02f09472fd5e268f/src/clencurt.h).
Running bzip2 -z clencurt.h brings it down from 40Mb to 14Mb, which is an
improvement.
I'm sure I'll use this tip in the future, thanks!

baptiste



> |
> | assuming that compression is enough (the referred file doesn't exist in
> the sources ...)
> |
> | Cheers,
> | Simon
> |
> |
> |
> | > On Sun, Feb 28, 2016 at 11:18 AM, Baptiste Auguie
> | > <baptiste.aug...@gmail.com> wrote:
> | >> Dear Rcpp gurus,
> | >>
> | >> In the process of updating my planar package
> | >> <https://github.com/baptiste/planar>, CRAN has mentioned their
> concern with
> | >> the size of the source package (20Mb compressed tar.gz). This puzzled
> me
> | >> until I found the culprit: a 40Mb header file
> | >> <https://github.com/baptiste/planar/blob/master/src/clencurt.h> with
> 500k
> | >> pre-calculated quadrature points.
> | >> I'm thinking that the easiest strategy is probably to compress these
> data
> | >> into binary form, say as a Rdata file in inst/, and have the Makefile
> do
> | >> some magic to recover it during the package compilation. I'm not sure
> how to
> | >> achieve this, or if it even makes sense. Any example of a similar
> procedure
> | >> I could follow?
> | >>
> | >> Thanks,
> | >>
> | >> baptiste
> | >>
> | >> ___
> | >> Rcpp-devel mailing list
> | >> Rcpp-devel@lists.r-forge.r-project.org
> | >>
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
> | > ___
> | > Rcpp-devel mailing list
> | > Rcpp-devel@lists.r-forge.r-project.org
> | >
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
> | >
> |
> | ___
> | Rcpp-devel mailing list
> | Rcpp-devel@lists.r-forge.r-project.org
> | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> ___
> Rcpp-devel mailing list
> Rcpp-devel@lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] lighter source package

[Baptiste Auguie]

Thanks Kevin. Indeed, something along those lines should be the way to go,
though I wouldn't really know how to adapt the example to load a Rdata
file, export a text file, move it to src/ and clean up.
Fortunately, after having a closer look at this header file, it looks like
I'm not currently using it (the Clenshaw-Curtis quadrature is an
alternative option provided by S. Johnson's cubature library, but I'm
actually using the other routine). So I can get rid of it altogether for
now, and my package falls below 1Mb.

Thanks for the tip anyway,

baptiste



On 29 February 2016 at 08:59, Kevin Ushey <kevinus...@gmail.com> wrote:

> What about having a 'configure' script that generates this header file
> on package install?
>
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup
>
> On Sun, Feb 28, 2016 at 11:18 AM, Baptiste Auguie
> <baptiste.aug...@gmail.com> wrote:
> > Dear Rcpp gurus,
> >
> > In the process of updating my planar package
> > <https://github.com/baptiste/planar>, CRAN has mentioned their concern
> with
> > the size of the source package (20Mb compressed tar.gz). This puzzled me
> > until I found the culprit: a 40Mb header file
> > <https://github.com/baptiste/planar/blob/master/src/clencurt.h> with
> 500k
> > pre-calculated quadrature points.
> > I'm thinking that the easiest strategy is probably to compress these data
> > into binary form, say as a Rdata file in inst/, and have the Makefile do
> > some magic to recover it during the package compilation. I'm not sure
> how to
> > achieve this, or if it even makes sense. Any example of a similar
> procedure
> > I could follow?
> >
> > Thanks,
> >
> > baptiste
> >
> > ___
> > Rcpp-devel mailing list
> > Rcpp-devel@lists.r-forge.r-project.org
> > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[Rcpp-devel] lighter source package

[Baptiste Auguie]

Dear Rcpp gurus,

In the process of updating my planar package <
https://github.com/baptiste/planar>, CRAN has mentioned their concern with
the size of the source package (20Mb compressed tar.gz). This puzzled me
until I found the culprit: a 40Mb header file <
https://github.com/baptiste/planar/blob/master/src/clencurt.h> with 500k
pre-calculated quadrature points.
I'm thinking that the easiest strategy is probably to compress these data
into binary form, say as a Rdata file in inst/, and have the Makefile do
some magic to recover it during the package compilation. I'm not sure how
to achieve this, or if it even makes sense. Any example of a similar
procedure I could follow?

Thanks,

baptiste
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Using complex numbers in a C program called by R

[Baptiste Auguie]

On 4 January 2016 at 21:14, Pierre Lafaye de Micheaux <
laf...@dms.umontreal.ca> wrote:

> Dear all,
>
> Thanks again for your answers.
>
> For one of my project, I indeed need the special complex error functions.
> This is why I used the RcppFaddeeva source files in the first time.
>

That's useful to know. In that case, I believe something could be done but
I'd need some help from Dirk to make sure the package export the right
things.
https://github.com/baptiste/rcppfaddeeva/pull/2#issuecomment-109682706


> This being said, it was ALSO a workaround to get access to complex numbers
> operations (and so that the package compile under Windows
> without errors).
>

This workaround is clearly suboptimal and needs to be sorted first IMHO.
I'm guessing that's a magic side-effect of the Rcpp.h include in one of the
files.


> I know that using .C() is now discouraged by R core group. This being
> said, I am a bit reluctant, at least for some projects, to use .Call().
> I like the idea to be able to use old FORTRAN77 codes and/or C codes
> written by others. Usually, using these codes is quite straightforward
> thanks to the .Fortran() interface. As for the C codes, it is only
> necessary to modify the arguments of the C function to make them pointers in
> order to then call it through the .C() function.
>
> My understanding, but maybe I am not good enough, is that to be able to
> call a C/C++ function using .Call() and/or involving Rcpp needs
> a lot more modifications to the original C source file.
>

If you look at RcppFaddeeva, you'll find that the original C+ library is
pretty much untouched, and the c++ wrappers are quite minimal. And with
Rcpp attributes, you don't even have to write R wrappers.

I think this is bad for reproducibility. For example, if one would like to
> call this same C code from Matlab and if this C code is full of Rcpp, then
> I guess there will be some trouble. Am I right?


> Note that I "learned" a bit of Rcpp. I am the author and maintainer of
> package PoweR:
> https://cran.r-project.org/web/packages/PoweR/index.html
> I wrote in this package the file calcpuissRcpp.cpp that contains some Rcpp
> features (maybe you can have a quick look to see my low? level
> of knowledge of Rcpp). And I agree that this is cool stuff when you want
> to be able to access high level
> R functions from C. But as said above, you loose some reproducibility (in
> the sense explained above) and maybe also some speed (and this is why I
> have two "parallel" versions in my PoweR package: calcpuiss.cpp and
> calcpuissRcpp.cpp).
>
> So, with all this in mind, my "request" is still the same. Namely being
> able to manipulate (and create) complex numbers at the (pure) C level in an
> R package so that it could compile properly (without errors) under
> Microsoft Windows. I found this workaround by copying these RcppFaddeeva
> source files
> (.cpp and .h files) in the src/ directory of my package(s) but this is not
> really clean. Probably I could try to remove all "unnecessary" stuff from
> these source
> files in order to keep only what is really needed to play with complex
> numbers at the (pure) C level, but maybe there would be something more
> clever to do? Like adding RcppFaddeeva to the LinkingTo/Depends/Export
> fields?


I believe this step (to use some of Faddeeva's functions) needs some work
in RcppFaddeeva, which I'd be happy to discuss with you and hopefully Dirk,
but that's a different issue altogether.

Or creating a very simple package (by removing all special complex error
> functions from RcppFaddeeva)


Sounds like a good idea to me. And if you put it on github, say, people
could look at it if you get stuck. As I remember, Dirk fixed my
RcppFaddeeva package faster than I was committing to it.

HTH,

baptiste

and call the resulting package EnableC and then add this to
> LinkingTo/Depends/Export fields?


> I hope I made myself clear ...
>
> Thank you again for your time.
>
> Best regards,
>
> Pierre L.
>
>

> Le 03/01/2016 22:14, Dirk Eddelbuettel a écrit :
>
>> On 4 January 2016 at 09:50, Baptiste Auguie wrote:
>> | Hi,
>> |
>> | Just to clarify: did you include files from RcppFaddeeva because you
>> need some
>> | of its functionality (special complex error functions), or was it only a
>> | workaround to get access to complex numbers? In the latter case, I
>> recommend
>> | you try making a minimal Rcpp package to see how easy it is to
>> interface with
>> | C++ functions, and that way you will only have relevant header files
>> included.
>>
>> +1
>>
>> I already responded to Pierre's initial emails in November and tried then
>> to
>> explain to him that 

Re: [Rcpp-devel] Using complex numbers in a C program called by R

[Baptiste Auguie]

Hi,

Just to clarify: did you include files from RcppFaddeeva because you need
some of its functionality (special complex error functions), or was it only
a workaround to get access to complex numbers? In the latter case, I
recommend you try making a minimal Rcpp package to see how easy it is to
interface with C+ functions, and that way you will only have relevant
header files included.

Best,

baptiste



On 4 January 2016 at 09:36, Pierre Lafaye de Micheaux <
laf...@dms.umontreal.ca> wrote:

> Dear all,
>
> This email comes after a discussion on the R-pkg-devel mailing list:
> https://stat.ethz.ch/pipermail/r-package-devel/2016q1/000627.html
>
> My purpose was to be able, in two of my packages, to use complex numbers
> (create some, addition, multiplication, division, modulus, etc)
> directly in a C code that is called from R (using the .C interface).
> Note that these complex numbers might not come from R but could be created
> and used directly in my C code, that will then output (via pointers)
> real (I mean double) values back to R (via the .C interface). I could also
> send from R these complex numbers via the .C interface.
>
> A very simple example of such a function called from R via the .C
> interface could be the following:
>
> #include 
> #include "Rmath.h"
> extern "C" {
> void Cfunc(complex double *var) {
> double _Complex z = 1.0 + 2.0 * _Complex_I;
> var[0] = z + exp(var[0]);
> return;
> }}
>
> I could call this function from R as follows:
> .C(1i)
>
> No problem so far when I use such a function in a package that is compiled
> under Linux. But this will not work under windows (see the discussion
> on the R-pkg-devel list). So what I did to make everything work under
> Windows also was to include in the src/ directory of my package the source
> files
> from the RcppFaddeeva package. Then I would modify the function above as
> follows:
>
> #include 
> #include "Rmath.h"
> #include "libraries/callFaddeeva.cpp"
> #include "libraries/Faddeeva.cpp"
> #include "libraries/RcppExports.cpp"
> extern "C" {
> void Cfunc(complex double *var) {
> cmplx z = C(1.0, 2.0);
> var[0] = z + cexp(var[0]);
> return;
> }}
>
> Maybe there is a way not to include all the Faddeeva source files in my
> packages? But I do not know how to do it.
>
> Best regards,
>
> Pierre L.
>
>
>
> --
> Pierre Lafaye de Micheaux
>
> Adresse courrier:
> Université de Montréal
> Pavillon André-Aisenstadt
> Département de Mathématiques et Statistique
> CP 6128 Succursale Centre-ville
> Montréal Qc H3C 3J7
> CANADA
>
> Adresse physique:
> Département de Mathématiques et Statistique
> Bureau 4249, Pavillon André-Aisenstadt
> 2920, chemin de la Tour
> Montréal, Québec H3T 1J4
> CANADA
>
> Tél.: (00-1) 514-343-6607 / Fax: (00-1) 514-343-5700
> laf...@dms.umontreal.ca
> http://www.biostatisticien.eu
>
> ___
> Rcpp-devel mailing list
> Rcpp-devel@lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] RcppArmadillo, solve always requires zgels?

[Baptiste Auguie]

Hi,

Thanks Dirk for your suggestions. Let me try to clarify a few things below.
Basically,

- zgels should not be needed (probably, and if I was doing things correctly)

- I believe the template mechanism is simply unaware of the square format
of my matrix, and defaults to the nrow  ncol case for lack of better
knowledge. I do not know how to specify that the matrix is square, it's
passed on from another function, i.e.

https://github.com/baptiste/cda/blob/master/src/cd.cpp#L49
is using A from
https://github.com/baptiste/cda/blob/master/src/cda.cpp#L129

The way I picture it, I need to give a hint of the square size, and
armadillo will pick the right function/template/glue (I don't know the
mechanism at play).

On 1 June 2015 at 01:12, Dirk Eddelbuettel e...@debian.org wrote:


 Hi Baptiste,

 On 31 May 2015 at 20:47, Baptiste Auguie wrote:
 | Dear list,
 |
 | My cda package (https://github.com/baptiste/cda) solves a linear system
 Ax=b
 | with Armadillo; win-builder and CRAN complain about a missing zgels_
 when
 | trying to build on windows or mac, as it's not part of the subset of
 LAPACK
 | provided by R libraries (I asked about this in 2011). I have included a
 copy of

 Right. When no system lapack/blas is found, R uses its own. Which is a
 subset.  We were bitten that once and now check in configure for
 availability
 of zgesdd.  I suppose this case is similar.

 Look at the logic in

   https://github.com/RcppCore/RcppArmadillo/blob/master/configure

 You may need to do something similar for zgels.  So this part of the
 problem
 (do we have zgels ?) really may be part of which type of R installation
 do
 we have.

 Worst case we need new branching / #ifdef logic --- but right now I think
 maybe more at the level of your package then at RcppArmadillo.


The easiest workaround, I find, is to include zgels.f, as I've been doing
since 2011. Now, my premise here is that this function is not needed in my
package.


 | this file (zgels.f) from Netlib for the past few years just to make the
 problem
 | go away, but I've recently realised that zgels is not supposed to be
 called! It
 | builds fine on Linux, or any machine with a full LAPACK installed, but
 I'm now
 | wondering if solve() always calls zgels (that would be inefficient for my
 | use-case).

 From the top-level, when I just use ag (a fantastic and much faster grep
 alternative; and mail will drop the ansi code for colour highlihting from
 the
 console)


Yes, I've tried to look at where zgels is called in the original Armadillo;
it's not crystal clear (for me) with the templates and glue etc.


 edd@max:~/git/rcpparmadillo(master)$ ag zgels
 inst/include/armadillo_bits/lapack_bones.hpp
 97:  #define arma_zgels  zgels
 205:  #define arma_zgels  ZGELS
 340:  void arma_fortran(arma_zgels)(char* trans, blas_int* m, blas_int* n,
 blas_int* nrhs, void*   a, blas_int* lda, void*   b, blas_int* ldb, void*
  work, blas_int* lwork, blas_int* info);

 inst/include/armadillo_bits/lapack_wrapper.hpp
 689:  arma_fortran(arma_zgels)(trans, m, n, nrhs, (T*)a, lda, (T*)b,
 ldb, (T*)work, lwork, info);
 edd@max:~/git/rcpparmadillo(master)$

 I think you should discuss the merits of what gets called with Conrad.


Looking at the code and docs, the intent for square matrices is probably
not to use zgels. I believe my code is simply failing to give enough hints
for the templates to work out which case is actually being required.


 | The matrix A is square: the system is not under/overdetermined, and I
 believe
 | Armadillo should select LU factorisation rather than (slower) QR. Here's
 the

 It is hard to answer this in full generality --- and even harder to change
 an
 existing API.

 If Armadillo has been using QR here for years, we cannot really change this
 now on the request of a single package.


 | error I get from win-builder when I remove zgels.f from my cda package,
 |
 | cd.o:cd.cpp:
 |
 (.text$_ZN4arma6auxlib8solve_udISt7complexIdENS_3MatIS3_bRNS4_IT_EES8_RKNS_4BaseIS6_T0_EE
 | [bool arma::auxlib::solve_udstd::complexdouble, arma::Matstd::complex
 | double  (arma::Matstd::complexdouble ,
 arma::Matstd::complexdouble
 | , arma::Basestd::complexdouble, arma::Matstd::complexdouble  
 const
 | )]+0x3a5): undefined reference to `zgels_'
 |
 | So it thinks it should call solve_ud, which is meant for under-determined
 | systems. Why would that be?
 | I tried to find the relevant piece in the template code, this looks
 relevant
 | but I don't understand it:
 https://github.com/RcppCore/RcppArmadillo/blob/
 | master/inst/include/armadillo_bits/glue_solve_meat.hpp#L26

 Well that seems to be the call in the 'rows  cols' case.


I linked to the case which is returned in the win-builder log; the case of
a square matrix would be a few lines earlier (note that the solve_ud case
is the default, if previous conditions fail to apply).



 But if there is a function solve_ud, can you not just call solve_ud
 from your package?


That would be auxlib::solve(out

Re: [Rcpp-devel] RcppArmadillo, solve always requires zgels?

[Baptiste Auguie]

Hi,

I attach a minimal sourceCpp file:

Rcpp::sourceCpp('testzgels.cpp')

provides extra debugging info, and shows my complete lack of understanding
of c++ templates. It would appear that upon compilation, all cases (nrow ==
ncol, nrow  ncol, nrow  ncol) are considered (of course: the matrix A has
no size information for the compiler). The size check is only performed
when calling the function, and dispatches to the correct LAPACK routine
(gels vs gesv).

Now, unfortunately this example does not help me solve a more specialised
case, where **I know** only square matrices will be passed. I do not need
the various possible routines, which in fact won't be all available within
R's subset of LAPACK.
zgels is assumed to be required (by CRAN and win-builder), presumably
because the templates cater for all possible cases and the code-checking
just looks up the list of symbol names, although in actuality it would
never be used. Does that make sense? How could I specialise the code to
restrict solve to square systems?

Thanks,

baptiste






On 1 June 2015 at 10:13, Dirk Eddelbuettel e...@debian.org wrote:


 On 1 June 2015 at 09:06, Baptiste Auguie wrote:
 | Hi,
 |
 | Thanks Dirk for your suggestions. Let me try to clarify a few things
 below.
 | Basically,
 |
 | - zgels should not be needed (probably, and if I was doing things
 correctly)
 |
 | - I believe the template mechanism is simply unaware of the square
 format of my
 | matrix, and defaults to the nrow  ncol case for lack of better
 knowledge. I do

 Per this line


 https://github.com/RcppCore/RcppArmadillo/blob/master/inst/include/armadillo_bits/glue_solve_meat.hpp#L26

 I somehow have my doubts.

 | not know how to specify that the matrix is square, it's passed on from
 another
 | function, i.e.
 |
 | https://github.com/baptiste/cda/blob/master/src/cd.cpp#L49
 | is using A from
 | https://github.com/baptiste/cda/blob/master/src/cda.cpp#L129
 |
 | The way I picture it, I need to give a hint of the square size, and
 armadillo
 | will pick the right function/template/glue (I don't know the mechanism at
 | play).

 Can you minimize the problem?  Minimally reproducible example which still
 gets to zgels when maybe it shouldn't?

 Dirk

 |
 | On 1 June 2015 at 01:12, Dirk Eddelbuettel e...@debian.org wrote:
 |
 |
 | Hi Baptiste,
 |
 | On 31 May 2015 at 20:47, Baptiste Auguie wrote:
 | | Dear list,
 | |
 | | My cda package (https://github.com/baptiste/cda) solves a linear
 system
 | Ax=b
 | | with Armadillo; win-builder and CRAN complain about a missing
 zgels_
 | when
 | | trying to build on windows or mac, as it's not part of the subset
 of
 | LAPACK
 | | provided by R libraries (I asked about this in 2011). I have
 included a
 | copy of
 |
 | Right. When no system lapack/blas is found, R uses its own. Which is
 a
 | subset.  We were bitten that once and now check in configure for
 | availability
 | of zgesdd.  I suppose this case is similar.
 |
 | Look at the logic in
 |
 |   https://github.com/RcppCore/RcppArmadillo/blob/master/configure
 |
 | You may need to do something similar for zgels.  So this part of the
 | problem
 | (do we have zgels ?) really may be part of which type of R
 installation
 | do
 | we have.
 |
 | Worst case we need new branching / #ifdef logic --- but right now I
 think
 | maybe more at the level of your package then at RcppArmadillo.
 |
 |
 |
 | The easiest workaround, I find, is to include zgels.f, as I've been
 doing since
 | 2011. Now, my premise here is that this function is not needed in my
 package.
 |
 |
 | | this file (zgels.f) from Netlib for the past few years just to
 make the
 | problem
 | | go away, but I've recently realised that zgels is not supposed to
 be
 | called! It
 | | builds fine on Linux, or any machine with a full LAPACK installed,
 but
 | I'm now
 | | wondering if solve() always calls zgels (that would be inefficient
 for my
 | | use-case).
 |
 | From the top-level, when I just use ag (a fantastic and much faster
 grep
 | alternative; and mail will drop the ansi code for colour highlihting
 from
 | the
 | console)
 |
 |
 | Yes, I've tried to look at where zgels is called in the original
 Armadillo;
 | it's not crystal clear (for me) with the templates and glue etc.
 |
 |
 | edd@max:~/git/rcpparmadillo(master)$ ag zgels
 | inst/include/armadillo_bits/lapack_bones.hpp
 | 97:  #define arma_zgels  zgels
 | 205:  #define arma_zgels  ZGELS
 | 340:  void arma_fortran(arma_zgels)(char* trans, blas_int* m,
 blas_int* n,
 | blas_int* nrhs, void*   a, blas_int* lda, void*   b, blas_int* ldb,
 void*
 |  work, blas_int* lwork, blas_int* info);
 |
 | inst/include/armadillo_bits/lapack_wrapper.hpp
 | 689:  arma_fortran(arma_zgels)(trans, m, n, nrhs, (T*)a, lda,
 (T*)b,
 | ldb, (T*)work, lwork, info);
 | edd@max:~/git

[Rcpp-devel] RcppArmadillo, solve always requires zgels?

[Baptiste Auguie]

Dear list,

My cda package (https://github.com/baptiste/cda) solves a linear system
Ax=b with Armadillo; win-builder and CRAN complain about a missing zgels_
when trying to build on windows or mac, as it's not part of the subset of
LAPACK provided by R libraries (I asked about this in 2011). I have
included a copy of this file (zgels.f) from Netlib for the past few years
just to make the problem go away, but I've recently realised that zgels is
not supposed to be called! It builds fine on Linux, or any machine with a
full LAPACK installed, but I'm now wondering if solve() always calls zgels
(that would be inefficient for my use-case).
The matrix A is square: the system is not under/overdetermined, and I
believe Armadillo should select LU factorisation rather than (slower) QR.
Here's the error I get from win-builder when I remove zgels.f from my cda
package,

cd.o:cd.cpp:(.text$_ZN4arma6auxlib8solve_udISt7complexIdENS_3MatIS3_bRNS4_IT_EES8_RKNS_4BaseIS6_T0_EE[bool
arma::auxlib::solve_udstd::complexdouble, arma::Matstd::complexdouble
 (arma::Matstd::complexdouble , arma::Matstd::complexdouble ,
arma::Basestd::complexdouble, arma::Matstd::complexdouble  
const)]+0x3a5): undefined reference to `zgels_'

So it thinks it should call solve_ud, which is meant for under-determined
systems. Why would that be?
I tried to find the relevant piece in the template code, this looks
relevant but I don't understand it:
https://github.com/RcppCore/RcppArmadillo/blob/master/inst/include/armadillo_bits/glue_solve_meat.hpp#L26

Best regards,

baptiste
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] linking external libraries in a package

[baptiste auguie]

Hi,

Dirk was right, unsurprisingly, all it took was to dump the files in src/
and R takes care of everything during package building (I initially had
issues with the PATH for my C compiler, which led me to the wrong
conclusion that things weren't so simple). All is magically working now :)

Thanks,

baptiste


On 1 January 2014 17:33, Dirk Eddelbuettel e...@debian.org wrote:


 On 1 January 2014 at 17:30, baptiste auguie wrote:
 | Hi list, and happy new year,

 Thanks, and Happy New Year from here too!

 | The command I'm using to create an executable is
 |
 | g++ -DHCUBATURE -o minimal hcubature.c minimal.c -lm -I
 /usr/local/include -O2
 |  -larmadillo -framework Accelerate
 |
 | where hcubature.c and associated header files come from cubature (
 http://
 | ab-initio.mit.edu/wiki/index.php/Cubature ).

 Summary: No external depends. No extra headers. No extra libraries.

 (Beyond the Accelerate framework which is OS X specific. I do not know if R
 would add this automatically.  If it needs manual intervention, you can
 handle this with src/Makevars alone. But that is a different question.)

 | The last piece I'm missing is how to compile such source files in a
 package
 | with the correct flags; my understanding is that most of these flags can
 be
 | taken care of with a suitable Makevars file. I currently have the
 following,
 |
 | PKG_LIBS = $(shell $(R_HOME)/bin/Rscript -e Rcpp:::LdFlags() )
 $(LAPACK_LIBS)
 | $(BLAS_LIBS) $(FLIBS)
 |
 | but I don't see how to link hcubature.c together with another source
 file. Do I
 | need a complete Makefile to specify this sort of command? I have zero
 | experience in these matters of compilation, I'd appreciate some guidance
 or
 | simple examples to follow.

 Just drop it into src/ and you're done.

 There are 5000+ packages on CRAN, and a large enough percentage with
 compiled code, and a still large enough percentage amonth those which
 includes external packages. Just look what others are doing -- eg packages
 such as RSQLite include the entire SQLite project (plain C, no external
 depends).

 More complicated setups exists too where you first descend into
 subdirectories of src/ and build entire libraries first. IIRC the Matrix
 package does -- but you don't have to.  One of the earlier Rcpp clients
 which I helped with a package reorginisation was phylobase, and there we
 did
 just that: copy all the external depends into src/ and have Makevars take
 care of it. Which avoids the convoluted need for library building under
 different OSs and ARCHs.  As I said: drop into src/ and you're done.

 R actually provides a pretty rich build system. If anything, it is a tad
 underdocumented.  But lists such as this one, or expert such as Simon, can
 set you straight.

 Let me know if you need more help.  I could fork your repo if you're lost.

 Cheers,  Dirk

 --
 Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[Rcpp-devel] linking external libraries in a package

[baptiste auguie]

Hi list, and happy new year,

This is a follow-up to a previous query I made on Stack Overflow,
http://stackoverflow.com/questions/20474303/using-c-function-from-other-package-in-rcpp
where my goal is to use an existing library for numerical integration
together with my existing functions using RcppArmadillo.

I've since taken a different perspective: I will call directly the original
C routine and ship it with my package. With helpful guidance from Conrad
Sanderson I managed to sort out the c/c++ side of things. I now have a
stand-alone proof-of-principle code to use the cubature library for
numerical integration, with an integrand based on Armadillo objects (and
some glue between the two),
https://github.com/baptiste/cubature/blob/master/minimal.c

The command I'm using to create an executable is

g++ -DHCUBATURE -o minimal hcubature.c minimal.c -lm -I /usr/local/include
-O2  -larmadillo -framework Accelerate

where hcubature.c and associated header files come from cubature (
http://ab-initio.mit.edu/wiki/index.php/Cubature ).

The last piece I'm missing is how to compile such source files in a package
with the correct flags; my understanding is that most of these flags can be
taken care of with a suitable Makevars file. I currently have the following,

PKG_LIBS = $(shell $(R_HOME)/bin/Rscript -e Rcpp:::LdFlags() )
$(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)

but I don't see how to link hcubature.c together with another source file.
Do I need a complete Makefile to specify this sort of command? I have zero
experience in these matters of compilation, I'd appreciate some guidance or
simple examples to follow.

Best regards,

baptiste
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Fwd: CRAN packages with C++ compilation errors on OS X 10.9

[baptiste auguie]

Hi,

Sorry for the delay in getting back to this; I took the opportunity to
rewrite a substantial part of the package, and this slowed down the update
for those c++11 / clang issues.
The bottom line is that using Rcpp::function in modules was enough to
please OSX 10.9 on CRAN:
http://www.r-project.org/nosvn/R.check/r-devel-macosx-x86_64/cda-00check.html

Thanks,

baptiste



On 31 October 2013 13:15, Romain Francois rom...@r-enthusiasts.com wrote:

 Le 31/10/2013 15:59, baptiste auguie a écrit :

 Dear Rcpp gurus,


 Today a CRAN maintainer informed us of the failure of a few Rcpp-related
 packages to build under the new version of the Mac operating system, OS
 X 10.9 aka Mavericks.
 I do have access to a Mac, but I'm reluctant (in fact, unable) to update
 to Mavericks, therefore I'm in the dark when it comes to fixing /testing
 for the errors reported in the log file. On a positive note, it appears
 at first sight that most of the errors are relatively benign, and
 similar-looking issues are reported for all the packages involved. That
 gives me hope that once the underlying issue is well identified, most
 packages can be fixed with minimal changes.

 Here's the info we were given from CRAN,

 OS X 10.9 (aka Mavericks) has a new C++ compiler, clang++ with libcxx
 headers/runtime.  Your package fails to compile with that compiler: see
 the appropriate log at http://www.stats.ox.ac.uk/pub/__bdr/Mavericks/

 http://www.stats.ox.ac.uk/pub/bdr/Mavericks/ .

 My two packages are cda and planar. The error seems to occur in the
 Modules definition, e.g. from this line in my code

 https://github.com/baptiste/planar/blob/master/src/multilayer.cpp#L231

 where function is judged ambiguous, as far as I understand. This
 function is presumably something from
 Rcpp/include/Rcpp/module/Module_generated_function.h but I am not
 familiar with that code.

 Any ideas, hints?

 Best regards,

 baptiste


 I sent you a pull request on github.

 .function abuses the compiler recognition, it is just unfortunate that
 something else is called function, which is what confused it.

 Not sure there could be defenses against it.

 In the meantime, you should be fine by just using Rcpp::function



 Also, for such trivial uses of modules (i.e. no classes), maybe it is
 worth considering using // [[Rcpp::export]] and code generation given by
 compileAttributes instead of modules.


 Romain

 --
 Romain Francois
 Professional R Enthusiast
 +33(0) 6 28 91 30 30

 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Fwd: CRAN packages with C++ compilation errors on OS X 10.9

[baptiste auguie]

On 31 October 2013 13:15, Romain Francois rom...@r-enthusiasts.com wrote:

 Le 31/10/2013 15:59, baptiste auguie a écrit :

 Dear Rcpp gurus,


 Today a CRAN maintainer informed us of the failure of a few Rcpp-related
 packages to build under the new version of the Mac operating system, OS
 X 10.9 aka Mavericks.
 I do have access to a Mac, but I'm reluctant (in fact, unable) to update
 to Mavericks, therefore I'm in the dark when it comes to fixing /testing
 for the errors reported in the log file. On a positive note, it appears
 at first sight that most of the errors are relatively benign, and
 similar-looking issues are reported for all the packages involved. That
 gives me hope that once the underlying issue is well identified, most
 packages can be fixed with minimal changes.

 Here's the info we were given from CRAN,

 OS X 10.9 (aka Mavericks) has a new C++ compiler, clang++ with libcxx
 headers/runtime.  Your package fails to compile with that compiler: see
 the appropriate log at 
 http://www.stats.ox.ac.uk/pub/**__bdr/Mavericks/http://www.stats.ox.ac.uk/pub/__bdr/Mavericks/

 http://www.stats.ox.ac.uk/**pub/bdr/Mavericks/http://www.stats.ox.ac.uk/pub/bdr/Mavericks/
 .

 My two packages are cda and planar. The error seems to occur in the
 Modules definition, e.g. from this line in my code

 https://github.com/baptiste/**planar/blob/master/src/**
 multilayer.cpp#L231https://github.com/baptiste/planar/blob/master/src/multilayer.cpp#L231

 where function is judged ambiguous, as far as I understand. This
 function is presumably something from
 Rcpp/include/Rcpp/module/**Module_generated_function.h but I am not
 familiar with that code.

 Any ideas, hints?

 Best regards,

 baptiste


 I sent you a pull request on github.


 .function abuses the compiler recognition, it is just unfortunate that
 something else is called function, which is what confused it.

 Not sure there could be defenses against it.

 In the meantime, you should be fine by just using Rcpp::function


Thanks! I've merged your pull request, and will propagate the changes to my
cda package which reports similar issues.




 Also, for such trivial uses of modules (i.e. no classes), maybe it is
 worth considering using // [[Rcpp::export]] and code generation given by
 compileAttributes instead of modules.


You're probably right, I haven't been able to keep up with the new idioms
in Rcpp; next time I get around to developing the package for new
functionality, I'll investigate how to use those attributes instead.

Thanks!

baptiste



 Romain

 --
 Romain Francois
 Professional R Enthusiast
 +33(0) 6 28 91 30 30

 __**_
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-**project.orgRcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-**project.org/cgi-bin/mailman/**
 listinfo/rcpp-develhttps://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Forcing a shallow versus deep copy

[baptiste auguie]

Hi,

That's great, thanks for considering this!

Following this discussion, I went to browse through my code looking for
wrap() and as() statements that could benefit from a speed-up of memory
reuse. Of course I didn't find any.
I switched to using Modules when they were introduced, the code being much
nicer to read, and these conversions only happen behind the scene.
My c++ functions thus only deal with native Armadillo / C++ objects, and I
leave it up to the modules to magically do the required conversions in and
out. It's a brilliant interface, very readable.

From what I understand, however, the resulting code can often lose a factor
2-3 in speed, compared to the now much more verbose alternative of
explicitly converting and sharing the memory with this type of code:

arma::mat A(M.begin(), M.rows(), M.cols(), false);

From this perspective, the possibility of setting copy_aux_mem to false in
as(), as used by modules, would be very welcome.

Best regards,

baptiste


On 11 July 2013 10:22, rom...@r-enthusiasts.com wrote:


 Hello,

 This comes up every now and then, I think we can find a syntax to initiate
 an arma::mat that would allow what you want.

 It is not likely it will come via attributes. The idea is to keep them
 simple. The solutions I see below would eventually lead to clutter, and we
 are heading in the less clutter direction.

 I'll think about it and propose something.

 Romain

 Le 2013-07-11 14:32, Changi Han a écrit :

  Hello,

 I think I (superficially) understand the difference between:

 // [[Rcpp::export]]
 double sum1(Rcpp::NumericMatrix M) {
 arma::mat A(M.begin(), M.rows(), M.cols(), false);
  return sum(sum(A));
 }

 // [[Rcpp::export]]
 double sum2(arma::mat A) {
 return sum(sum(A));
 }

 Partly out of laziness, partly because sum2 is more elegant, and
 partly to avoid namespace pollution, I was wondering if there is a way
 to force a shallow copy in sum2.

 If not, then may I submit a low priority feature request. An
 attribute? Some thing like:

 // [[Rcpp::export]]
 double sum2(arma::mat A) {
 // [[ Rcpp::shallow ( A ) ]]
  return sum(sum(A));
 }

 Or (akin to C++11 generalized attributes)

 // [[Rcpp::export]] { [[ Rcpp::shallow ( A ) ]] }
 double sum2(arma::mat A) {
 return sum(sum(A));
  }

 An alternative is to have an argument in sourceCpp that takes a
 list/vector of objects that are to be shallow or deep copied.

 For example in sum1, if M is changed within the function before
 casting to the arma::mat, then might be cleaner to add M to a
 list/vector of objects to be deep copied rather than cloning M within
 sum1: leads to one fewer variable name.

 Just a thought. I can certainly live with the additional step. As
 always, thanks for all the Rcpp goodness.

 Cheers,
 Changi Han


 __**_
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-**project.orgRcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-**project.org/cgi-bin/mailman/**
 listinfo/rcpp-develhttps://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Pass a function name as an argument.

[baptiste auguie]

Hi,

I asked the same thing once, and Dirk came up with some helpful ideas and a
whipped up a demo for the gallery

http://stackoverflow.com/questions/14428687/rcpparmadillo-pass-user-defined-function

http://gallery.rcpp.org/articles/passing-cpp-function-pointers/

HTH,

baptiste

On 18 May 2013 19:00, Xiao He praguewaterme...@gmail.com wrote:

 Hi JJ,

 Thank you for the reply. I would actually like to pass C++ functions to
 the C++ function foo(). To be more specific, the user will indicate in the
 R environment which of the two functions (fun1 or fun2) to pass to foo().
 foo() will somehow use the chosen one accordingly. I suppose one option is
 to wrap foo() inside another function. The wrapper function can take input
 from the user from R, and then based on what the input is choose the
 appropriate function (fun1 or fun2). But the question of how to pass
 functions with different numbers of arguments still remains.  I wonder if
 you have any thoughts. Thank you again!

 Best,
 Xiao




 On Sat, May 18, 2013 at 12:45 PM, JJ Allaire jj.alla...@gmail.com wrote:

 Hi Xiao,

 The problem is that sourceCpp can only accept arguments of types that can
 be converted to R using Rcpp::as (this is detailed in the help topic for
 sourceCpp and in the Rcpp vignettes). Plain C function pointers
 aren't convertible in this fashion so the compilation fails.

 If your intention is to pass an R function to C++ you can however use the
 Rcpp::Function type in your signature. This is explained in more detail in
 this Rcpp Gallery article:

 http://gallery.rcpp.org/articles/r-function-from-c++/

 J.J.

 On Sat, May 18, 2013 at 1:31 PM, Xiao He praguewaterme...@gmail.comwrote:

 Hi everyone, I have two questions regarding passing a function name as
 an argument.

 (1). Suppose that I have a function foo() shown below. The function
 takes a NumericVector and a function pointer that points to a function that
 takes a NumericVector and returns a double. Note that the function pointer
 will only point to functions not exposed to R.

 double foo(NumericVector x, double (*f)(NumericVector x) ){
 double output;
  output=(*f)(x);
 return output;
 }

 When I try to compile it as is using sourceCpp(), it's fine, but when I
 add // [[Rcpp::export]] above the function definition, I get an error
 message:

 Error in sourceCpp(foo.cpp) :
   Error 1 occurred building shared library.
 foo.cpp:229: error: expected initializer before ‘SEXP’

 So I wonder how I can fix this mistake.


 (2). Imagine a more complex scenario: suppose there are two functions
 available to be passed to foo(). But the two functions differ in the number
 of arguments each has (see fun1() and fun2() below). I wonder if there is
 any way to deal with this.

 double fun1(NumericVector x){
 double total=0;
  for(int i=0;ix.size();i++)
 total+=x(i);
  return total/10;
 }


 double fun2(NumericVector x, int n){
 double total=0;
  for(int i=0;ix.size();i++)
 total+=x(i)+add;
  return total/n;
 }
  Thank you in advance!


 Best,
 -Xiao


 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel




 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] an error message from RcppArmadillo: sourceRcpp

[baptiste auguie]

Hi,

I believe you're missing this line:

// [[Rcpp::depends(RcppArmadillo)]]

HTH,

baptiste

On 29 January 2013 19:08, Aileen Lin aileenshanhong@gmail.com wrote:

 Hi there,

 I get RcppArmadillo running, but still has a problem
 with Rcpp::sourceCpp(). My code is here:

 #include Rcpp.h
 #include RcppArmadillo.h
 using namespace Rcpp;

 //[[Rcpp::export]]
 NumericMatrix add(NumericMatrix b){

   return b.n_cols;
 }

  Rcpp::sourceCpp('add.cpp')
 g++ -m64 -IC:/R/R-215~1.2/include -DNDEBUG
 -IC:/Users/Aileen/Documents/R/win-library/2.15/Rcpp/include
 -Id:/RCompile/CRANpkg/extralibs64/local/include -O2 -Wall
  -mtune=core2 -c add.cpp -o add.o add.cpp:2:27: fatal error:
 RcppArmadillo.h: No such file or directory compilation terminated. make:
 *** [add.o] Error 1
 Error in Rcpp::sourceCpp(add.cpp) :
   Error 1 occurred building shared library.

 Could anyone tell me what I did wrongly? Thank you.

 Regards,
 Aileen

 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Fwd: latest incompatible changes for package developers?

[baptiste auguie]

Hi Romain, Dirk, all,

Thanks for the quick replies. I think the list problem was due to a change
in my gmail address (from googlemail); still puzzling that I didn't get a
warning.

Hopefully someone can figure out why a function that returned an arma
matrix has now become a vector: I've posted a minimal package on dropbox,

https://dl.dropbox.com/u/352834/cda_1.2.1.tar.gz

with a test in inst/testing that used to return a 3x3 matrix (Euler
rotation), now a vector after the Rcpp update.


The lesson for me is that I should really get into a proper testing
framework. In the meantime, I'll be writing a few tests with Hadley's
testthat.

All the best,

baptiste


On 17 November 2012 11:20, Romain Francois rom...@r-enthusiasts.com wrote:

 First time I see this email.

 Sorry your package does not work.

 R CMD check --no-vignettes worked. (this is how I tested), but indeed
 something in the vignette makes it crash. I guess I should check the
 vignettes too :/

 I get an error in demo(dimer_linear)

 regarding something that does not look like it is related to Rcpp, in this
 mdply call :

 comparison - mdply(params, onedimer, .progress=none)

 Not sure what the next steps are ...

 Romain

 Le 16/11/12 22:56, baptiste auguie a écrit :

 Hi,

 Forwarded to you directly just in case it never makes it to the list for
 whatever reason (shouldn't I get an error message if it it is bounced?)

 Best,

 baptiste

 -- Forwarded message --
 From: *baptiste auguie* baptiste.aug...@gmail.com
 mailto:baptiste.auguie@gmail.**com baptiste.aug...@gmail.com
 Date: 17 November 2012 09:29
 Subject: Fwd: latest incompatible changes for package developers?
 To: rcpp-devel 
 rcpp-de...@r-forge.wu-wien.**ac.atrcpp-de...@r-forge.wu-wien.ac.at
 mailto:rcpp-de...@r-forge.wu-**wien.ac.atrcpp-de...@r-forge.wu-wien.ac.at
 


 Not sure what happened to this email I sent yesterday; I can't find it
 in the list archives?

 Thanks,
 b.


 -- Forwarded message --
 From: *baptiste auguie* baptiste.aug...@gmail.com
 mailto:baptiste.auguie@gmail.**com baptiste.aug...@gmail.com
 Date: 16 November 2012 09:18
 Subject: latest incompatible changes for package developers?
 To: rcpp-devel 
 rcpp-devel@lists.r-forge.r-**project.orgrcpp-devel@lists.r-forge.r-project.org
 mailto:rcpp-devel@lists.r-**forge.r-project.orgrcpp-devel@lists.r-forge.r-project.org
 


 Dear list,

 I haven't yet had time to read much about the new exciting changes
 introduced in Rcpp 0.10, but I got an email from B. Ripley this morning
 warning me that my cda package* was broken as a result of this CRAN
 update. It uses modules and RcppArmadillo.
 Indeed, a quick glance at the broken demos after having updated the
 package suggest that most if not all my functions are currently broken.
 Is there a specific document I should read first to speed up this
 recovery and be compatible with the new version? How much change should
 I expect?

 Thanks.
 All the best,

 baptiste

 * https://github.com/baptiste/**cda https://github.com/baptiste/cda
 http://cran.r-project.org/web/**packages/cda/index.htmlhttp://cran.r-project.org/web/packages/cda/index.html




 --
 Romain Francois
 Professional R Enthusiast
 +33(0) 6 28 91 30 30

 R Graph Gallery: 
 http://gallery.r-enthusiasts.**comhttp://gallery.r-enthusiasts.com
 `- http://bit.ly/SweN1Z : SuperStorm Sandy

 blog:
 http://romainfrancois.blog.**free.frhttp://romainfrancois.blog.free.fr
 |- http://bit.ly/RE6sYH : OOP with Rcpp modules
 `- http://bit.ly/Thw7IK : Rcpp modules more flexible


___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] broken package after udpate

[baptiste auguie]

I see, thanks a lot for tracking this down.
In practical terms, should I change all such functions to use SEXP +
explicit wrap, or will you submit a new CRAN version soon enough fixing
this? Personally I don't mind waiting a bit for the CRAN fix of cda;
probably noone else uses my package and I'd rather avoid making unnecessary
workaround fixes. That being said, I would be surprised if no other
packages broke because of this.

All the best,

baptiste




On 17 November 2012 12:44, Romain Francois rom...@r-enthusiasts.com wrote:

 This is about one of C++ most annoying things. order of includes.

 To make it short, the function that is responsible for making an R object
 out of the returned arma::mat is module_wrap, which calls wrap,

 Where module_wrap is currently written, it does not see the wrap()
 overloads from RcpppArmadillo so it just uses a version that uses begin()
 and end() and therefor just creates a vector.

 So, alright. I broke this. This is an easy fix, although I'm afraid one
 that has to happen in Rcpp.

 A contingency measure might be to write your euler function like this:



 SEXP euler(const double phi, const double theta, const double psi)
   {
 arma::mat Rot(3,3);
 const double cosphi = cos(phi), cospsi = cos(psi), costheta =
 cos(theta);
 const double sinphi = sin(phi), sinpsi = sin(psi), sintheta =
 sin(theta);
 Rot(0,0) = cospsi*cosphi - costheta*sinphi*sinpsi;
 Rot(0,1) = cospsi*sinphi + costheta*cosphi*sinpsi;
 Rot(0,2) = sinpsi*sintheta;

 Rot(1,0) = -sinpsi*cosphi - costheta*sinphi*cospsi;
 Rot(1,1) = -sinpsi*sinphi + costheta*cosphi*cospsi;
 Rot(1,2) = cospsi*sintheta;

 Rot(2,0) = sinphi*sintheta;
 Rot(2,1) = -cosphi*sintheta;
 Rot(2,2) = costheta;

 return wrap(Rot);
   }

 because there you call the right wrap.

 Of course, the desired behaviour of having arma::mat as returned type will
 be brought back.

 Romain

 Le 17/11/12 00:08, Dirk Eddelbuettel a écrit :


 On 17 November 2012 at 11:31, baptiste auguie wrote:
 | Hi,
 |
 | (Hopefully this makes it to the list; I believe I've had problems
 reaching it
 | because of a recent change between @gmail and @googlemail).

 Looks like it.

 | I made a minimal package * to illustrate the problem of my recently
 broken
 | package cda (since yesterday's update of Rcpp). There's only one
 function euler
 | () in a Module named cda. It used to return a 3x3 matrix, but after
 updating to
 | Rcpp 0.10 it returns a vector. You can run the example with
 |
 | $ R -f inst/testing/test.r
 |
 | What am I doing wrong?
 |
 | Best,
 |
 | baptiste
 |
 | * 
 https://dl.dropbox.com/u/**352834/cda_1.2.1.tar.gzhttps://dl.dropbox.com/u/352834/cda_1.2.1.tar.gz

 Good example. I added one line
  Rcpp::Rcout  In Euler, Rot is   std::endl  Rot  std::endl;
 and the end of 'Euler' and we see that the dimension is in fact there, but
 then gets lost on the way out:


 edd@max:/tmp/baptiste$ r -lcda -p -e'M - cda$euler(1.1, 2.0, 3.1);
 dim(M); class(M); M'
   [1] cda   grid  reshape2  randtoolbox
   [5] rngWELL   statmod   plyr  RcppArmadillo
   [9] Rcpp  methods   base
 In Euler, Rot is
-0.4378  -0.8983   0.0378
-0.3894   0.1515  -0.9085
 0.8104  -0.4125  -0.4161

 [1] -0.43778268 -0.38941320  0.81037256 -0.89828547  0.15154235
 -0.41245379
 [7]  0.03780919 -0.90851102 -0.41614684
 NULL
 [1] numeric
 [1] -0.43778268 -0.38941320  0.81037256 -0.89828547  0.15154235
 -0.41245379
 [7]  0.03780919 -0.90851102 -0.41614684
 edd@max:/tmp/baptiste$

 That is with the newest Rcpp and RcppArmadillo.  So somewhere we are
 loosing
 the matrix attribute.

 If I 'make the whole thing slower' by explicitly converting, it works -- I
 just add euler2 as

 NumericMatrix euler2(const double phi, const double theta, const double
 psi) {
arma::mat M(3,3);
M = euler(phi, theta, psi);
return Rcpp::wrap(M);
 }
 // [...]
 function( euler2, euler2, Constructs a 3x3 Euler rotation matrix ) ;\

 as seen here:


 edd@max:/tmp/baptiste$ r -lcda -p -e'M - cda$euler2(1.1, 2.0, 3.1);
 dim(M); class(M); M'
   [1] cda   grid  reshape2  randtoolbox
   [5] rngWELL   statmod   plyr  RcppArmadillo
   [9] Rcpp  methods   base
 In Euler, Rot is
-0.4378  -0.8983   0.0378
-0.3894   0.1515  -0.9085
 0.8104  -0.4125  -0.4161

 [,1]   [,2][,3]
 [1,] -0.4377827 -0.8982855  0.03780919
 [2,] -0.3894132  0.1515423 -0.90851102
 [3,]  0.8103726 -0.4124538 -0.41614684
 [1] 3 3
 [1] matrix
 [,1]   [,2][,3]
 [1,] -0.4377827 -0.8982855  0.03780919
 [2,] -0.3894132  0.1515423 -0.90851102
 [3,]  0.8103726 -0.4124538 -0.41614684
 edd@max:/tmp/baptiste$

 So somewhere between the compiler getting smarter, Conrad optimising
 expression and us, an attribute got lost.

 Maybe Romain can find a way to make this explicit.

 Cheers, Dirk





 --
 Romain Francois
 Professional R

Re: [Rcpp-devel] broken package after udpate

[baptiste auguie]

I've tested my package with the latest Rcpp svn commit (3987) on r-forge
and that fixes it. I'm therefore keen to just wait for the next Rcpp
release; I'll write the CRAN maintainers to see what they want to do with
temporarily broken cda in the meantime.

Thanks again for the very responsive help,

baptiste




On 17 November 2012 13:13, Dirk Eddelbuettel e...@debian.org wrote:


 On 17 November 2012 at 01:06, Romain Francois wrote:
 |
 | Le 17/11/12 00:59, baptiste auguie a écrit :
 |  I see, thanks a lot for tracking this down.

 Seconded -- nicely done.

 |  In practical terms, should I change all such functions to use SEXP +
 |  explicit wrap, or will you submit a new CRAN version soon enough fixing
 |  this?
 |
 | I don't know.

 We are doing _a lot_ of work on Rcpp right now, so I'd say we will have a
 new
 release sooner rather than later -- maybe in two or three weeks. But there
 is
 no guarantee.

 |  Personally I don't mind waiting a bit for the CRAN fix of cda;
 |  probably noone else uses my package and I'd rather avoid making
 |  unnecessary workaround fixes. That being said, I would be surprised if
 |  no other packages broke because of this.
 |
 | Well. We'll only know when people tell us I guess.

 With infinite time, we would have an infinite number of use cases. I think
 we
 have a simple case that test return of matrices, but (and I have not yet
 checked) the include order that Romain identified is of course not
 something
 we check.

 Cheers, Dirk

 --
 Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] [OT] Rcpp CRAN usage milestone

[baptiste auguie]

A big thanks from me too, to the Rcpp team for a great piece of software.
(there was a summery Easter break, during which I did not keep up with
list emails -- thanks for reviving it)

Cheers,

baptiste



On 13 April 2012 14:33, Michael Hannon jm_han...@yahoo.com wrote:
 On Sunday, April 8, 2012 at 10:50 AM Dirk Eddelbuettel wrote:

 The CRANberries service [1] just noticed a new package 'survSNP' which
 brings the number of CRAN packages having a Depends: or Imports: on Rcpp to
 sixty.
 .
 .
 .
 So I it is really nice to see that Rcpp appears to now be playing
 approximately the same role for many of you reading this list here---so a
 big Thank You! to all of you for your patches, bug reports, questions and
 or suggestions.
 .
 .
 .

 Hi, Dirk.  I guess it takes a village to raise a successful R package, so in
 that sense your Thank You! to the users of Rcpp  Friends is appropriate.

 But I like to think that for both kids and R packages the parents play an
 essential role.  I've been waiting for somebody to offer the obvious back at
 you, dude! response, but I haven't seen one.  So let me be the first: thanks
 to you and Romain for creating, maintaining, and updating Rcpp.

 -- Mike
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Optimising 2d convolution

[baptiste auguie]

Hi,

(Rcpp)Armadillo has a 1D convolution function 
http://arma.sourceforge.net/docs.html#conv . It might be a very
inefficient way, to use it sequentially for 2D; I haven't tried.

HTH,

baptiste



On 7 January 2012 07:43, Hadley Wickham had...@rice.edu wrote:
 Hi all,

 The rcpp-devel list has been very helpful to me so far, so I hope you
 don't mind another question!  I'm trying to speed up my 2d convolution
 function:



 library(inline)
 # 2d convolution -

 convolve_2d - cxxfunction(signature(sampleS = numeric, kernelS =
 numeric), plugin = Rcpp, '
    Rcpp::NumericMatrix sample(sampleS), kernel(kernelS);
    int x_s = sample.nrow(), x_k = kernel.nrow();
    int y_s = sample.ncol(), y_k = kernel.ncol();

    Rcpp::NumericMatrix output(x_s + x_k - 1, y_s + y_k - 1);
    for (int row = 0; row  x_s; row++) {
      for (int col = 0; col  y_s; col++) {
        for (int i = 0; i  x_k; i++) {
          for (int j = 0; j  y_k; j++) {
            output(row + i, col + j) += sample(row, col) * kernel(i, j);
          }
        }
      }
    }
    return output;
 ')


 x - diag(1000)
 k - matrix(runif(20* 20), ncol = 20)
 system.time(convolve_2d(x, k))
 #    user  system elapsed
 # 14.759   0.028  15.524

 I have a vague idea that to get better performance I need to get
 closer to bare pointers, and I need to be careful about the order of
 my loops to ensure that I'm working over contiguous chunks of memory
 as often as possible, but otherwise I've basically exhausted my
 C++/Rcpp knowledge.  Where should I start looking to improve the
 performance of this function?

 The example data basically matches the real problem - x is not usually
 going to be much bigger than 1000 x 1000 and k typically will be much
 smaller.  (And hence, based on what I've read, this technique should
 be faster than doing it via a discrete fft)

 Hadley

 --
 Assistant Professor / Dobelman Family Junior Chair
 Department of Statistics / Rice University
 http://had.co.nz/
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Optimising 2d convolution

[baptiste auguie]

On 7 January 2012 11:40, baptiste auguie baptiste.aug...@googlemail.com wrote:
 Hi,

 (Rcpp)Armadillo has a 1D convolution function 
 http://arma.sourceforge.net/docs.html#conv . It might be a very
 inefficient way, to use it sequentially for 2D; I haven't tried.

Also, it only works for separable kernels.

baptiste


 HTH,

 baptiste



 On 7 January 2012 07:43, Hadley Wickham had...@rice.edu wrote:
 Hi all,

 The rcpp-devel list has been very helpful to me so far, so I hope you
 don't mind another question!  I'm trying to speed up my 2d convolution
 function:



 library(inline)
 # 2d convolution 
 -

 convolve_2d - cxxfunction(signature(sampleS = numeric, kernelS =
 numeric), plugin = Rcpp, '
    Rcpp::NumericMatrix sample(sampleS), kernel(kernelS);
    int x_s = sample.nrow(), x_k = kernel.nrow();
    int y_s = sample.ncol(), y_k = kernel.ncol();

    Rcpp::NumericMatrix output(x_s + x_k - 1, y_s + y_k - 1);
    for (int row = 0; row  x_s; row++) {
      for (int col = 0; col  y_s; col++) {
        for (int i = 0; i  x_k; i++) {
          for (int j = 0; j  y_k; j++) {
            output(row + i, col + j) += sample(row, col) * kernel(i, j);
          }
        }
      }
    }
    return output;
 ')


 x - diag(1000)
 k - matrix(runif(20* 20), ncol = 20)
 system.time(convolve_2d(x, k))
 #    user  system elapsed
 # 14.759   0.028  15.524

 I have a vague idea that to get better performance I need to get
 closer to bare pointers, and I need to be careful about the order of
 my loops to ensure that I'm working over contiguous chunks of memory
 as often as possible, but otherwise I've basically exhausted my
 C++/Rcpp knowledge.  Where should I start looking to improve the
 performance of this function?

 The example data basically matches the real problem - x is not usually
 going to be much bigger than 1000 x 1000 and k typically will be much
 smaller.  (And hence, based on what I've read, this technique should
 be faster than doing it via a discrete fft)

 Hadley

 --
 Assistant Professor / Dobelman Family Junior Chair
 Department of Statistics / Rice University
 http://had.co.nz/
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[Rcpp-devel] asarma::cx_double(x)

[baptiste auguie]

Dear list,

I'm probably missing something basic, but I expected the following to work,

library(RcppArmadillo)
library(inline)

fx - cxxfunction(signature(x = Rcomplex) , '
 arma::cx_double y = asarma::cx_double(x);
 return wrap( y ) ;
   ', plugin = RcppArmadillo )


fx( 1+2i )

yet it fails to compile. I believe I need a conversion since arma does
not know what to do with Rcomplex objects, e.g. multiplying x by i =
arma::cx_double(0,1) yields

error: no match for 'operator*' in 'x * i'

I've successfully used cx_vec instead of cx_double,

fx - cxxfunction(signature(x = Rcomplex) , '
 arma::cx_vec y = asarma::cx_vec(x);
 const arma::cx_double i = arma::cx_double(0,1);
 return wrap( y * i ) ;
   ', plugin = RcppArmadillo )

fx( 1+2i )

Does this make sense?

Best regards,

baptiste
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Fwd: Building and Installing an R package built under RcppArmadillo on Mac OS X

[baptiste auguie]

Same here,

fun(matrix(rnorm(9),3,3))
   [,1]   [,2]   [,3]
[1,]  1.3709584 -0.5646982  0.3631284
[2,] -0.5646982  0.4042683 -0.1061245
[3,]  0.3631284 -0.1061245  2.0184237
 sessionInfo()
R version 2.13.1 (2011-07-08)
Platform: i386-apple-darwin9.8.0/i386 (32-bit)

locale:
[1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  grid
methods   base

other attached packages:
[1] RcppArmadillo_0.2.29 Rcpp_0.9.6   inline_0.3.8
[4] ggplot2_0.8.9proto_0.3-9.2reshape_0.8.4
[7] plyr_1.6

loaded via a namespace (and not attached):
[1] tools_2.13.1
 system(g++ --version)
i686-apple-darwin9-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5577)

baptiste


On 15 October 2011 08:27, MISRA, SANJOG
sanjog.mi...@simon.rochester.edu wrote:
 As does mine.

 fun - cxxfunction(signature(M_=numeric), plugin=RcppArmadillo,body = '
 + arma::mat M = Rcpp::asarma::mat(M_);
 + return Rcpp::wrap(symmatl(M));
 + ')

 set.seed(42)
 fun(matrix(rnorm(9),3,3))
           [,1]       [,2]       [,3]
 [1,]  1.3709584 -0.5646982  0.3631284
 [2,] -0.5646982  0.4042683 -0.1061245
 [3,]  0.3631284 -0.1061245  2.0184237



 :g++ --version
 i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)

 sessionInfo()
 R version 2.13.0 (2011-04-13)
 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)



 Sanjog Misra
 Associate Professor of Marketing and Applied Statistics
 Area Coordinator, Applied Statistics
 Simon School of Business
 University of Rochester
 Rochester, NY 14627
 P: 585.275.8920
 F: 585.273.1140


 -Original Message-
 From: rcpp-devel-boun...@r-forge.wu-wien.ac.at 
 [mailto:rcpp-devel-boun...@r-forge.wu-wien.ac.at] On Behalf Of Steve Lianoglou
 Sent: Friday, October 14, 2011 2:42 PM
 To: Dirk Eddelbuettel
 Cc: rcpp-de...@r-forge.wu-wien.ac.at
 Subject: Re: [Rcpp-devel] Fwd: Building and Installing an R package built 
 under RcppArmadillo on Mac OS X

 Something is definitely wrong.

 My printout goes out to 1 more decimal place than yours:

 R fun(matrix(rnorm(9),3,3))
           [,1]       [,2]       [,3]
 [1,]  1.3709584 -0.5646982  0.3631284
 [2,] -0.5646982  0.4042683 -0.1061245
 [3,]  0.3631284 -0.1061245  2.0184237

 R sesionInfo()
 R version 2.13.1 Patched (2011-09-15 r57010)
 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
 ...

 And

 $ g++ --version
 i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)

 -steve

 On Fri, Oct 14, 2011 at 1:17 PM, Dirk Eddelbuettel e...@debian.org wrote:

 To bring closure to this issue I may well have misdiagnosed at first, could
 someone on an OS X machine please run the following

 -
 suppressMessages(library(inline))

 fun - cxxfunction(signature(M_=numeric), plugin=RcppArmadillo,
                   body='
  arma::mat M = Rcpp::asarma::mat(M_);
  return Rcpp::wrap( symmatl(M) );
 ')

 set.seed(42)
 fun(matrix(rnorm(9),3,3))
 -


 My linux box gets me

 R suppressMessages(library(inline))
 R fun - cxxfunction(signature(M_=numeric), plugin=RcppArmadillo,
 +                    body='
 +   arma::mat M = Rcpp::asarma::mat(M_);
 +   return Rcpp::wrap( symmatl(M) );
 + ')
 R set.seed(42)
 R fun(matrix(rnorm(9),3,3))
          [,1]      [,2]      [,3]
 [1,]  1.370958 -0.564698  0.363128
 [2,] -0.564698  0.404268 -0.106125
 [3,]  0.363128 -0.106125  2.018424
 R


 and I would like to rule out actual OS X issue and with that pass the baton
 back to Terrance as a presumably local issue on his box.

 Thanks!

 Dirk

 --
 Outside of a dog, a book is a man's best friend. Inside of a dog, it is too
 dark to read. -- Groucho Marx
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel




 --
 Steve Lianoglou
 Graduate Student: Computational Systems Biology
  | Memorial Sloan-Kettering Cancer Center
  | Weill Medical College of Cornell University
 Contact Info: http://cbio.mskcc.org/~lianos/contact
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Now 38 CRAN packages using Rcpp

[baptiste auguie]

Awesome indeed, congratulations!

RcppArmadillo has 8 offsprings on CRAN, RcppEigen and RcppGSL none so far.

AP - available.packages(contrib.url(http://cran.r-project.org;))

## more concise count
## length(grep(Rcpp, AP[,Depends]))
## sum(grepl(Rcpp, AP[,Depends]))

depends = data.frame(pattern= c(Rcpp, RcppArmadillo,
   RcppEigen, RcppGSL, rJava))

library(plyr)
pl - mlply(depends,  grep, x = AP[,Depends])
arrange(ldply(pl, length), -V1)

baptiste


On 17 September 2011 01:54, Dirk Eddelbuettel e...@debian.org wrote:

 This mornings CRAN arrival of bcp, now rewritten to use Rcpp, brings the
 total of CRAN packages using Rcpp to 38.

 That is a pretty stunning number given that the rewrite leading to what Rcpp
 is today hadn't even started two years ago.  Thanks to everybody for the
 help, suggestions, encouragements, and of course contributions and bug fixes!

 My informal comparison was always to rJava, and we are closing the gap --
 seven more packages to go:

 R AP - available.packages(contrib.url(http://cran.r-project.org;))
 R do.call(sum, lapply(AP[,Depends], FUN=function(x) grep(rJava, x)==1))
 [1] 45
 R do.call(sum, lapply(AP[,Depends], FUN=function(x) grep(Rcpp, x)==1))
 [1] 38
 R dim(AP)
 [1] 3268   13
 R


 Dirk



 --
 New Rcpp master class for R and C++ integration is scheduled for
 San Francisco (Oct 8), more details / reg.info available at
 http://www.revolutionanalytics.com/products/training/public/rcpp-master-class.php
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Question about compile package to .zip for windows

[baptiste auguie]

http://win-builder.r-project.org/

is very handy.

HTH,

baptiste

On 1 August 2011 15:14, Yi Zhao zhaoyitj2...@gmail.com wrote:
 Dear all,

 I am trying to compile a package that I developed on Linux. I want to
 compile it to .zip package for windows.

 However, Rcmd build --binary  doesn't work well. The compiled package
 cannot be installed on Windows.

 FYI, Ubuntu 10.10.

 Does anybody have any ideas? I am a begineer, please guide me at your
 convenience.

 Thanks a lot!

 Yi Zhao
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel


___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[Rcpp-devel] package: cda

[baptiste auguie]

Dear list,

I have just released a new package on CRAN
http://cran.r-project.org/web/packages/cda/index.html . It uses
RcppArmadillo to solve a complex linear system of equations that
describes the self-consistent electromagnetic interaction between
small metallic nanoparticles illuminated by light, thereby predicting
the scattering and absorption properties of the cluster.

Thanks for the invaluable help I got from this list along the way;
Romain, Dirk, Conrad and Doug in particular.

Best regards,

baptiste
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] RcppEigen now on CRAN

[baptiste auguie]

Hi,

Another august piece work, thanks.
As a happy user of Armadillo (guess what, this week my packages even
passed win-builder! Yeah!) I have a general question: between (Rcpp),
RcppGSL, RcppArmadillo, RcppEigen, we now have so much choice that it
may be difficult to decide which framework to use for a particular
project. Are there comparative charts somewhere, in terms of function
coverage, speed? (those I found did not cover these three libraries).
It could also be very useful to have a kind of Rosetta stone, akin to
http://arma.sourceforge.net/docs.html#syntax but comparing (R) | Rcpp
|  RcppGSL | RcppArmadillo | RcppEigen, ideally with wise comments
from advanced users. Where could we build such meta-documentation?

Just a thought,

Best regards,

baptiste




On 28 June 2011 07:55, Douglas Bates ba...@stat.wisc.edu wrote:
 A new package, RcppEigen, which provides linkage from R to the Eigen
 C++ template library for linear algebra (http://eigen.tuxfamily.org)
 via Rcpp, is now available on CRAN.    The Eigen library is a pure
 template library that does not depend on the BLAS or Lapack, thus
 avoiding some difficulties such as Baptiste Auguste encountered
 regarding inconsistent versions of the Lapack routines being available
 on different platforms.

 A great deal of care has gone into the development of the Eigen
 library to ensure good performance through the use of vectorization
 instructions such as SSE2, SSE3 and ARM_NEON, when available, and by
 using block structured algorithms.  The files RcppEigen/src/fastLm.h
 and RcppEigen/src/fastLm.cpp in the source package provide examples of
 the use of some of the decompositions available in Eigen.  Eigen
 supports both dense and sparse matrices, with various types of
 triangular, symmetric (or selfAdjoint) and diagonal adaptors.  To
 learn about the facilities available in Eigen I would recommend
 starting with the tutorial at
 http://eigen.tuxfamily.org/dox/index.html

 Like the Rcpp and RcppArmadillo packages, RcppEigen has a plugin for
 cxxfunction from the inline package, to allow for rapid prototyping.
 There is also a function RcppEigen.package.skeleton to aid in creating
 a package that uses the RcppEigen headers.

 Because Eigen essentially creates its own BLAS functions, the size of
 the libs directory for packages using RcppEigen can be very large and
 compiling source files that include the RcppEigen.h file can be
 relatively slow.  As with most template libraries, the idea is to
 off-load the complexity of the code onto the compiler to sort out,
 with the penalty that instantiating templates may slow down the
 compiler.

 I enclose an example of a short C++ function using RcppEigen and a
 slightly longer and more complex C++ function, compiled with inline.
 Some things to notice:

 - in keeping with the functional programming semantics of R, it is a
 good idea to declare Rcpp objects created from the input SEXP
 arguments as const.

 - a Eigen matrix of double precision values has type Eigen::MatrixXd,
 similarly Eigen::MatrixXi for integer matrices and Eigen::MatrixXcd
 for matrices of std::complexdouble (see the tutorial for the
 explanation of the X in MatrixXd)

 - the Eigen::VectorXd class is a column vector of doubles, similarly
 Eigen::VectorXi and Eigen::VectorXcd.  A row vector is
 Eigen::RowVectorXd, etc.  These are all just specializations of the
 Matrix template (Vectors have 1 column, RowVectors have 1 row, fixed
 at compile time).

 - to obtain an Eigen matrix or vector from an Rcpp object, without
 copying the contents, use the Eigen::Map adaptor class.

 - the Eigen classes ArrayXd and ArrayXXd are similar representations
 to VectorXd and MatrixXd but allow for element-wise operations.  The
 .array() method creates a view of a Vector or Matrix object as an
 Array.  The .matrix() method maps the other way.

 - the Eigen::Matrix and Eigen::Array classes have methods for
 Rcpp::wrap defined in the RcppEigen headers.

 - Adaptor methods like .triangularViewtype(),
 .selfadjointViewtype() and .diagonalView() (applied to a Vector) are
 the common ways of restricting to specialized forms of matrices.

 - most methods for Eigen classes return *this as a reference so that
 methods can be chained.

 - like Armadillo, Eigen performs lazy evaluation of expressions to
 reduce the number of intermediate results that must be stored.

 As with any new libraries, Eigen takes some getting used to, but
 overall I have found it very good to work with and recommend its use.

 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel


___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] package .onLoad multiple modules

[baptiste auguie]

Oops, please ignore the second request; it is documented in Rcpp-modules.

Thanks,

baptiste

On 24 June 2011 15:16, baptiste auguie baptiste.aug...@googlemail.com wrote:
 Hi,

 I have a couple of follow-up questions re: this old thread:

 - could we expect a CRAN release of Rcpp soon? (I am relying on this
 new argument to loadRcppModules(), which means that my package would
 currently fail on CRAN, and even on r-forge (I'm not sure how to
 specify Rcpp = 0.9.4.2 as import).

 - R/zzz.r in my package now reads,

  cda - new( Module )
  cd - new( Module )
  linear - new( Module )
  array - new( Module )

  .onLoad - function(pkgname, libname){
     loadRcppModules(direct=FALSE)
  }

 which is much cleaner than before; however, R CMD check still complains
 WARNING Undocumented code objects:
  array cd linear
 All user-level objects in a package should have documentation entries.

 Can I hide them, or is there a documentation format for Modules?

 Thanks, and best regards,

 baptiste

 PS: full package is at
 https://r-forge.r-project.org/scm/viewvc.php/pkg/cda/?root=photonics

 sessionInfo()
 R version 2.13.0 (2011-04-13)
 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)

 locale:
 [1] en_NZ.UTF-8/en_NZ.UTF-8/C/C/en_NZ.UTF-8/en_NZ.UTF-8

 attached base packages:
 [1] stats     graphics  grDevices utils     datasets  grid
 methods   base

 other attached packages:
 [1] cda_1.0              statmod_1.4.10       RcppArmadillo_0.2.23
 Rcpp_0.9.4.2         ggplot2_0.8.9        proto_0.3-9.2
 [7] reshape_0.8.4        plyr_1.5.2



 On 1 June 2011 15:43, baptiste auguie baptiste.aug...@googlemail.com wrote:
 On 31 May 2011 23:19,  rom...@r-enthusiasts.com wrote:

 Le 31 mai 2011 à 13:11, Christian Gunning x...@unm.edu a écrit :

 On Tue, May 31, 2011 at 3:00 AM,
 rcpp-devel-requ...@r-forge.wu-wien.ac.at wrote:
 When FALSE it does what you want.

 Fantastic, thanks a lot.

 baptiste


 I can't begin to describe how long I've waited for such a function.
 -x

 :-)
 Well it does what you want ... in this context...

 It might not accomodate other needs you might have such as time travel, etc 
 ...


 --
 A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama!
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel



___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] package .onLoad multiple modules

[baptiste auguie]

Hi,

Thanks, and indeed, given the choice r-forge always opts for CRAN
versions of packages, which is quite annoying. I removed Rcpp from
DESCRIPTION/Depends when I added it as an import(Rcpp) in NAMESPACE.
I'm not sure if both are needed/compatible.

Thanks also for the news re: the next Rcpp release, looking forward to that.

Best regards,

baptiste


On 25 June 2011 05:45, Dirk Eddelbuettel e...@debian.org wrote:

 On 24 June 2011 at 10:16, Davor Cubranic wrote:
 | On June 23, 2011 08:16:59 PM baptiste auguie wrote:
 |  - could we expect a CRAN release of Rcpp soon? (I am relying on this
 |  new argument to loadRcppModules(), which means that my package would
 |  currently fail on CRAN, and even on r-forge (I'm not sure how to
 |  specify Rcpp = 0.9.4.2 as import).
 |
 | Version dependencies can be specified in the package's DESCRIPTION file. I 
 have
 | this in one of my packages:
 |       Depends: Rcpp (= 0.8.6), RcppArmadillo (= 0.2.6)

 Yes, sure, but only 'a.b.c.' versions get to CRAN, and R-Forge in all its
 wisdom does not use development versions packages hosted there.  So all it
 knows is 0.9.4.

 It may be two or three more weeks til a new Rcpp release.

 Dirk

 --
 Gauss once played himself in a zero-sum game and won $50.
                      -- #11 at http://www.gaussfacts.com
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] package .onLoad multiple modules

[baptiste auguie]

Hi,

I have a couple of follow-up questions re: this old thread:

- could we expect a CRAN release of Rcpp soon? (I am relying on this
new argument to loadRcppModules(), which means that my package would
currently fail on CRAN, and even on r-forge (I'm not sure how to
specify Rcpp = 0.9.4.2 as import).

- R/zzz.r in my package now reads,

  cda - new( Module )
  cd - new( Module )
  linear - new( Module )
  array - new( Module )

 .onLoad - function(pkgname, libname){
 loadRcppModules(direct=FALSE)
 }

which is much cleaner than before; however, R CMD check still complains
WARNING Undocumented code objects:
  array cd linear
All user-level objects in a package should have documentation entries.

Can I hide them, or is there a documentation format for Modules?

Thanks, and best regards,

baptiste

PS: full package is at
https://r-forge.r-project.org/scm/viewvc.php/pkg/cda/?root=photonics

sessionInfo()
R version 2.13.0 (2011-04-13)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)

locale:
[1] en_NZ.UTF-8/en_NZ.UTF-8/C/C/en_NZ.UTF-8/en_NZ.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  grid
methods   base

other attached packages:
[1] cda_1.0  statmod_1.4.10   RcppArmadillo_0.2.23
Rcpp_0.9.4.2 ggplot2_0.8.9proto_0.3-9.2
[7] reshape_0.8.4plyr_1.5.2



On 1 June 2011 15:43, baptiste auguie baptiste.aug...@googlemail.com wrote:
 On 31 May 2011 23:19,  rom...@r-enthusiasts.com wrote:

 Le 31 mai 2011 à 13:11, Christian Gunning x...@unm.edu a écrit :

 On Tue, May 31, 2011 at 3:00 AM,
 rcpp-devel-requ...@r-forge.wu-wien.ac.at wrote:
 When FALSE it does what you want.

 Fantastic, thanks a lot.

 baptiste


 I can't begin to describe how long I've waited for such a function.
 -x

 :-)
 Well it does what you want ... in this context...

 It might not accomodate other needs you might have such as time travel, etc 
 ...


 --
 A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama!
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel


___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] trans() changed in latest RcppArmadillo

[baptiste auguie]

Hi Conrad, all,

Thanks for the fixes and fast release. I have just tested
RcppArmadillo_0.2.22 on my code and it works fine.

Best regards,

baptiste


On 7 June 2011 03:52, Conrad Sand conradsand.r...@gmail.com wrote:
 Hi Baptise  Terrance,

 I've fixed several issues in Armadillo and released an updated version
 (1.99.4).  Dirk has wrapped it up in RcppArmadillo 0.2.22, which
 should be hitting the mirrors soon.

 Could you try your code again and let me know if you encounter any problems ?

 With regards,
 Conrad


 On 1 June 2011 05:58, baptiste auguie baptiste.aug...@googlemail.com wrote:
 Thanks so much, Conrad!

 Best regards,

 Baptiste

 On 31 May 2011 23:37, Conrad Sand wrote:
 I've found the cause of the issue (involves handling of small matrices).

 The fix is easy (and already done in the SVN repo), but I currently
 don't have the time to roll out another release.  I'll aim to release
 a fix on the weekend, which will also give me time to double-check if
 there is a problem in inv().

 In the meantime I recommend sticking to the previous version of
 Armadillo and RcppArmadillo.

 btw, for dot products I recommend using the dot() and cdot() functions
 -- they're generally faster than going through the multiplication
 operator.

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] RcppArmadillo inv() depends on Lapack, zgetri_ not available on CRAN / R-forge?

[baptiste auguie]

On 8 June 2011 08:03, Douglas Bates ba...@stat.wisc.edu wrote:
 On Tue, Jun 7, 2011 at 2:34 PM, baptiste auguie
 baptiste.aug...@googlemail.com wrote:
 Hi Doug,

 On 8 June 2011 03:43, Douglas Bates ba...@stat.wisc.edu wrote:

 On Jun 6, 2011 4:17 AM, baptiste auguie baptiste.aug...@googlemail.com
 wrote:

 Thank you for the explanations below.

 On 5 June 2011 10:40, Dirk Eddelbuettel e...@debian.org wrote:
 
  On 5 June 2011 at 10:12, baptiste auguie wrote:
  | Hi Dirk and all,
  |
  | On 4 June 2011 12:04, Dirk Eddelbuettel e...@debian.org wrote:
  | 
  |  Baptiste,
  | 
  |  On 4 June 2011 at 11:45, baptiste auguie wrote:
  |  | Dear list,
  |  |
  |  | My package cda, which I was hoping to release on CRAN, fails to
  |  | compile on R-forge with error,
  |  |
  |  | ** testing if installed package can be loaded
  |  | Error in dyn.load(file, DLLpath = DLLpath, ...) :
  |  |   unable to load shared object
  '/tmp/RtmpbztUMm/Rinst1829c04c/cda/libs/cda.so':
  |  |   /tmp/RtmpbztUMm/Rinst1829c04c/cda/libs/cda.so: undefined symbol:
  zgetri_
  |  |
  |  | It builds fine on my local machines (Mac OS 10.5, 10.6).
  |  |
  |  | From an older discussion on this list 
  |  |
  http://www.mail-archive.com/rcpp-devel@lists.r-forge.r-project.org/msg00678.html
  |  | the issue seems to be that Armadillo's inv() relies on a function
  that
  |  | is not provided by R, only by LAPACK. I have just replaced inv()
  by
  |  | pinv() and solve() in my code; merely to see what happens, but
  chances
  |  | are they also require a full LAPACK.
  |
  | Indeed, the error on R-forge is now with zgels_, required to solve
  | linear systems. It seems one cannot solve Armadillo linear systems
  | without LAPACK in the current situation.
 
  Yes. Doug, Romain and myself should address that, or at least make it
  clear
  what feature of the full Armadillo are lacking in RcppArmadillo.
 
  |  Sometime relatively early in the RcppArmadillo development process,
  Doug
  |  convinced Romain and myself to go for a pure template solution with
  Armadillo
  |  as all / most things found during the configure (or in this case,
  cmake)
  |  stage can be assumed 'found' given that we have around us by design.
   So no
  |  testing, no local library and full reliance and what R gives us.
  | 
  |  That was a brilliant idea, and has freed us from having to rely on
  building
  |  and shipping a library, having to tell users how to set PKG_LIBS etc
  pp and I
  |  firmly believe that this helped tremendously in getting
  RcppArmadillo more
  |  widely used. So I would not want to revert this.
  |
  | It sounds like a good choice, I agree. Yet solving a linear system is
  | quite a crucial task in linear algebra; it would be nice if we could
  | come up with a tutorial recipe for dummies like me.
  |
  | 
  |  In any event, it seems that you need more LAPACK than R has for you.
   That is
  |  likely to be a dicey situation as you per se do not know whether R
  was built
  |  and linked with its own (subset) copy of LAPACK, or whether it uses
  system
  |  LAPACK libraries (as e.g. the Debian / Ubuntu systems do).  So you
  may be in
  |  a spot bother and I not sure what I can recommend --- other than
  trying your
  |  luck at some short configure snippets that will run at package build
  time to
  |  determine whether the system you want to build cda on it 'rich'
  enough to
  |  support it.  I can help you off list with some configure snippets as
  some of
  |  my packages have configure code; adding a test for zgetri should be
  feasible.
  | 
  |  | Does anybody have any experience
  |  | dealing with such issues w.r.t releasing a package on R-forge /
  CRAN?
  |  | Is there any chance they would consider installing LAPACK on those
  |  | servers, or is there no point in asking such things?
  | 
  |  I don't think it is a matter of fixing the R-Forge server. I think
  it is a
  |  matter of making your package installable on the largest number of
  user
  |  systems.  Also try win-builder.r-project.org to see how it fares on
  that
  |  platform.

 Unsurprisingly, it fails, with the same complaint as R-forge.

  |
  | I was under the impression that R-forge or CRAN, if it had LAPACK
  | installed, could produce binaries for the relevant platforms, and
  | users would not have to build the package themselves and would not be
  | required of having LAPACK on their machine. That's probably a
  | misconception, isn't it?
 
  If and only statically linked binaries or libraries where produced,
  which is
  generally not the case. Many OSs (Linux incl) ship source only and
  otherwise
  link dynamically, others (Windoze) use dynamic linking and OS X is for
  all I
  know somewhere in the middle (as you can get prebuild packages with
  dynamic
  linking or build from source).

 I see; so basically the user will always need to have a full LAPACK
 installed. Here's one question then, if R-core didn't consider
 necessary to include those particular

Re: [Rcpp-devel] RcppArmadillo inv() depends on Lapack, zgetri_ not available on CRAN / R-forge?

[baptiste auguie]

On 8 June 2011 09:04, Douglas Bates ba...@stat.wisc.edu wrote:
 On Tue, Jun 7, 2011 at 3:47 PM, baptiste auguie
 baptiste.aug...@googlemail.com wrote:
 On 8 June 2011 08:03, Douglas Bates ba...@stat.wisc.edu wrote:
 On Tue, Jun 7, 2011 at 2:34 PM, baptiste auguie
 baptiste.aug...@googlemail.com wrote:
 Hi Doug,

 On 8 June 2011 03:43, Douglas Bates ba...@stat.wisc.edu wrote:

 On Jun 6, 2011 4:17 AM, baptiste auguie baptiste.aug...@googlemail.com
 wrote:

 Thank you for the explanations below.

 On 5 June 2011 10:40, Dirk Eddelbuettel e...@debian.org wrote:
 
  On 5 June 2011 at 10:12, baptiste auguie wrote:
  | Hi Dirk and all,
  |
  | On 4 June 2011 12:04, Dirk Eddelbuettel e...@debian.org wrote:
  | 
  |  Baptiste,
  | 
  |  On 4 June 2011 at 11:45, baptiste auguie wrote:
  |  | Dear list,
  |  |
  |  | My package cda, which I was hoping to release on CRAN, fails to
  |  | compile on R-forge with error,
  |  |
  |  | ** testing if installed package can be loaded
  |  | Error in dyn.load(file, DLLpath = DLLpath, ...) :
  |  |   unable to load shared object
  '/tmp/RtmpbztUMm/Rinst1829c04c/cda/libs/cda.so':
  |  |   /tmp/RtmpbztUMm/Rinst1829c04c/cda/libs/cda.so: undefined 
  symbol:
  zgetri_
  |  |
  |  | It builds fine on my local machines (Mac OS 10.5, 10.6).
  |  |
  |  | From an older discussion on this list 
  |  |
  http://www.mail-archive.com/rcpp-devel@lists.r-forge.r-project.org/msg00678.html
  |  | the issue seems to be that Armadillo's inv() relies on a function
  that
  |  | is not provided by R, only by LAPACK. I have just replaced inv()
  by
  |  | pinv() and solve() in my code; merely to see what happens, but
  chances
  |  | are they also require a full LAPACK.
  |
  | Indeed, the error on R-forge is now with zgels_, required to solve
  | linear systems. It seems one cannot solve Armadillo linear systems
  | without LAPACK in the current situation.
 
  Yes. Doug, Romain and myself should address that, or at least make it
  clear
  what feature of the full Armadillo are lacking in RcppArmadillo.
 
  |  Sometime relatively early in the RcppArmadillo development process,
  Doug
  |  convinced Romain and myself to go for a pure template solution with
  Armadillo
  |  as all / most things found during the configure (or in this case,
  cmake)
  |  stage can be assumed 'found' given that we have around us by 
  design.
   So no
  |  testing, no local library and full reliance and what R gives us.
  | 
  |  That was a brilliant idea, and has freed us from having to rely on
  building
  |  and shipping a library, having to tell users how to set PKG_LIBS 
  etc
  pp and I
  |  firmly believe that this helped tremendously in getting
  RcppArmadillo more
  |  widely used. So I would not want to revert this.
  |
  | It sounds like a good choice, I agree. Yet solving a linear system is
  | quite a crucial task in linear algebra; it would be nice if we could
  | come up with a tutorial recipe for dummies like me.
  |
  | 
  |  In any event, it seems that you need more LAPACK than R has for 
  you.
   That is
  |  likely to be a dicey situation as you per se do not know whether R
  was built
  |  and linked with its own (subset) copy of LAPACK, or whether it uses
  system
  |  LAPACK libraries (as e.g. the Debian / Ubuntu systems do).  So you
  may be in
  |  a spot bother and I not sure what I can recommend --- other than
  trying your
  |  luck at some short configure snippets that will run at package 
  build
  time to
  |  determine whether the system you want to build cda on it 'rich'
  enough to
  |  support it.  I can help you off list with some configure snippets 
  as
  some of
  |  my packages have configure code; adding a test for zgetri should be
  feasible.
  | 
  |  | Does anybody have any experience
  |  | dealing with such issues w.r.t releasing a package on R-forge /
  CRAN?
  |  | Is there any chance they would consider installing LAPACK on 
  those
  |  | servers, or is there no point in asking such things?
  | 
  |  I don't think it is a matter of fixing the R-Forge server. I think
  it is a
  |  matter of making your package installable on the largest number of
  user
  |  systems.  Also try win-builder.r-project.org to see how it fares on
  that
  |  platform.

 Unsurprisingly, it fails, with the same complaint as R-forge.

  |
  | I was under the impression that R-forge or CRAN, if it had LAPACK
  | installed, could produce binaries for the relevant platforms, and
  | users would not have to build the package themselves and would not be
  | required of having LAPACK on their machine. That's probably a
  | misconception, isn't it?
 
  If and only statically linked binaries or libraries where produced,
  which is
  generally not the case. Many OSs (Linux incl) ship source only and
  otherwise
  link dynamically, others (Windoze) use dynamic linking and OS X is for
  all I
  know somewhere in the middle (as you can get prebuild packages with
  dynamic
  linking or build from source

Re: [Rcpp-devel] RcppArmadillo inv() depends on Lapack, zgetri_ not available on CRAN / R-forge?

[baptiste auguie]

Thank you for the explanations below.

On 5 June 2011 10:40, Dirk Eddelbuettel e...@debian.org wrote:

 On 5 June 2011 at 10:12, baptiste auguie wrote:
 | Hi Dirk and all,
 |
 | On 4 June 2011 12:04, Dirk Eddelbuettel e...@debian.org wrote:
 | 
 |  Baptiste,
 | 
 |  On 4 June 2011 at 11:45, baptiste auguie wrote:
 |  | Dear list,
 |  |
 |  | My package cda, which I was hoping to release on CRAN, fails to
 |  | compile on R-forge with error,
 |  |
 |  | ** testing if installed package can be loaded
 |  | Error in dyn.load(file, DLLpath = DLLpath, ...) :
 |  |   unable to load shared object 
 '/tmp/RtmpbztUMm/Rinst1829c04c/cda/libs/cda.so':
 |  |   /tmp/RtmpbztUMm/Rinst1829c04c/cda/libs/cda.so: undefined symbol: 
 zgetri_
 |  |
 |  | It builds fine on my local machines (Mac OS 10.5, 10.6).
 |  |
 |  | From an older discussion on this list 
 |  | 
 http://www.mail-archive.com/rcpp-devel@lists.r-forge.r-project.org/msg00678.html
 |  | the issue seems to be that Armadillo's inv() relies on a function that
 |  | is not provided by R, only by LAPACK. I have just replaced inv() by
 |  | pinv() and solve() in my code; merely to see what happens, but chances
 |  | are they also require a full LAPACK.
 |
 | Indeed, the error on R-forge is now with zgels_, required to solve
 | linear systems. It seems one cannot solve Armadillo linear systems
 | without LAPACK in the current situation.

 Yes. Doug, Romain and myself should address that, or at least make it clear
 what feature of the full Armadillo are lacking in RcppArmadillo.

 |  Sometime relatively early in the RcppArmadillo development process, Doug
 |  convinced Romain and myself to go for a pure template solution with 
 Armadillo
 |  as all / most things found during the configure (or in this case, cmake)
 |  stage can be assumed 'found' given that we have around us by design.  So 
 no
 |  testing, no local library and full reliance and what R gives us.
 | 
 |  That was a brilliant idea, and has freed us from having to rely on 
 building
 |  and shipping a library, having to tell users how to set PKG_LIBS etc pp 
 and I
 |  firmly believe that this helped tremendously in getting RcppArmadillo more
 |  widely used. So I would not want to revert this.
 |
 | It sounds like a good choice, I agree. Yet solving a linear system is
 | quite a crucial task in linear algebra; it would be nice if we could
 | come up with a tutorial recipe for dummies like me.
 |
 | 
 |  In any event, it seems that you need more LAPACK than R has for you.  
 That is
 |  likely to be a dicey situation as you per se do not know whether R was 
 built
 |  and linked with its own (subset) copy of LAPACK, or whether it uses system
 |  LAPACK libraries (as e.g. the Debian / Ubuntu systems do).  So you may be 
 in
 |  a spot bother and I not sure what I can recommend --- other than trying 
 your
 |  luck at some short configure snippets that will run at package build time 
 to
 |  determine whether the system you want to build cda on it 'rich' enough to
 |  support it.  I can help you off list with some configure snippets as some 
 of
 |  my packages have configure code; adding a test for zgetri should be 
 feasible.
 | 
 |  | Does anybody have any experience
 |  | dealing with such issues w.r.t releasing a package on R-forge / CRAN?
 |  | Is there any chance they would consider installing LAPACK on those
 |  | servers, or is there no point in asking such things?
 | 
 |  I don't think it is a matter of fixing the R-Forge server. I think it is a
 |  matter of making your package installable on the largest number of user
 |  systems.  Also try win-builder.r-project.org to see how it fares on that
 |  platform.

Unsurprisingly, it fails, with the same complaint as R-forge.

 |
 | I was under the impression that R-forge or CRAN, if it had LAPACK
 | installed, could produce binaries for the relevant platforms, and
 | users would not have to build the package themselves and would not be
 | required of having LAPACK on their machine. That's probably a
 | misconception, isn't it?

 If and only statically linked binaries or libraries where produced, which is
 generally not the case. Many OSs (Linux incl) ship source only and otherwise
 link dynamically, others (Windoze) use dynamic linking and OS X is for all I
 know somewhere in the middle (as you can get prebuild packages with dynamic
 linking or build from source).

I see; so basically the user will always need to have a full LAPACK
installed. Here's one question then, if R-core didn't consider
necessary to include those particular functions from LAPACK,
presumably that means that R defines its own routines to solve linear
systems and invert matrices. Is there any possibility to use those
routines with Armadillo?


 | Sorry for being dense, I don't know anything about linking R to
 | external dependencies.

 It can be done; there are many examples -- for example every package using
 the GSL.

I just checked how RcppGSL does it, and well, this configure

[Rcpp-devel] RcppArmadillo inv() depends on Lapack, zgetri_ not available on CRAN / R-forge?

[baptiste auguie]

Dear list,

My package cda, which I was hoping to release on CRAN, fails to
compile on R-forge with error,

** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object '/tmp/RtmpbztUMm/Rinst1829c04c/cda/libs/cda.so':
  /tmp/RtmpbztUMm/Rinst1829c04c/cda/libs/cda.so: undefined symbol: zgetri_

It builds fine on my local machines (Mac OS 10.5, 10.6).

From an older discussion on this list 
http://www.mail-archive.com/rcpp-devel@lists.r-forge.r-project.org/msg00678.html
the issue seems to be that Armadillo's inv() relies on a function that
is not provided by R, only by LAPACK. I have just replaced inv() by
pinv() and solve() in my code; merely to see what happens, but chances
are they also require a full LAPACK. Does anybody have any experience
dealing with such issues w.r.t releasing a package on R-forge / CRAN?
Is there any chance they would consider installing LAPACK on those
servers, or is there no point in asking such things?

Best regards,

baptiste
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] trans() changed in latest RcppArmadillo

[baptiste auguie]

Thanks so much, Conrad!

Best regards,

Baptiste

On 31 May 2011 23:37, Conrad Sand conradsand.r...@gmail.com wrote:
 I've found the cause of the issue (involves handling of small matrices).

 The fix is easy (and already done in the SVN repo), but I currently
 don't have the time to roll out another release.  I'll aim to release
 a fix on the weekend, which will also give me time to double-check if
 there is a problem in inv().

 In the meantime I recommend sticking to the previous version of
 Armadillo and RcppArmadillo.

 btw, for dot products I recommend using the dot() and cdot() functions
 -- they're generally faster than going through the multiplication
 operator.


 On 31 May 2011 11:39, Conrad Sand conradsand.r...@gmail.com wrote:
 Hi Baptiste,

 Thanks for the bug report.  I'll take a look at the underlying issues.


 On 31 May 2011 09:48, baptiste auguie baptiste.aug...@googlemail.com wrote:
 Sorry, I had too many spaces in the vectors. The conclusion is the same 
 though.

 library(inline)
 require( RcppArmadillo )

 ## let's calculate this product
 c(-1-1i, 1-1i) %*% c(1i, -1i)
  ## 0-2i

 ## trans() with v0.2.19
 fx - cxxfunction( signature() , '
  arma::cx_colvec A = (-1,-1) (+1,-1);, B = (+0,1) (+0,-1); ;
                arma::cx_colvec res = trans(A) * B;

                return wrap( res ) ;
        ', plugin = RcppArmadillo )

 fx()
 ## 0-2i

 ## strans() with v0.2.21
 fx - cxxfunction( signature() , '
  arma::cx_colvec A = (-1,-1) (+1,-1);, B = (+0,1) (+0,-1); ;
                arma::cx_colvec res = strans(A) * B;
                return wrap( res ) ;
        ', plugin = RcppArmadillo )

 fx()
 ## 1-1i


___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] package .onLoad multiple modules

[baptiste auguie]

On 31 May 2011 23:19,  rom...@r-enthusiasts.com wrote:

 Le 31 mai 2011 à 13:11, Christian Gunning x...@unm.edu a écrit :

 On Tue, May 31, 2011 at 3:00 AM,
 rcpp-devel-requ...@r-forge.wu-wien.ac.at wrote:
 When FALSE it does what you want.

Fantastic, thanks a lot.

baptiste


 I can't begin to describe how long I've waited for such a function.
 -x

 :-)
 Well it does what you want ... in this context...

 It might not accomodate other needs you might have such as time travel, etc 
 ...


 --
 A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama!
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] trans() changed in latest RcppArmadillo

[baptiste auguie]

After a couple hours switching back and forth between versions, I
found a problem with the scalar product of complex vectors. Here is a
minimal example,

library(inline)
require( RcppArmadillo )

## let's calculate this product
c(-1-1i, 1-1i) %*% c(1i, -1i)
 ## 0-2i

## trans() with v0.2.19
fx - cxxfunction( signature() , '
 arma::cx_colvec A =  (-1,-1)(+1,-1) ;, B = (+0,1)  (+0,-1) ; ;
arma::cx_colvec res = trans(A) * B;

return wrap( res ) ;
', plugin = RcppArmadillo )

fx()
## 0-2i

## strans() with v0.2.21
fx - cxxfunction( signature() , '
 arma::cx_colvec A =  (-1,-1)(+1,-1) ;, B = (+0,1)  (+0,-1) ; ;
arma::cx_colvec res = strans(A) *B;

return wrap( res ) ;
', plugin = RcppArmadillo )

fx()
## 1-1i

Best regards,

baptiste



On 31 May 2011 10:01, baptiste auguie baptiste.aug...@googlemail.com wrote:
 I was a bit optimistic yesterday; I have not yet been able to produce
 a minimal example but it seems trans/strans was not the end of the
 story in my code. Something else was broken with the change to
 0.2.21.Thankfully the end results are very visibly wrong.

 Best regards,

 Baptiste

 On 31 May 2011 07:02, Savitsky, Terrance savit...@rand.org wrote:
 Dr. Sanderson, I've been able to verify that my issue resides in the
 inv() function (that I typically apply to small p x p matrices, where p
 = 3 - 10).  In particular, the new version/algorithm induces numerical
 instability.  I've not yet tested that the results of the inv()
 computation are generally accurate, only that they are not numerically
 robust in comparison to 0.2.19.  I'm up against a deadline, so I
 switched back to 0.2.19, which resolves my problem, for now, but will
 provide a reproducible example when finished with my work.

 Terrance

 -Original Message-
 From: Conrad Sand [mailto:conradsand.r...@gmail.com]
 Sent: Monday, May 30, 2011 6:34 AM
 To: rcpp-de...@r-forge.wu-wien.ac.at
 Cc: Savitsky, Terrance
 Subject: Re: trans() changed in latest RcppArmadillo

 On 30 May 2011, Terrance Savitsky wrote:
 Hello, After upgrading to the 0.2.21 release of RcppArmadillo, my
 previously working code (across many functions) ceased working (on a
 Windows XP installation).  I re-installed the previous version
 (0.2.20)
 from CRAN (via a server location not yet updated to 0.2.21); didn't
 fix it.
 The timing may be a coincidence, though reading the post on
 trans() encourages me to make this post.  While I use 'trans' across
 my
 functions, it is not applied on complex-valued matrices; only
 real-valued.  So the prior post wouldn't explain my issue.

 Hi, I'm the main author of Armadillo.

 I'm interested in hearing about all regressions -- can you provide
 more details ?

 There have been a lot of changes between Armadillo 1.2 and the latest
 beta (1.99.3).  I'd like to shake out all known bugs before releasing
 2.0.


 Cheers,
 Conrad

 --
 Dr Conrad Sanderson : Sr Research Scientist : NICTA :
 http://arma.sf.net/cs

 __

 This email message is for the sole use of the intended recipient(s) and
 may contain confidential information. Any unauthorized review, use,
 disclosure or distribution is prohibited. If you are not the intended
 recipient, please contact the sender by reply email and destroy all copies
 of the original message.

 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel


___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] trans() changed in latest RcppArmadillo

[baptiste auguie]

Sorry, I had too many spaces in the vectors. The conclusion is the same though.

library(inline)
require( RcppArmadillo )

## let's calculate this product
c(-1-1i, 1-1i) %*% c(1i, -1i)
 ## 0-2i

## trans() with v0.2.19
fx - cxxfunction( signature() , '
 arma::cx_colvec A = (-1,-1) (+1,-1);, B = (+0,1) (+0,-1); ;
arma::cx_colvec res = trans(A) * B;

return wrap( res ) ;
', plugin = RcppArmadillo )

fx()
## 0-2i

## strans() with v0.2.21
fx - cxxfunction( signature() , '
 arma::cx_colvec A = (-1,-1) (+1,-1);, B = (+0,1) (+0,-1); ;
arma::cx_colvec res = strans(A) * B;
return wrap( res ) ;
', plugin = RcppArmadillo )

fx()
## 1-1i


On 31 May 2011 11:42, baptiste auguie baptiste.aug...@googlemail.com wrote:
 After a couple hours switching back and forth between versions, I
 found a problem with the scalar product of complex vectors. Here is a
 minimal example,

 library(inline)
 require( RcppArmadillo )

 ## let's calculate this product
 c(-1-1i, 1-1i) %*% c(1i, -1i)
  ## 0-2i

 ## trans() with v0.2.19
 fx - cxxfunction( signature() , '
  arma::cx_colvec A =  (-1,-1)    (+1,-1) ;, B = (+0,1)  (+0,-1) ; ;
                arma::cx_colvec res = trans(A) * B;

                return wrap( res ) ;
        ', plugin = RcppArmadillo )

 fx()
 ## 0-2i

 ## strans() with v0.2.21
 fx - cxxfunction( signature() , '
  arma::cx_colvec A =  (-1,-1)    (+1,-1) ;, B = (+0,1)  (+0,-1) ; ;
                arma::cx_colvec res = strans(A) *B;

                return wrap( res ) ;
        ', plugin = RcppArmadillo )

 fx()
 ## 1-1i

 Best regards,

 baptiste



 On 31 May 2011 10:01, baptiste auguie baptiste.aug...@googlemail.com wrote:
 I was a bit optimistic yesterday; I have not yet been able to produce
 a minimal example but it seems trans/strans was not the end of the
 story in my code. Something else was broken with the change to
 0.2.21.Thankfully the end results are very visibly wrong.

 Best regards,

 Baptiste

 On 31 May 2011 07:02, Savitsky, Terrance savit...@rand.org wrote:
 Dr. Sanderson, I've been able to verify that my issue resides in the
 inv() function (that I typically apply to small p x p matrices, where p
 = 3 - 10).  In particular, the new version/algorithm induces numerical
 instability.  I've not yet tested that the results of the inv()
 computation are generally accurate, only that they are not numerically
 robust in comparison to 0.2.19.  I'm up against a deadline, so I
 switched back to 0.2.19, which resolves my problem, for now, but will
 provide a reproducible example when finished with my work.

 Terrance

 -Original Message-
 From: Conrad Sand [mailto:conradsand.r...@gmail.com]
 Sent: Monday, May 30, 2011 6:34 AM
 To: rcpp-de...@r-forge.wu-wien.ac.at
 Cc: Savitsky, Terrance
 Subject: Re: trans() changed in latest RcppArmadillo

 On 30 May 2011, Terrance Savitsky wrote:
 Hello, After upgrading to the 0.2.21 release of RcppArmadillo, my
 previously working code (across many functions) ceased working (on a
 Windows XP installation).  I re-installed the previous version
 (0.2.20)
 from CRAN (via a server location not yet updated to 0.2.21); didn't
 fix it.
 The timing may be a coincidence, though reading the post on
 trans() encourages me to make this post.  While I use 'trans' across
 my
 functions, it is not applied on complex-valued matrices; only
 real-valued.  So the prior post wouldn't explain my issue.

 Hi, I'm the main author of Armadillo.

 I'm interested in hearing about all regressions -- can you provide
 more details ?

 There have been a lot of changes between Armadillo 1.2 and the latest
 beta (1.99.3).  I'd like to shake out all known bugs before releasing
 2.0.


 Cheers,
 Conrad

 --
 Dr Conrad Sanderson : Sr Research Scientist : NICTA :
 http://arma.sf.net/cs

 __

 This email message is for the sole use of the intended recipient(s) and
 may contain confidential information. Any unauthorized review, use,
 disclosure or distribution is prohibited. If you are not the intended
 recipient, please contact the sender by reply email and destroy all copies
 of the original message.

 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel



___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[Rcpp-devel] package .onLoad multiple modules

[baptiste auguie]

Dear list,

[Disclaimer: I am not very familiar with Rcpp/C++, and probably
haven't followed all the relevant discussions on this list.]

I'm trying to tidy up two packages on r-forge [*] before submitting
them to CRAN. In cda/zzz.r, I have the following code,

NAMESPACE - environment()
cda - new( Module )
cdatests - new( Module )
cd - new( Module )
linear - new( Module )
array - new( Module )

.onLoad - function(libname, pkgname){
  unlockBinding( cda , NAMESPACE )
  unlockBinding( cdatests , NAMESPACE )
  unlockBinding( cd , NAMESPACE )
  unlockBinding( linear , NAMESPACE )
  assign( cda, Module( cda ), NAMESPACE )
  assign( cdatests, Module( cdatests ), NAMESPACE )
  assign( cd, Module( cd ), NAMESPACE )
  assign( linear, Module( linear ), NAMESPACE )
  lockBinding( cda, NAMESPACE )
  lockBinding( cdatests, NAMESPACE )
  lockBinding( cd, NAMESPACE )
  lockBinding( linear, NAMESPACE )

  unlockBinding( array , NAMESPACE )
  assign( array, Module( array ), NAMESPACE )
  lockBinding( array, NAMESPACE )

}

It seems to work, but is there something I can/should do to make this
a wee cleaner?

Thanks!

baptiste

[*]: https://r-forge.r-project.org/scm/viewvc.php/pkg/cda/?root=photonics
https://r-forge.r-project.org/scm/viewvc.php/pkg/planar/?root=photonics
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[Rcpp-devel] trans() changed in latest RcppArmadillo

[baptiste auguie]

Dear list,

The latest RcppArmadillo broke some code that worked for me before,
and produces erroneous results. I have just tracked down the origin of
the problem to a change in the armadillo library: applying trans() to
complex matrices now takes the complex conjugate as well as
transposing. Using strans() restores the original behavior. I though
I'd warn other RcppArmadillo users to check their code if it uses
complex linear algebra. Rather curiously, strans() cannot be applied
on real matrices, so trans() should be kept there.

Best regards,

baptiste
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] package .onLoad multiple modules

[baptiste auguie]

Hi,

On 30 May 2011 04:28, Dirk Eddelbuettel e...@debian.org wrote:

 On 29 May 2011 at 18:56, baptiste auguie wrote:
 | Dear list,
 |
 | [Disclaimer: I am not very familiar with Rcpp/C++, and probably
 | haven't followed all the relevant discussions on this list.]
 |
 | I'm trying to tidy up two packages on r-forge [*] before submitting
 | them to CRAN. In cda/zzz.r, I have the following code,
 |
 | NAMESPACE - environment()
 | cda - new( Module )
 | cdatests - new( Module )
 | cd - new( Module )
 | linear - new( Module )
 | array - new( Module )
 |
 | .onLoad - function(libname, pkgname){
 |   unlockBinding( cda , NAMESPACE )
 |   unlockBinding( cdatests , NAMESPACE )
 |   unlockBinding( cd , NAMESPACE )
 |   unlockBinding( linear , NAMESPACE )
 |   assign( cda, Module( cda ), NAMESPACE )
 |   assign( cdatests, Module( cdatests ), NAMESPACE )
 |   assign( cd, Module( cd ), NAMESPACE )
 |   assign( linear, Module( linear ), NAMESPACE )
 |   lockBinding( cda, NAMESPACE )
 |   lockBinding( cdatests, NAMESPACE )
 |   lockBinding( cd, NAMESPACE )
 |   lockBinding( linear, NAMESPACE )
 |
 |   unlockBinding( array , NAMESPACE )
 |   assign( array, Module( array ), NAMESPACE )
 |   lockBinding( array, NAMESPACE )
 |
 | }
 |
 | It seems to work, but is there something I can/should do to make this
 | a wee cleaner?

 Have another look at the Rcpp-modules vignette, and/or the third set of
 slides (Advanced Rcpp) from our class in April -- you no longer need the
 unlockBinding / lockBinding business as Romain internalized that. The
 skeleton-generated packages now just do this in zzz.R:

  .onLoad - function(pkgname, libname){
      loadRcppModules()
  }

 using a 'RcppModules: cda, cdatests, cd, linear, array' declaration in
 DESCRIPTION.

Strange, this does not seem to work for me.

If I use the following zzz.r, (with RcppModules listed in DESCRIPTION)

.onLoad - function(libname, pkgname){
   loadRcppModules()
}

I get a segfault whenever I use a c++ function,

 *** caught segfault ***
address 0x0, cause 'memory not mapped'

Traceback:
 1: .External(list(name = InternalFunction_invoke, address =
pointer: 0x101407f30, dll = list(name = Rcpp, path =
/Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/libs/x86_64/Rcpp.so,
dynamicLookup = TRUE, handle = pointer: 0x101441030,
info = pointer: 0x1002b3ed0), numParameters = -1L), pointer:
0x103011050, ...)
 2: circular_dichroism_spectrum(clust, gold, n = 1.33, N = 36, progress = FALSE)
 3: onecluster()

Is there another step I'm missing?

Best regards,

baptiste


 The question Laurent raised the other day about spurious warnings from 'R CMD
 check' around this still stands though.  Not yet sure what to do there...

 Cheers, Dirk

 --
 Gauss once played himself in a zero-sum game and won $50.
                      -- #11 at http://www.gaussfacts.com

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] package .onLoad multiple modules

[baptiste auguie]

Thanks, that is helpful. I think I have nailed down the problem.

I defined a wrapper at R level that used a C++ function from a module
named cd,

circular_dichroism_spectrum - function( ... ){

 [...] # some argument processing

  res - cd$circular_dichroism_spectrum(...) # calling the C++ function

 return(res)
}

Now, with loadRcppModules(), no cd module is created, as far as I
can tell, and invoking circular_dichroism_spectrum() is calling the
C++ function directly; a segfault results because some of the
arguments differ between the C++ function and its R wrapper.

I see two options:

- choose a different name for the R and C++ functions

- manage some kind of namespace masking the C++ function from the
top-level, like cd$ did before. Is there a way to do this in the
loadRcppModules() approach?

Best regards,

baptiste


On 30 May 2011 11:11, Dirk Eddelbuettel e...@debian.org wrote:

 On 30 May 2011 at 10:29, baptiste auguie wrote:
 | Hi,
 |
 | On 30 May 2011 04:28, Dirk Eddelbuettel e...@debian.org wrote:
 | 
 |  On 29 May 2011 at 18:56, baptiste auguie wrote:
 |  | Dear list,
 |  |
 |  | [Disclaimer: I am not very familiar with Rcpp/C++, and probably
 |  | haven't followed all the relevant discussions on this list.]
 |  |
 |  | I'm trying to tidy up two packages on r-forge [*] before submitting
 |  | them to CRAN. In cda/zzz.r, I have the following code,
 |  |
 |  | NAMESPACE - environment()
 |  | cda - new( Module )
 |  | cdatests - new( Module )
 |  | cd - new( Module )
 |  | linear - new( Module )
 |  | array - new( Module )
 |  |
 |  | .onLoad - function(libname, pkgname){
 |  |   unlockBinding( cda , NAMESPACE )
 |  |   unlockBinding( cdatests , NAMESPACE )
 |  |   unlockBinding( cd , NAMESPACE )
 |  |   unlockBinding( linear , NAMESPACE )
 |  |   assign( cda, Module( cda ), NAMESPACE )
 |  |   assign( cdatests, Module( cdatests ), NAMESPACE )
 |  |   assign( cd, Module( cd ), NAMESPACE )
 |  |   assign( linear, Module( linear ), NAMESPACE )
 |  |   lockBinding( cda, NAMESPACE )
 |  |   lockBinding( cdatests, NAMESPACE )
 |  |   lockBinding( cd, NAMESPACE )
 |  |   lockBinding( linear, NAMESPACE )
 |  |
 |  |   unlockBinding( array , NAMESPACE )
 |  |   assign( array, Module( array ), NAMESPACE )
 |  |   lockBinding( array, NAMESPACE )
 |  |
 |  | }
 |  |
 |  | It seems to work, but is there something I can/should do to make this
 |  | a wee cleaner?
 | 
 |  Have another look at the Rcpp-modules vignette, and/or the third set of
 |  slides (Advanced Rcpp) from our class in April -- you no longer need the
 |  unlockBinding / lockBinding business as Romain internalized that. The
 |  skeleton-generated packages now just do this in zzz.R:
 | 
 |   .onLoad - function(pkgname, libname){
 |       loadRcppModules()
 |   }
 | 
 |  using a 'RcppModules: cda, cdatests, cd, linear, array' declaration in
 |  DESCRIPTION.
 |
 | Strange, this does not seem to work for me.
 |
 | If I use the following zzz.r, (with RcppModules listed in DESCRIPTION)
 |
 | .onLoad - function(libname, pkgname){
 |    loadRcppModules()
 | }
 |
 | I get a segfault whenever I use a c++ function,
 |
 |  *** caught segfault ***
 | address 0x0, cause 'memory not mapped'
 |
 | Traceback:
 |  1: .External(list(name = InternalFunction_invoke, address =
 | pointer: 0x101407f30,     dll = list(name = Rcpp, path =
 | 
 /Library/Frameworks/R.framework/Versions/2.13/Resources/library/Rcpp/libs/x86_64/Rcpp.so,
 |         dynamicLookup = TRUE, handle = pointer: 0x101441030,
 | info = pointer: 0x1002b3ed0), numParameters = -1L),     pointer:
 | 0x103011050, ...)
 |  2: circular_dichroism_spectrum(clust, gold, n = 1.33, N = 36, progress = 
 FALSE)
 |  3: onecluster()
 |
 | Is there another step I'm missing?

 My first instinct is to check the unitTest, so look at what is different in
 test run from

   inst/unitTests/runit.Module.client.package.R

 using

   inst/unitTests/testRcppModule/

 That should still work on your platform and you should be able to go from 
 there.

 Dirk

 --
 Gauss once played himself in a zero-sum game and won $50.
                      -- #11 at http://www.gaussfacts.com

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Favourite Rcpp examples?

[baptiste auguie]

On 27 April 2011 10:56, Dirk Eddelbuettel e...@debian.org wrote:

 On 27 April 2011 at 10:29, baptiste auguie wrote:
 | Would RcppArmadillo be OK? I have a couple of functions / packages
 | using it with basic complex linear algebra calculations, together with
 | the original, slower R implementation.

 That would be perfect, yes. Mind you it is getting late as the course is in
 two days, but in a larger sense we _always_ want compelling examples to make
 the Rcpp / RcppArmadillo examples better still.

OK, sorry I've just come back from a Easter trip; it'll be too late
for your original request but I'll tidy up some examples and post back
when they're ready.
By the way, have you considered setting up a sort of wiki so that
users could share tips and short recipes with Rcpp? I find that
archived emails are not always reliable as the code may change
substantially with time, and vignettes + unit tests are more
intimidating and not as convenient. ggplot2's wiki and stackexchange
seem to work well for this purpose nowadays.

Best,

baptiste



 Several folks kindly emailed me and spoke in favour of some sort of looped
 example.  The example sent by Lance already lead to one (slightlt reworked)
 blog post (at http://dirk.eddelbuettel.com/blog/2011/04/23#rcpp_for_varsims);
 this uses RcppArmadillo to simulate a VAR(1) model. It has been added to the
 SVN repo of RcppArmadillo as well and will be in the next release.

 MCMC got a few mentions; I don't do much Bayesian analysis myself so I find
 most examples too involved. I looked again at Whit's old example based on his
 CppBugs code (on github).  But I did get my copy of Albert's 'Bayesian
 Computation with R' out and worked one example of a basic (introductory)
 Monte Carlo study (which I hope to blog about in a few days).

 So a long-winded way of saying: Yes please!  Rcpp users have been kind with
 suggestions; we added one example already and I am game for more. Show us
 what you got ;-)

 Cheers, Dirk

 --
 Gauss once played himself in a zero-sum game and won $50.
                      -- #11 at http://www.gaussfacts.com

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Release candidate (Was: Ancient Rcpp for OS X on CRAN)

[baptiste auguie]

On 23 February 2011 16:32, Dirk Eddelbuettel e...@debian.org wrote:

 On 23 February 2011 at 09:27, ken.willi...@thomsonreuters.com wrote:
 |
 |
 | On 2/23/11 8:05 AM, Dirk Eddelbuettel e...@debian.org wrote:
 |
 | 
 | Thanks again to Simon, Ken and Baptiste for help yesterday. I have put a
 | release candidate here
 | 
 |    http://dirk.eddelbuettel.com/tmp-rcpp/Rcpp_0.9.1.1.tar.gz
 | 
 | and would really appreciate it if folks with OS X versions 10.5 and 10.6
 | could give it a spin and report back (on or off list).
 |
 |
 | Passes fine for me on 10.6.

 Thank you. As did 0.9.1.  Now we need someone with 10.5 to tell us that it
 passes there too.


Yep, it does.

Thanks,

Baptiste


 Dirk

 --
 Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]

[baptiste auguie]

Hi,

Out of curiosity I also ran a R CMD check on the CRAN version of Rcpp,
and it failed on my machine (10.5):

Running the tests in ‘tests/doRUnit.R’ failed.

  Error in eval.with.vis(expr, envir, enclos) :
unit test problems: 0 failures, 1 errors
  Error in func() : object 'stdVector' not found
  Calls: source - eval.with.vis - eval.with.vis
  Execution halted

sessionInfo()
R version 2.12.1 Patched (2010-12-30 r53895)
Platform: i386-apple-darwin9.8.0 (32-bit)

locale:
[1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] tools_2.12.1

Sys.info()
sysname Darwin release 9.8.0 version Darwin Kernel
Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;

Thanks,

baptiste

On 22 February 2011 22:53, Simon Urbanek simon.urba...@r-project.org wrote:

 On Feb 22, 2011, at 3:56 PM, Dirk Eddelbuettel wrote:


 On 22 February 2011 at 15:32, Simon Urbanek wrote:
 |
 | On Feb 22, 2011, at 3:21 PM, Dirk Eddelbuettel wrote:
 |
 | 
 |  On 22 February 2011 at 13:49, ken.willi...@thomsonreuters.com wrote:
 |  | On 2/22/11 11:45 AM, Simon Urbanek simon.urba...@r-project.org 
 wrote:
 |  |
 |  |
 |  | 
 |  | On Feb 22, 2011, at 12:32 PM, Dirk Eddelbuettel wrote:
 |  | 
 |  | 
 |  | Simon:  Are there are any reasons Rcpp is frozen on a version that is
 |  | five
 |  |  months old and five releases behind?
 |  | 
 |  | 
 |  | Yes, it's not passing checks - it's that simple:
 |  | 
 http://www.R-project.org/nosvn/R.check/r-prerel-macosx-ix86/Rcpp-00check.h
 |  | tml
 |  |
 |  | On my machine, which is running R 2.12.1 on OS X 10.6.6 with nothing
 |  | remarkable changed (e.g. GCC is at 4.2.1), Rcpp_0.9.1.tar.gz builds 
 |  | tests  installs fine from the source release.
 | 
 |  Thanks for doing that. I was about to beg you do it. As I mentioned, I 
 seem
 |  to recall that it also works swimmingly on Romain's OS X machine.  So 
 there
 |  error may be somewhere between Simon and his computers ...
 | 
 |
 | Yeah, right, between me and my computers? Well, I did the legwork to track 
 down your mistakes and here is at least one that causes the test to fail:
 |
 | * installing *source* package 'testRcppModule' ...
 | ** libs
 | *** arch - i386
 | [...]
 | g++ -arch i386 -I/Library/Frameworks/R.framework/Resources/include 
 -I/Library/Frameworks/R.framework/Resources/include/i386  
 -I/usr/local/include -I/private/tmp/ttt/l/Rcpp/include   -fPIC  -g -O2 -c 
 stdVector.cpp -o stdVector.o
 | stdVector.cpp: In function 'void _rcpp_module_stdVector_init()':
 | stdVector.cpp:36: error: call of overloaded 'method(const char [7], 
 unresolved overloaded function type)' is ambiguous
 | /private/tmp/ttt/l/Rcpp/include/Rcpp/module/Module_generated_method.h:53: 
 note: candidates are: Rcpp::class_Class Rcpp::class_Class::method(const 
 char*, OUT (Class::*)(U0), const char*, bool (*)(SEXPREC**, int)) [with OUT 
 = void, U0 = long unsigned int, Class = std::vectordouble, 
 std::allocatordouble ]
 | /private/tmp/ttt/l/Rcpp/include/Rcpp/module/Module_generated_method.h:80: 
 note:                 Rcpp::class_Class Rcpp::class_Class::method(const 
 char*, OUT (Class::*)(U0, U1), const char*, bool (*)(SEXPREC**, int)) [with 
 OUT = void, U0 = long unsigned int, U1 = const double, Class = 
 std::vectordouble, std::allocatordouble ]
 | make: *** [stdVector.o] Error 1
 | ERROR: compilation failed for package 'testRcppModule'
 |
 |
 | You owe me one.

 I thought that was a constant anyway? ;-)

 Was that 32 bit or 64 bit? What OS X version? What g++ version?  Any idea why
 Romain and Ken are not affected?


 i386 = 32-bit (not that is matters) and the CRAN specs are listed in CRAN 
 Package Check Flavors saying OS X 10.5.8, gcc 4.2.1 (5577 to be precise).
 I can only speculate why they are not affected, and I'd say it's because they 
 use 10.6 and not 10.5 (consequence of which are different compilers as well).


 Could you do one further test and disable the appropriate unit test to see if
 'the rest' passes?  To do so, edit

     inst/unitTests/runit.Module.client.package.R

 either make the initial test

     if( Rcpp:::capabilities()[[Rcpp modules]] ) {

 'false' or else return right at the top of

     test.Module.package - function( ){

 because the file stdVector.cpp that failed for you is part of the test
 package for Rcpp modules as wrappers around various STL functions.


 I assume that it would succeed, because that's what the unit test file says 
 (only 1 failure). I have already deleted the tmp files I used for testing so 
 we'll have to trust RUnit on this ;).

 Cheers,
 Simon



 |
 |  | The last part of the output (where it differs from the 
 Rcpp-00check.html
 |  | above) is:
 |  |
 |  | =
 |  | * checking tests ...
 |  | ** running tests for arch Œi386¹
 |  |   Running ŒdoRUnit.R¹
 |  |  OK
 |  | ** running tests for arch Œx86_64¹
 |  |   Running ŒdoRUnit.R¹
 |  |  OK
 |  | * 

Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]

[baptiste auguie]

On 23 February 2011 00:28, Dirk Eddelbuettel e...@debian.org wrote:

 +if( Rcpp:::capabilities()[[Rcpp modules]]  ! .basOSX() ) {

You probably meant,

+if( Rcpp:::capabilities()[[Rcpp modules]]  ! .badOSX() ) {

(check in progress...)

baptiste
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]

[baptiste auguie]

R CMD check now successfully completes on my machine with

.badOSX -  !( Sys.info()['sysname'] == Darwin 

isTRUE(as.integer(gsub(\\..*,,Sys.info()['release']))  10L) )

if( Rcpp:::capabilities()[[Rcpp modules]]   .badOSX ) {

Cheers,

baptiste

On 23 February 2011 00:56, Simon Urbanek simon.urba...@r-project.org wrote:

 On Feb 22, 2011, at 6:28 PM, Dirk Eddelbuettel wrote:


 Ken,

 Could you test the 0.9.1 tarball?  Then in
 inst/unitTests/runit.Module.client.package.R, apply the diff below:

  -- ie add the new .badOSX function (maybe I'll rename it 'oldOSX')


 You have a typo in the call (.basOSX vs .badOSX) and you got the test all 
 wrong -- you're testing for anything but Darwin and you have the versions 
 wrong (only major matters and bad is anything below 10). Why don't you just 
 use my code ? ;) You can just copy my condition in verbatim just after 
 Rcpp:::capabilities()[[Rcpp modules]]  - it was designed that way ...

 Cheers,
 S


  -- change the test to add a    ! .badOSX()

 so that the test that barfs under g++ 4.2.1 is not getting run.

 If that passes everything, yet failed before, we would have ourselves a new
 version which may things better.

 Dirk


 Index: runit.Module.client.package.R
 ===
 --- runit.Module.client.package.R     (revision 2902)
 +++ runit.Module.client.package.R     (working copy)
 @@ -22,8 +22,18 @@
       gc()
 }

 -if( Rcpp:::capabilities()[[Rcpp modules]] ) {
 +.badOSX - function() {                              # the unit test in 
 this file fails on OS X 10.5
 +    val - FALSE                             # assume we are not on an old 
 OS X
 +    if (Sys.info()['sysname'] != Darwin) {    # if on Darwin, let's test
 +        vertxt - Sys.info()['release']              # 10.5.0 or 10.6.0 or 
 
 +        osx - as.numeric(strsplit(vertxt, \\.)[[1]])
 +        val - osx[1] == 10  osx[2] = 5           # 10 and le 5 will 
 mark as bad
 +    }
 +    val
 +}

 +if( Rcpp:::capabilities()[[Rcpp modules]]  ! .basOSX() ) {
 +
 test.Module.package - function( ){

     td - tempfile()

 On 22 February 2011 at 16:58, ken.willi...@thomsonreuters.com wrote:
 |
 |
 |
 |
 | On 2/22/11 4:54 PM, Dirk Eddelbuettel e...@debian.org wrote:
 |
 | What is in Sys.info(), particularly fields 1 and 2:
 | 
 | R Sys.info()[1:2]
 |             sysname             release
 |             Linux 2.6.32-25-generic
 |
 | That's probably the right way to do it, as Simon suggested too in the
 | meantime.
 |
 |  Sys.info()[1:2]
 |  sysname  release
 | Darwin 10.6.0
 |
 |
 |
 |
 |
 | 
 | 
 | Else, .Platform() starts with 'Darwin', right?
 |
 | Nope:
 |
 |  .Platform[1]
 | $OS.type
 | [1] unix
 |
 |
 |
 | --
 | Ken Williams
 | Senior Research Scientist
 | Thomson Reuters
 | http://labs.thomsonreuters.com
 |
 |

 --
 Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com



 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Ancient Rcpp for OS X on CRAN [Was: Building/linking trouble with cxxfunction()]

[baptiste auguie]

Oops, just realised the silliness of my having renamed .badOSX a good
one. Oh well, never mind that, I guess it's a matter of opinion ;)

baptiste

On 23 February 2011 01:08, baptiste auguie
baptiste.aug...@googlemail.com wrote:
 R CMD check now successfully completes on my machine with

 .badOSX -  !( Sys.info()['sysname'] == Darwin 

 isTRUE(as.integer(gsub(\\..*,,Sys.info()['release']))  10L) )

 if( Rcpp:::capabilities()[[Rcpp modules]]   .badOSX ) {

 Cheers,

 baptiste

 On 23 February 2011 00:56, Simon Urbanek simon.urba...@r-project.org wrote:

 On Feb 22, 2011, at 6:28 PM, Dirk Eddelbuettel wrote:


 Ken,

 Could you test the 0.9.1 tarball?  Then in
 inst/unitTests/runit.Module.client.package.R, apply the diff below:

  -- ie add the new .badOSX function (maybe I'll rename it 'oldOSX')


 You have a typo in the call (.basOSX vs .badOSX) and you got the test all 
 wrong -- you're testing for anything but Darwin and you have the versions 
 wrong (only major matters and bad is anything below 10). Why don't you 
 just use my code ? ;) You can just copy my condition in verbatim just after 
 Rcpp:::capabilities()[[Rcpp modules]]  - it was designed that way ...

 Cheers,
 S


  -- change the test to add a    ! .badOSX()

 so that the test that barfs under g++ 4.2.1 is not getting run.

 If that passes everything, yet failed before, we would have ourselves a new
 version which may things better.

 Dirk


 Index: runit.Module.client.package.R
 ===
 --- runit.Module.client.package.R     (revision 2902)
 +++ runit.Module.client.package.R     (working copy)
 @@ -22,8 +22,18 @@
       gc()
 }

 -if( Rcpp:::capabilities()[[Rcpp modules]] ) {
 +.badOSX - function() {                              # the unit test in 
 this file fails on OS X 10.5
 +    val - FALSE                             # assume we are not on an old 
 OS X
 +    if (Sys.info()['sysname'] != Darwin) {    # if on Darwin, let's test
 +        vertxt - Sys.info()['release']              # 10.5.0 or 10.6.0 or 
 
 +        osx - as.numeric(strsplit(vertxt, \\.)[[1]])
 +        val - osx[1] == 10  osx[2] = 5           # 10 and le 5 will 
 mark as bad
 +    }
 +    val
 +}

 +if( Rcpp:::capabilities()[[Rcpp modules]]  ! .basOSX() ) {
 +
 test.Module.package - function( ){

     td - tempfile()

 On 22 February 2011 at 16:58, ken.willi...@thomsonreuters.com wrote:
 |
 |
 |
 |
 | On 2/22/11 4:54 PM, Dirk Eddelbuettel e...@debian.org wrote:
 |
 | What is in Sys.info(), particularly fields 1 and 2:
 | 
 | R Sys.info()[1:2]
 |             sysname             release
 |             Linux 2.6.32-25-generic
 |
 | That's probably the right way to do it, as Simon suggested too in the
 | meantime.
 |
 |  Sys.info()[1:2]
 |  sysname  release
 | Darwin 10.6.0
 |
 |
 |
 |
 |
 | 
 | 
 | Else, .Platform() starts with 'Darwin', right?
 |
 | Nope:
 |
 |  .Platform[1]
 | $OS.type
 | [1] unix
 |
 |
 |
 | --
 | Ken Williams
 | Senior Research Scientist
 | Thomson Reuters
 | http://labs.thomsonreuters.com
 |
 |

 --
 Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com



 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel


___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[Rcpp-devel] split the c++ code in several files

[baptiste auguie]

Dear list,


This is probably not specific to Rcpp but I couldn't find any advice
in the R-exts manual. I am using RcppArmadillo in a package to do some
linear algebra. The C++ code is getting a bit too large to manage in
one file only, I would like to split its content in several files.
It seems possible, but I'm not sure how to deal with the scoping
rules: if a function requires a subroutine defined in another file it
seems to have a scoping problem (the compilation fails with message
error: ‘’ was not declared in this scope). Currently my cpp file
looks like this,

///
#include cda.h
#include RcppArmadillo.h
#include iostream

using namespace Rcpp ;
using namespace RcppArmadillo ;

using namespace std;

extern C {

  arma::mat foo(const arma::mat R) {
return(R);
   }

  // R wrapper
  RCPP_FUNCTION_1(NumericMatrix, test, NumericMatrix IR)
  {
   arma::mat R = Rcpp::as arma::mat (IR);
   return wrap( foo(R) );
  }
 // other routines
}
///

(The actual file is here:
https://r-forge.r-project.org/scm/viewvc.php/pkg/cda/src/cda.cpp?diff_format=hroot=photonicsview=log)


Are there workarounds / rules to split the content in several files?

Best regards,

baptiste
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] split the c++ code in several files

[baptiste auguie]

Hi,

Thanks for the valuable information and advice. Some comments / questions below.

On 16 September 2010 15:49, Romain Francois rom...@r-enthusiasts.com wrote:
 Le 16/09/10 15:24, baptiste auguie a écrit :

 Dear list,


 This is probably not specific to Rcpp but I couldn't find any advice
 in the R-exts manual. I am using RcppArmadillo in a package to do some
 linear algebra. The C++ code is getting a bit too large to manage in
 one file only, I would like to split its content in several files.
 It seems possible, but I'm not sure how to deal with the scoping
 rules: if a function requires a subroutine defined in another file it
 seems to have a scoping problem (the compilation fails with message
 error: ‘’ was not declared in this scope). Currently my cpp file
 looks like this,

 ///
 #include cda.h
 #includeRcppArmadillo.h
 #includeiostream

 using namespace Rcpp ;
 using namespace RcppArmadillo ;

 using namespace std;

 extern C {

   arma::mat foo(const arma::mat  R) {
     return(R);
    }

   // R wrapper
   RCPP_FUNCTION_1(NumericMatrix, test, NumericMatrix IR)
   {
    arma::mat R = Rcpp::as  arma::mat(IR);
    return wrap( foo(R) );
   }
  // other routines
 }
 ///

 (The actual file is here:

 https://r-forge.r-project.org/scm/viewvc.php/pkg/cda/src/cda.cpp?diff_format=hroot=photonicsview=log)


 Are there workarounds / rules to split the content in several files?

 Best regards,

 baptiste

 Hello,

 The usual thing is to declare functions in header files, and include these
 headers from each .cpp file. You then define the functions in .cpp files in
 any order you like. As long as it is declared, the compiler knows it is
 coming.

In principle I understand, but in practice I'm a bit stuck with this.
In my previous header file I only declared RcppExport functions, such
as

//
#ifndef _cda2_CDA2_H
#define _cda2_CDA2_H

#include RcppArmadillo.h

/* void progress_bar(double x, double N); */
RcppExport SEXP rotation(SEXP phi, SEXP theta, SEXP psi);

#endif

//

When I also add internal C++ routines (uncommenting progress_bar
above) I get errors such as,

** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared library
'/Library/Frameworks/R.framework/Resources/library/cda2/libs/x86_64/cda2.so':
  
dlopen(/Library/Frameworks/R.framework/Resources/library/cda2/libs/x86_64/cda2.so,
6): Symbol not found: __Z12progress_bardd
  Referenced from:
/Library/Frameworks/R.framework/Resources/library/cda2/libs/x86_64/cda2.so
  Expected in: flat namespace
 in /Library/Frameworks/R.framework/Resources/library/cda2/libs/x86_64/cda2.so
ERROR: loading failed



 I think you should use RCPP_FUNCTION_* outside of the extern C block.


OK, thanks.



 However, I believe modules now do a better job than the RCPP_* macros, and
 for example I think you don't need this wrapper:

  // R level wrapper
  RCPP_FUNCTION_3(NumericMatrix, rotation, double phi,
                  double theta, double psi) {
    return wrap(euler(phi, theta, psi));
  }

 You would simply make a module liks this:

 RCPP_MODULE(aladdin){
        using namespace Rcpp ;

        function( rotation, euler ) ;
        function( interaction_matrix, interactionA ) ;
 }

 and then on the R side, you grab the module :

 jasmine - Module( aladdin )
 jasmine$rotation( 1, 2, 3 )
 jasmine$interaction_matrix( ... )


It works brilliantly, thanks! It's so much cleaner.

 Also note that from the most recent version of RcppArmadillo, you don't need
 the Rcpp::as anymore to convert a NumericMatrix to an arma::mat, you can
 just do (I think):

 arma::mat R = IR ;


A quick test failed, but I'll try again with something more minimal to
report. Truth be told, I got lost in the recent discussions on the
best way to pass a real (complex) matrix from R to Armadillo and I've
been meaning to go back to this question.

Thanks,

baptiste


 Romain



 --
 Romain Francois
 Professional R Enthusiast
 +33(0) 6 28 91 30 30
 http://romainfrancois.blog.free.fr
 |- http://bit.ly/cCmbgg : Rcpp 0.8.6
 |- http://bit.ly/bzoWrs : Rcpp svn revision 2000
 `- http://bit.ly/b8VNE2 : Rcpp at LondonR, oct 5th






-- 


Dr. Baptiste Auguié

Departamento de Química Física,
Universidade de Vigo,
Campus Universitario, 36310, Vigo, Spain

tel: +34 9868 18617
http://webs.uvigo.es/coloides

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] r-forge error: undefined symbol: zgetri_

[baptiste auguie]

On 20 August 2010 22:33, Douglas Bates ba...@stat.wisc.edu wrote:
 On Fri, Aug 20, 2010 at 12:35 PM, baptiste auguie
 baptiste.aug...@googlemail.com wrote:
 Hi,

 On 20 August 2010 19:09, Romain Francois rom...@r-enthusiasts.com wrote:
 Le 20/08/10 16:07, Dirk Eddelbuettel a écrit :

 On 20 August 2010 at 09:41, baptiste auguie wrote:
 | Indeed, I had forgotten to rerun roxygen before my last commit, sorry.
 | It should be OK now.
 |
 | I've also put the source tarball from R CMD BUILD here,
 |
 | http://dl.dropbox.com/u/352834/cda_1.0.tar.gz

 This works for me on Ubuntu 10.4 / amd64 once I drop the Depends: on
 the package constants which is not on CRAN:

 e...@max:/tmp/cda$ R CMD INSTALL .
 * installing to library ‘/usr/local/lib/R/site-library’
 * installing *source* package ‘cda’ ...
 ** libs
 g++ -I/usr/share/R/include
 -I/usr/local/lib/R/site-library/Rcpp/include
 -I/usr/local/lib/R/site-library/RcppArmadillo/include   -fpic  -O3 -g0
 -Wall -pipe  -c cda.cpp -o cda.o
 cda.cpp: In function ‘int progress_bar(double, double)’:
 cda.cpp:36: warning: no return statement in function returning non-void
 cda.cpp: In function ‘Rcpp::List linearExtinction(const arma::mat, const
 arma::cx_mat, double)’:
 cda.cpp:285: warning: unused variable ‘pi’
 g++ -shared -o cda.so cda.o -L/usr/local/lib/R/site-library/Rcpp/lib
 -lRcpp -Wl,-rpath,/usr/local/lib/R/site-library/Rcpp/lib -llapack -lblas
 -lgfortran -lm -L/usr/lib64/R/lib -lR
 installing to /usr/local/lib/R/site-library/cda/libs
 ** R
 ** inst
 ** preparing package for lazy loading
 Loading required package: reshape
 Loading required package: plyr
 Loading required package: grid
 Loading required package: proto
 ** help
 *** installing help indices
 ** building package indices ...
 ** testing if installed package can be loaded

 * DONE (cda)
 e...@max:/tmp/cda$ r -lcda -e'cat(Hello cda world\n)'
 Hello cda world
 e...@max:/tmp/cda$

 FWIW on Debian and Ubuntu R uses external lapack and blas libraries.

 Dirk

 That is also why it works on OSX, because here we are using the vecLib
 framework for blas and lapack.


 Thank you all for investigating the matter.


 So you are left with a few options :
 - don't call inv on your complex matrix

 i do need this, I feel it would be a waste to convert the matrix back
 to R format, invert it with R facilities, and then convert it back for
 Armadillo...

 On many occasions where people think that they need to calculate a
 matrix inverse they don't really need to do so.  For example you don't
 need to calculate the inverse explicitly if all you are going to do is
 to solve a linear system of equations.


True, on many occasions. In this particular case, I have to solve many
times (typically more than 400 times) the system Ax = b, with
different right-hand side b. I haven't checked objectively, but my
guess was that calculating the inverse once was to be more efficient
than solving the 400 linear systems. It may depend on the size of the
matrix, etc.

Best,

baptiste


 - negociate with R-core that they include missing lapack bits

 I wouldn't even know what's missing and where.

 - write a package that supplies these bits

 Same here.

 I'm afraid there is nothing we can really do.

 That's OK, thankfully it works on the only platform(s) I use. A shame
 that I can't easily share this work with others though.

 Thanks,

 baptiste

 Romain

 --
 Romain Francois
 Professional R Enthusiast
 +33(0) 6 28 91 30 30
 http://romainfrancois.blog.free.fr
 |- http://bit.ly/bzoWrs : Rcpp svn revision 2000
 |- http://bit.ly/b8VNE2 : Rcpp at LondonR, oct 5th
 `- http://bit.ly/aAyra4 : highlight 0.2-2





 --
 

 Dr. Baptiste Auguié

 Departamento de Química Física,
 Universidade de Vigo,
 Campus Universitario, 36310, Vigo, Spain

 tel: +34 9868 18617
 http://webs.uvigo.es/coloides
 
 ___
 Rcpp-devel mailing list
 Rcpp-devel@lists.r-forge.r-project.org
 https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel





-- 


Dr. Baptiste Auguié

Departamento de Química Física,
Universidade de Vigo,
Campus Universitario, 36310, Vigo, Spain

tel: +34 9868 18617
http://webs.uvigo.es/coloides

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] r-forge error: undefined symbol: zgetri_

[baptiste auguie]

Hi,

My Makevars contains the following line,

## Use the R_HOME indirection to support installations of multiple R version
PKG_LIBS = $(shell $(R_HOME)/bin/Rscript -e Rcpp:::LdFlags() )
$(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)


which I obviously took from somewhere, perhaps automatically generated
from package.skeleton, I don't remember. It's worked for me on two
different machines (both Macs, though).

Best regards,

baptiste


On 19 August 2010 23:50, Douglas Bates ba...@stat.wisc.edu wrote:
 On Thu, Aug 19, 2010 at 3:06 PM, baptiste auguie
 baptiste.aug...@googlemail.com wrote:
 Dear all,

 I'm stumped by this error for my cda package on r-forge:

 Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared library '/tmp/Rinst2710053821/cda/libs/cda.so':
  /tmp/Rinst2710053821/cda/libs/cda.so: undefined symbol: zgetri_

 https://r-forge.r-project.org/R/?group_id=160log=build_srcpkg=cdaflavor=patched


 I don't have a clue what this means --- is this an incorrect
 dependency, an error in my C++ code, a known problem with r-forge,
 something I should have read in a vignette / manual ... ? It compiles
 fine on my machine (Mac OS 10.6). The package uses RcppArmadillo.

 The error means that there is a reference to one of the Lapack
 functions, zgetri, which forms the inverse of a complex matrix using
 its triangular factorization, and the symbol could not be found.  What
 does your cda/src/Makevars file contain?

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] Multiplication of ComplexVector?

[baptiste auguie]

Hi,

On 17 August 2010 10:04, Romain Francois rom...@r-enthusiasts.com wrote:
 Le 17/08/10 10:00, baptiste auguie a écrit :

 On 17 August 2010 09:20, Romain Francoisrom...@r-enthusiasts.com  wrote:

 Le 17/08/10 07:43, baptiste auguie a écrit :

 Hi,

 On 17 August 2010 03:24, Dirk Eddelbuettele...@debian.org    wrote:

 On 16 August 2010 at 19:43, Dirk Eddelbuettel wrote:

 [...]

 The only trouble is that nobody has written the corresponding 'glue'
 code
 to
 make

      arma::cx_vec a1(y1.begin(), y1.size(), false);

 happen: create an Armadillo complex vector from an Rcpp::ComplexVector.
  We
 can init by scalar size, what you'd need to insert for now is a simply
 (and
 very pedestrian) copy-loop.

 I'm confused, isn't

  arma::cx_colvec a1 = Rcpp::as    arma::cx_vec( y1 );

 aimed at doing this kind of conversion? (that's what I use, following
 Romain's tip)

 baptiste

 I don't think you are confused. This works well, but it does require some
 extra copying, which Dirk was trying to spare.

 Using the advanced constructor in armadillo means that both the
 ComplexVector and the cx_vec use the same memory. although it says loud
 and
 clear in armadillo documentation :

 
 This is faster, but can be dangerous unless you know what you're doing!
 


 Thanks. Two questions then,

 1- reinterpret_cast  std::complexdouble*  seems like a good option,
 does it work with real / complex matrices as well? The only things
 that came up from googling it were related to RcppGSL, not
 RcppArmadillo.

 Sure.

 code- '
    ComplexMatrix y1(i), y2(ii);
    arma::cx_mat a1( reinterpret_cast std::complexdouble* (y1.begin()),
 y1.nrow(), y1.ncol(), false);
    arma::cx_mat a2( reinterpret_cast std::complexdouble* (y2.begin()),
 y2.nrow(), y2.ncol(), false);
    return wrap( a1 + a2);
    '
 fun- cxxfunction(signature(i=complex, ii = complex), code,
 plugin=RcppArmadillo)

 x1 - matrix( 1:10*(1+1i), 5, 2 )
 x2 - matrix( 1*1:10*(1+1i), 5, 2 )
 fun( x1, x2 )

 You don't need reinterpret_cast for converting NumericMatrix to a
 Matdouble aka mat because they both use the same type and layout for
 storage : double with column major order layout

Thanks for the nice examples.


 2- when is it not safe? ;)

 When people don't know what they are doing.

Oops, that'd be me :)


 For example : R has no knowledge that armadillo shares the memory with it,
 so if for some reason R thinks it can garbage collect the SEXP that came in
 (i and ii), it won't ask around for permission and so the armadillo
 matrix/vector will contain a pointer to wonderland, and then killing the
 jabbawockee bug is not easy.

 So if all you do is share the memory inside the same function/scope you
 should be fine.


I'll need to get bitten by the bug before I can really absorb the
meaning of this. I basically have no clue as to who owns the data /
pointers, underneath layers of Rcpp and Armadillo.


Thanks,

baptiste
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] use of auxiliary functions

[baptiste auguie]

Thanks for the conclusive example :)

baptiste



On 12 August 2010 21:53, Dirk Eddelbuettel e...@debian.org wrote:

 On 12 August 2010 at 20:59, baptiste auguie wrote:
 | Point well taken, l'll try to use const and const wherever appropriate.

 I am coming to this late (sorry, too much other stuff going on...) but I had
 meant to illustrate the good advise provided by Davor and Romain.  So here is
 a stylized Armadillo examples -- not involving SEXPs as these really are
 pointers which muddles everything.   So here I simply create a matrix and
 ship it to two functions: one uses const ref , one uses copy:

   e...@max:~/src/progs/C++$ ./const_ref_vs_copy_cost
   t0: 2010-Aug-12 14:45:04.526660
   t1: 2010-Aug-12 14:45:04.526731 00:00:00.71
   t2: 2010-Aug-12 14:45:05.054273 00:00:00.527542

 So 71 microsecs versus 527 millisecs.  This uses Boost which gives us nice
 granularity of time on Linux.  On another OS your mileage may vary. The Emacs
 compile-command works for me with Boost and Armadillo in standard
 places. Adjust as necessary.

 And for what it is worth, const whenever possible is item #3 in Effective
 C++ by Meyers, a book Romain and I both cherish.

 Cheers, Dirk


 // -*- compile-command: g++ -s -O3 -Wall -pedantic -pipe -o 
 const_ref_vs_copy_cost const_ref_vs_copy_cost.cpp -lboost_date_time-mt -*-

 #include boost/date_time/posix_time/posix_time.hpp
 #include armadillo
 #include iostream

 using namespace boost::posix_time;              // boost timers
 using namespace boost::gregorian;

 using namespace arma;

 double doSomeMindlessWork_const_ref(const mat  m) {
  int n = m.n_rows;
  int k = m.n_cols;

  return m(0,0) + m(n-1, k-1);
 }

 double doSomeMindlessWork_copy(mat m) {
  int n = m.n_rows;
  int k = m.n_cols;

  return m(0,0) + m(n-1, k-1);
 }


 int main() {
  const int n = 1;

  mat m = mat(n, n);

  ptime t0 = microsec_clock::local_time();
  doSomeMindlessWork_const_ref(m);
  ptime t1 = microsec_clock::local_time();
  doSomeMindlessWork_copy(m);
  ptime t2 = microsec_clock::local_time();

  std::cout  t0:   to_simple_string(t0)  \n
             t1:   to_simple_string(t1) 
 to_simple_string(t1-t0)  \n
             t2:   to_simple_string(t2) 
 to_simple_string(t2-t1)  \n
             std::endl;

  return 0;
 }

 --
 Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com




-- 


Dr. Baptiste Auguié

Departamento de Química Física,
Universidade de Vigo,
Campus Universitario, 36310, Vigo, Spain

tel: +34 9868 18617
http://webs.uvigo.es/coloides

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] use of auxiliary functions

[baptiste auguie]

Point well taken, l'll try to use const and const wherever appropriate.

Thanks,

baptiste




On 11 August 2010 23:55, Davor Cubranic cubra...@stat.ubc.ca wrote:
 As Romain said, there can be some hidden optimization going on, or the
 difference is not significant compared to the cost of the rest of the
 code.

 But C++ best practice would recommend that you write this particular
 function as you did in dum2, not dum1. It may not matter in this case,
 but it would in others. And it's good to be consistent, which will also
 help someone else reading your code. (But you don't have to put
 parentheses around the return statement's argument.)

 Also, making B a constant parameter if it's not supposed to be changed
 inside the function will sooner or later protect you from mistakes. Use
 consts even if you're not comfortable with using references, it's just
 another small bit of help from the compiler.

 Davor


 On August 11, 2010 12:30:05 pm baptiste auguie wrote:
 I think I understand the principle, however with my best effort I
 cannot find a test case. Here I thought I'd be passing an arbitrarily
 large arma matrix to some function, but again the timing is not
 convincing (in fact, I had to stop the execution once with the dummy2
 version),

 using namespace Rcpp ;
 using namespace RcppArmadillo ;

 extern C {

   arma::mat dum1(arma::mat B)
   {
     return (B*38);
   }

   arma::mat dum2(const arma::mat B)
   {
     return (B*38);
   }

   RCPP_FUNCTION_2(NumericMatrix, dummy1, NumericMatrix A, int N) {
     arma::mat B = Rcpp::as arma::mat ( A ) ;
     return wrap(dum1(repmat(B, N, N)));
   }

   RCPP_FUNCTION_2(NumericMatrix, dummy2, NumericMatrix A, int N) {
     arma::mat B = Rcpp::as arma::mat ( A ) ;
     return wrap(dum2(repmat(B, N, N)));
   }

 }




-- 


Dr. Baptiste Auguié

Departamento de Química Física,
Universidade de Vigo,
Campus Universitario, 36310, Vigo, Spain

tel: +34 9868 18617
http://webs.uvigo.es/coloides

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] use of auxiliary functions

[baptiste auguie]

I think I understand the principle, however with my best effort I
cannot find a test case. Here I thought I'd be passing an arbitrarily
large arma matrix to some function, but again the timing is not
convincing (in fact, I had to stop the execution once with the dummy2
version),

using namespace Rcpp ;
using namespace RcppArmadillo ;

extern C {

  arma::mat dum1(arma::mat B)
  {
return (B*38);
  }

  arma::mat dum2(const arma::mat B)
  {
return (B*38);
  }

  RCPP_FUNCTION_2(NumericMatrix, dummy1, NumericMatrix A, int N) {
arma::mat B = Rcpp::as arma::mat ( A ) ;
return wrap(dum1(repmat(B, N, N)));
  }

  RCPP_FUNCTION_2(NumericMatrix, dummy2, NumericMatrix A, int N) {
arma::mat B = Rcpp::as arma::mat ( A ) ;
return wrap(dum2(repmat(B, N, N)));
  }

}

}

Regards,

baptiste


On 11 August 2010 19:21, Davor Cubranic cubra...@stat.ubc.ca wrote:
 On August 11, 2010 02:48:23 am rom...@r-enthusiasts.com wrote:
 Le 10 août 2010 à 22:10, baptiste auguie
 baptiste.aug...@googlemail.com a écrit :
  OK, thanks. I have not been able to produce a minimal code that
  would exhibit an improved performance using this
  passing-by-reference idea.

 Hi,

 It would usually make a difference when copying the object that is
 passed by value is expensive to copy. Rcpp objects are very cheap
 to copy and both copies refer to the same actual data (the same
 SEXP).

 For internal code my recommendation would be to always use pass by
 reference and do an explicit call to clone when a real copy
 (different SEXP) is needed.

 In other words, if you were passing large arma::mat's, then const
 references should make a real difference.

 Davor

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] use of auxiliary functions

[baptiste auguie]

I see –– thanks for the clarification (it is indeed what Dirk really
had suggested, the accidental shortcut was mine). This passing by
reference seems very interesting (I pass several large complex arma
matrices in other functions), but I need to work out how it works
inside the functions.

Thanks again for the precious comments,

baptiste

PS: my package is now on r-forge, hoping to see if it compiles there too:

https://r-forge.r-project.org/scm/viewvc.php/pkg/cda/?root=photonics


On 10 August 2010 01:38, Davor Cubranic cubra...@stat.ubc.ca wrote:
 On 2010-08-07, at 7:03 PM, baptiste auguie wrote:

 Thanks Davor, Douglas and Dirk –– all your comments have been very
 helpful and I used them to improve my code (along with getting a
 better understanding of C++). The only thing I haven't tried yet is
 avoid duplicating the objects in memory using const (seems tricky from
 what I read on the net).

 Using 'const' won't save you from duplicating objects: all it does is mark a 
 variable/parameter as a constant, so that you can't accidentally change it. 
 What does save you from duplication is passing arguments by reference. And 
 passing arguments by reference is often combined with marking them 'const' 
 for safety, because accidentally changing them would introduce wide-ranging 
 bugs into your code that could be difficult to find.

 Also, note that passing by const reference only saves space for complex 
 objects, not primitive types like doubles and consts. So for the 'euler' 
 function you used in your example, it would be recommended to make its 
 signature:

 arma::mat euler(const double phi, const double theta, const double psi);
 In other words, 'phi', 'theta', and 'psi' are doubles, which I'm passing as 
 constants.

 While something like matrix multiply could be:

 arma::mat mul(const arma::mat a, const arma::mat b);
 Here, 'a' and 'b' are matrix objects, which I'm passing by constant reference.

 Hope this helps.

 Davor





-- 


Dr. Baptiste Auguié

Departamento de Química Física,
Universidade de Vigo,
Campus Universitario, 36310, Vigo, Spain

tel: +34 9868 18617
http://webs.uvigo.es/coloides

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

[Rcpp-devel] progress bar in for loop

[baptiste auguie]

Dear list,

There's one feature that I miss after porting a for loop from R to C++
: the possibility to add a progress bar. I used to write,

library(plyr)
l_ply(seq(1,10), function(ii) Sys.sleep(0.2), .progress = text)

My naive attempt in C++ was unsuccessful,

using namespace std;

  cout  [; //start progress bar
  for(ll=0; llN; ll++){ // loop over some variable
if ( !( ((ll+1)*100/N) % 5) ) //  display a character every 5 steps
  cout  =;
  }
  cout  [; //stop progress bar

For some reason (compiler?) nothing is displayed until the end of the
execution, where the full text is suddenly displayed at once. Is there
a workaround?

Best regards,

baptiste
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] progress bar in for loop

[baptiste auguie]

Oops, please ignore my previous request, I found an answer on
StackOverflow. I'm now using this routine,

int progress_bar(double x, double N)
{
// how wide you want the progress meter to be
int totaldotz=40;
double fraction = x / N;
// part of the progressmeter that's already full
int dotz = round(fraction * totaldotz);

// create the meter
int ii=0;
printf(%3.0f%% [,fraction*100);
// part  that's full already
for ( ; ii  dotz;ii++) {
printf(=);
}
// remaining part (spaces)
for ( ; ii  totaldotz;ii++) {
printf( );
}
// and back to line begin - do not forget the fflush to avoid
output buffering problems!
printf(]\r);
fflush(stdout);
}

Sorry for the noise,

baptiste

On 8 August 2010 16:37, baptiste auguie baptiste.aug...@googlemail.com wrote:
 Dear list,

 There's one feature that I miss after porting a for loop from R to C++
 : the possibility to add a progress bar. I used to write,

 library(plyr)
 l_ply(seq(1,10), function(ii) Sys.sleep(0.2), .progress = text)

 My naive attempt in C++ was unsuccessful,

 using namespace std;

  cout  [; //start progress bar
  for(ll=0; llN; ll++){ // loop over some variable
    if ( !( ((ll+1)*100/N) % 5) ) //  display a character every 5 steps
      cout  =;
  }
  cout  [; //stop progress bar

 For some reason (compiler?) nothing is displayed until the end of the
 execution, where the full text is suddenly displayed at once. Is there
 a workaround?

 Best regards,

 baptiste

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] use of auxiliary functions

[baptiste auguie]

Thanks Davor, Douglas and Dirk –– all your comments have been very
helpful and I used them to improve my code (along with getting a
better understanding of C++). The only thing I haven't tried yet is
avoid duplicating the objects in memory using const (seems tricky from
what I read on the net).

All the best,

baptiste


On 8 August 2010 03:21, Davor Cubranic cubra...@stat.ubc.ca wrote:
 On August 6, 2010 02:44:00 pm Douglas Bates wrote:
 On Fri, Aug 6, 2010 at 3:14 PM, baptiste auguie

   arma::mat euler(double phi, double theta, double psi)
   {
     arma::mat Rot(3,3);
     Rot(0,0) = cos(psi)*cos(phi) - cos(theta)*sin(phi)*sin(psi);
     Rot(0,1) = cos(psi)*sin(phi) + cos(theta)*cos(phi)*sin(psi);
     Rot(0,2) = sin(psi)*sin(theta);
 
     Rot(1,0) = -sin(psi)*cos(phi) - cos(theta)*sin(phi)*cos(psi);
     Rot(1,1) = -sin(psi)*sin(phi) + cos(theta)*cos(phi)*cos(psi);
     Rot(1,2) = cos(psi)*sin(theta);
 
     Rot(2,0) = sin(phi)*sin(theta);
     Rot(2,1) = -cos(phi)*sin(theta);
     Rot(2,2) = cos(theta);
     return (Rot);
   }

 It is probably not a big deal now but you are recalculating the same
 trigonometric functions several times in there.  Why not calculate
 the cos and sin of the each of the angles just once and then form
 the elements of the rotation matrix as linear combinations?  (Once
 upon a time we used to keep track of every floating point
 calculation and try to work out ways to minimize that number.)

 True, but I wonder whether in this case any modern compiler will catch
 the common intermediate calculations and optimize them for you so that
 they're only calculated once.

 Easy enough to check with gcc and its '-s' argument, which will give you
 the assembly output. :-)

 Davor




-- 


Dr. Baptiste Auguié

Departamento de Química Física,
Universidade de Vigo,
Campus Universitario, 36310, Vigo, Spain

tel: +34 9868 18617
http://webs.uvigo.es/coloides

___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

Re: [Rcpp-devel] RcppMAtrixcomplex ?

[baptiste auguie]

Thank you both for the valuable info, I am looking forward to trying
this out as soon as I can (i've had no time in the past few days).

All the best,

baptiste


On 26 April 2010 10:09, Romain Francois rom...@r-enthusiasts.com wrote:
 And now, with the new macros (see the thread [Rcpp-devel] any
 preprocessor expert around ? ), one can write the function as:

 #include RcppArmadillo.h
 using namespace Rcpp ;

 RCPP_FUNCTION_2( arma::mat, add_mat,
        arma::mat y, arma::mat x ){

        arma::mat result = x+y;
        return result ;
 }

 although in this case x and y would be copies of the R data, so it would
 be less efficient than your code.

 Romain

 Le 23/04/10 19:55, Davor Cubranic a écrit :

 Baptiste,

 Do have a look at RcppArmadillo, it makes matrix code very easy to write
 (and read!). For example, this is a function callable from R to add two
 matrices:

 #includeRcppArmadillo.h

 using namespace Rcpp;

 RcppExport SEXP add_mat(SEXP y_in,
                       SEXP x_in) {
    NumericMatrix y_r(y_in);
    arma::mat y(y_r.begin(), y_r.nrow, y_r.ncol(), false);

    NumericMatrix x_r(x_in);
    arma::mat x(x_r.begin(), x_r.nrow(), x_r.ncol(), false);

    arma::mat result = x+y;
    return wrap(result);
 }

 In this case, the matrices are real, not complex. but I believe simply
 replacing 'arma::mat' with 'arma::cx_mat' and 'NumericMatrix' with
 'ComplexMatrix' will work for the complex case.

 Davor


 On April 22, 2010 01:22:58 pm baptiste auguie wrote:
 OK, thanks for the information. I guess I was lead to believe that
 such operations were of common use because I worked previously with
 colleagues who had defined their own C++ complex class (and I'm
 guessing it was precisely for this purpose of operator overloading).
 Sadly the code was not open source. I'll look into armadillo,
 hopefully it provides an alternative. I might also need to rethink
 what portion of the code I should really be porting out of R; this
 function was clearly the bottleneck of my code but it looks like it
 will be painful to write it in a lower-level language.

 Thanks,

 baptiste

 On 22 April 2010 18:42, Romain Francoisrom...@r-enthusiasts.com
 wrote:
 Le 22/04/10 18:19, baptiste auguie a écrit :
 Thanks for the example, it is useful indeed. However, I am having
 difficulties with operations involving whole matrices, rather than
 matrix elements.

 We don't currently have those.

 Again I must warn that I don't know C++ ; but the
 addition of two matrices does not seem to work out-of-the-box, as
 well as more complicated functions. The dispatch of these
 functions might not exist for the complex matrix class, or maybe
 it is not implemented in Rcpp?

 The operations I would need to perform with complex matrices are,

 +, -, *, transpose,
 as well as operations on 1-column and one-row matrices (==
 vectors?) such as exp().

 Those are things you'd typically do in R, not in C/C++

 Working component by component is not a very attractive option

 That is what you usually do in a C/C++ world

 so I'm
 hoping there is an easy way to define operations between matrices,
 matrices and vectors, and matrices and scalars.

 One thing you can do perhaps is look into armadillo, which we wrap
 nicely with the RcppArmadillo package. and thanks to Doug, the
 wrapping is even nicer now since armadillo is packed up inside
 RcppArmadillo (but this version is not released yet).

 We will not implement these operators soon because it is very easy
 to not do it right. armadillo does it nicely.

 Thanks,

 baptiste

 PS: The problem with my previous email was in the gmail vs.
 googlemail domain, as Dirk pointed out (I had had that same
 problem before, but I forgot!).

 On 22 April 2010 13:17, Romain Francoisrom...@r-enthusiasts.com
   wrote:
 Thank you for reposting here.

 It is not trivial to see what is happening in your example, so
 I'll just give you some tools.

 The old api (which the classicRcppMatrixExample example uses)
 does not have
 support for complex vectors or matrices.

 The new api does have support for complex vectors and complex
 matrices. The
 unit test file runit.ComplexVector.R does indeed contain some
 very basic examples of using ComplexVector, but not complex
 matrices. However, you can
 use Rcpp::ComplexMatrix.

 Here is an example that calculates the sum of the real part of
 the elements
 of a complex matrix diagonal and the sum of the imaginary part:

 require( Rcpp )
 require( inline)

 fx- cfunction( signature( x = matrix ), '
         /* grab the R object as a complex matrix */
         ComplexMatrix m(x) ;
         double re_sum = 0.0 ;
         double im_sum = 0.0 ;
         for( int i=0; im.ncol(); i++){
                 re_sum += m(i,i).r ;
                 im_sum += m(i,i).i ;
         }
         return List::create(
                 _[sum real part] = re_sum,
                 _[sum imag part] = im_sum
                 ) ;

 ', Rcpp = TRUE, includes = using namespace Rcpp; )

 x- diag( (1-2i

[Rcpp-devel] RcppMAtrixcomplex ?

[baptiste auguie]

Dear all,

I'm hoping to port some R code to C++ to make it faster. The code
makes heavy use of matrices of complex numbers, and playing with the
RcppExamples package this morning I got the impression that it's not
currently implemented in Rcpp. I basically took the example from
classicRcppMatrixExample and tried to change the types from double to
complex. I must confess that I don't know C++, so maybe I missed
something obvious.

Attached is my dummy example, as well as the R code I'm trying to port
to give you an idea. Any suggestions would be greatly appreciated!

Best regards,

baptiste


PS: This message initially failed to reach the list; in the meantime I
got the suggestion from Romain and Dirk to have a look at the class
Rcpp::ComplexMatrix and the example in runit.ComplexVector.R


interactionA.R
Description: Binary data


RcppInlineExample.r
Description: Binary data
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel