Re: [Rcpp-devel] trans() changed in latest RcppArmadillo
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] [Rd] Interfacing a C++ class
On 06.06.2011, at 13:42, Romain Francois wrote:
Le 04/06/11 16:31, soeren.vo...@uzh.ch a écrit :
FOO is the C++ object, and Foo should be the S4 class. If the user creates
an object, say bar, from class Foo, the creation process automatically makes
a new FOO object relating to bar in that a unique name of the FOO instance
is stored in a slot of bar. All the user then has to do is modify bar by
simple assignments. The getters and setters ($, [) are set up and work.
Each modification goes in hand with assigning new values to bar as well as
updating the FOO object through available setters from FOO.
So far, this way has brought me to about 100 lines, but now I read about
ReferenceClasses and was wondering, if there is a much easier way of
achieving my goals. Moreover, I was not sure any longer if my goals make
sense or if a more advanced programmer would do it totally different (and
could share some structural thinking on their approach).
The idea behind my way of doing was based upon several considerations.
First, a classical R object would not confuse users, as I assume users of
my package to be rather non-skilled (and not willing to change that).
Second, I want to create a properly programmed package for distribution on
CRAN and publication, eventually. Third, I want to save objects across
sessions. So if a user restores a session, a simple command, say, restore(),
would do the trick to build all the related C++ objects again. However, I
admit that I still have not figured out how to automatically clean up the
workspace correctly before leaving a session, wanted or unwanted, that is,
clean up memory before leaving home. Fourth, pure arithmetic check is done
in C++, however, semantic check *should* be left to R, and the validity and
class routines seem to be perfect for this. Fifth, some work should be done
in R, such as the passing of data frames or samples from distributions.
Hello,
A C++ class that is exposed through an Rcpp module is already a reference
class, and so you can add methods, etc ...
Consider this example :
require(inline)
require(Rcpp)
fx - cxxfunction( , '', includes = '
class FOO{
public:
FOO( double x_, double y_): x(x_), y(y_){}
double x ;
double y ;
void move( double dx, double dy){
x += dx ;
y += dy ;
}
} ;
RCPP_MODULE(mod){
class_FOO(FOO )
.constructordouble,double()
.field( x, FOO::x )
.field( y, FOO::y )
.method( move, FOO::move )
;
}
', plugin = Rcpp )
mod - Module( mod, getDynLib(fx),mustStart = TRUE )
# grab the exposed C++ class
FOO - mod$FOO
# add R methods
FOO$methods(
bla = function() x+y,
reset = function() {
x - 0.0
y - 0.0
}
)
# create an instance
f - new( FOO, 2.0, 3.0 )
# call an R method
f$reset()
# call a C++ method
f$move( 2.0, 2.0 )
# call an R method
f$bla()
Thanks Simon and Romain for your great help! That C++ classes exposed via
Rcpp-modules are already reference classes helps a lot and saves time for
unnecessary mirroring. According to Romain saving class objects across sessions
remains to be implemented in Rcpp. I have not browsed the rJava package
extensively, but I found serialize() (base) and this function seems to provide
a workaround. Yet, I do not know how to use it in practice with my package.
Some thoughts: consider the small FOO example below. Then, on accidental crash
or quit(save=yes), or whatever users may do, R should know that it has to
serialise all existing FOO objects. Note, that in my package these objects are
sort of lists that can become quite large (say, a vector of 15,000 numeric
values plus a character string). After restoring a previously saved image, R
should know to load my package, and that in turn should deserialise every FOO
object present in the image. Sounds like a not too complicated task, something
like .dofirst()/.dolast() -- but that again exceeds my R and C++ programming
skills, and I hope that you experts may share an idea. Thanks, Sören
___
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] redimension help
I want you guys to know that I appreciate all the effort that you put
into the Rcpp package and this list. I am obviously one of the early
people to hurdle the new lowered bar for C++ development in R.
I have developed a function that builds a series of vectors and a matrix
of undetermined size. Rather than attempt dynamic objects (which I
wouldn't know how to do anyway) I have been able to initialize with row
dimensions that cannot be exceeded on these objects. I expect that code
that merely assigns values to these addresses will run faster than code
that must allocate space for each row entry anyway. But, at the end of
the process, my code realizes the true extent of these objects. It
would be really nice to clean these up before return to R.
I am aware of a Dimension class, but really don't know how to go about
using this in this case.
For the vectors it was relatively simple to execute a loop of erase()
methods:
// this works perfectly
for(int t=newTimes.size()-1; trow;t--) {
newTimes.erase(t);
}
Alas, for the Rcpp::IntegerMatrix this was not so easy.
Rcpp::IntegerMatrix opd (exists and has been populated)
for(int v=0; vnum_opl v++) {
for(int t=newTimes.size()-1; trow;t--) {
opd(_,0).erase(t);
}
}
This results in the compiler error: 'struct Rcpp::Matrix13::Column'
has no member named 'erase'
I'm sorry, but I am stuck.
___
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] returning pointers in module methods
Hello,
I've added a few things in modules to extend the possibilities of return
types from a method that is exposed.
So, it is now possible for a method to return a pointer to an other (or
the same) class. There is a small example below.
Here we expose two classes FOO and Bar. The interesting bits are the
methods clone and mult in FOO and the method make_foo in Bar.
The return type is resultT instead of T*, but the method should return
a T*, i.e. the result template class looks like this:
template typename T
class result {
public:
result( T* ptr_ ) : ptr(ptr_){}
operator T*(){ return ptr ; }
private:
T* ptr;
} ;
As usual when we come up with new features, please try them, and send
feedback. Maybe you feel result is not a good name, maybe you have
another idea, ...
Romain
require(inline)
require(Rcpp)
fx - cxxfunction( , '', includes = '
class FOO{
public:
FOO( double x_, double y_): x(x_), y(y_){}
double x ;
double y ;
void move( double dx, double dy){
x += dx ;
y += dy ;
}
resultFOO clone(){
return new FOO(x,y) ;
}
resultFOO mult(double z){
return new FOO(z*x,z*y) ;
}
} ;
class Bar {
public:
Bar( double x_ ) : x(x_){}
double x ;
resultFOO make_foo(){
return new FOO(x,x) ;
}
} ;
RCPP_MODULE(mod){
class_FOO(FOO )
.constructordouble,double()
.field( x, FOO::x )
.field( y, FOO::y )
.method( move, FOO::move )
.method( clone, FOO::clone )
.method( mult, FOO::mult )
;
class_Bar(Bar)
.constructordouble()
.field( x, Bar::x )
.method( make_foo, Bar::make_foo )
;
}
', plugin = Rcpp )
mod - Module( mod, getDynLib(fx),mustStart = TRUE )
# grab the exposed C++ class
FOO - mod$FOO
Bar - mod$Bar
f - new( FOO, 2, 3 )
g - f$clone()
h - f$mult(2)
b - new( Bar, 2 )
z - b$make_foo()
z$x
z$y
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/kaSV6U : Stand up set at Up The Creek
|- http://bit.ly/hdKhCy : Rcpp article in JSS
`- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
___
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] Create an instance of a reference class for a C++ class exported as a module from within C++?
Le 02/06/11 22:31, Douglas Bates a écrit :
Sorry for the long subject line but I hope it describes what I want to
do. I have a C++ class, dgTMatrix, that is exported in a module
definition.
RCPP_MODULE(RcppSp) {
...
class_dgCMatrix(dgCMatrix)
...
;
}
Many of the methods for this class return other members of this class.
Can I create a new instance of the reference class in R from within
the module? I'm sure it is possible, I'm just wondering if there is
an easy way to do this without duplicating large chunks of the code in
Rcpp/src/Module.cpp. Can i somehow clone the SEXP representing the
current instance then swap the external pointer to the C++ object?
As part of the changes I've made today [see the post returning pointers
in module methods ], there is this function you might be interested in
(in Module.h):
namespace internal {
template typename Class
SEXP make_new_object( Class* ptr ){
Rcpp::XPtrClass xp( ptr, true ) ;
Function maker = Environment::Rcpp_namespace()[ cpp_object_maker] ;
return maker( typeid(Class).name() , xp ) ;
}
}
Maybe I should make it more public (i.e not have it in internal).
Anyway, if you give this function a pointer to an instance of a class
that has been exposed through modules, it will create the associated R
ref class object.
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/kaSV6U : Stand up set at Up The Creek
|- http://bit.ly/hdKhCy : Rcpp article in JSS
`- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
___
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] returning pointers in module methods
Now, obviously, the next (perhaps more complicated) step is to allow
pointers as inputs.
This is a task for another day ...
Le 07/06/11 15:35, Romain Francois a écrit :
Hello,
I've added a few things in modules to extend the possibilities of return
types from a method that is exposed.
So, it is now possible for a method to return a pointer to an other (or
the same) class. There is a small example below.
Here we expose two classes FOO and Bar. The interesting bits are the
methods clone and mult in FOO and the method make_foo in Bar.
The return type is resultT instead of T*, but the method should return
a T*, i.e. the result template class looks like this:
template typename T
class result {
public:
result( T* ptr_ ) : ptr(ptr_){}
operator T*(){ return ptr ; }
private:
T* ptr;
} ;
As usual when we come up with new features, please try them, and send
feedback. Maybe you feel result is not a good name, maybe you have
another idea, ...
Romain
require(inline)
require(Rcpp)
fx - cxxfunction( , '', includes = '
class FOO{
public:
FOO( double x_, double y_): x(x_), y(y_){}
double x ;
double y ;
void move( double dx, double dy){
x += dx ;
y += dy ;
}
resultFOO clone(){
return new FOO(x,y) ;
}
resultFOO mult(double z){
return new FOO(z*x,z*y) ;
}
} ;
class Bar {
public:
Bar( double x_ ) : x(x_){}
double x ;
resultFOO make_foo(){
return new FOO(x,x) ;
}
} ;
RCPP_MODULE(mod){
class_FOO(FOO )
.constructordouble,double()
.field( x, FOO::x )
.field( y, FOO::y )
.method( move, FOO::move )
.method( clone, FOO::clone )
.method( mult, FOO::mult )
;
class_Bar(Bar)
.constructordouble()
.field( x, Bar::x )
.method( make_foo, Bar::make_foo )
;
}
', plugin = Rcpp )
mod - Module( mod, getDynLib(fx),mustStart = TRUE )
# grab the exposed C++ class
FOO - mod$FOO
Bar - mod$Bar
f - new( FOO, 2, 3 )
g - f$clone()
h - f$mult(2)
b - new( Bar, 2 )
z - b$make_foo()
z$x
z$y
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
http://romain-francois.com
|- http://bit.ly/kaSV6U : Stand up set at Up The Creek
|- http://bit.ly/hdKhCy : Rcpp article in JSS
`- http://bit.ly/elZJRJ : Montpellier Comedie Club - Avril 2011
___
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
Hello Dr. Sanderson, I find no issues in RcppArmadillo 0.2.22. In fact, I was unable to reproduce the error (under 0.2.21) I found via a simple example; in my case, a simple Bayesian regression routine with unknown variances. I continue to experience a transient error that I believe derives from my end and is unrelated to Armadillo; in particular, the inversion of a matrix becomes numerically unstable, causing a crash of an MCMC routine. The error event is rare and I have been unable to duplicate it in a systematic way by running 100's of monte carlo simulations. When the error event does occur, however, successive runs will all error out unless I re-load the library which re-sets the random seed. I built a multivariate Gaussian random number generator that uses arma structures in which I use randn() that is where the error manifests. Terrance -Original Message- From: Conrad Sand [mailto:conradsand.r...@gmail.com] Sent: Monday, June 06, 2011 8:53 AM To: baptiste auguie Cc: Savitsky, Terrance; rcpp-de...@r-forge.wu-wien.ac.at Subject: Re: [Rcpp-devel] trans() changed in latest RcppArmadillo 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. __ 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] Are c++ vector types provided by Rccp real c++ type?
Hi,
I am a new user of Rccp. I've been trying to understand since 2 weeks how
I'll be able to convert a Splus library constructed with multiple C++
functions (and files) into a nice and free R package.
My question seems basic to me but I'll let you judge I get this error
message:
interface.cpp: In function 'SEXPREC* CreateObjectGen(SEXPREC*, SEXPREC*, S
EXPREC*, SEXPREC*)':
interface.cpp:115:87: error: cannot convert 'Rcpp::FastRcpp::Vector14 '
to
'int*' for argument '1' to 'int CompGen(int*, int*, int*, int*, int*, int*,
int*, int*, int*)'
Do this mean I have to modify every function I am calling from inside
another c++ function? Is it possible?
Here I have this code:
__
#includeoutils.h // 'outils.cpp' is the place where the function CompGen()
is
#include interface.h
#include stdlib.h
using namespace Rcpp ;
RcppExport SEXP CreerObjetGen(SEXP SInd,SEXP SPere, SEXP SMere, SEXP SSexe)
{
STARTTIMER;
NumericVector xSInd(SInd), xSPere(SPere), xSMere(SMere),
xSSexe(SSexe);
FastNumericVector fSIndividu(xSIndividu), fSPere(xSPere),
fSMere(xSMere) , fSSexe(xSSexe);
CompGen(fSInd,fSPere,fSMere,fSSexe,fInd,fpere,fmere,fsexe,lNIndividu);
// the 2nd function I called...
__
I used to have this before I had to change them to types provided by Rccp
(NumericVector):
int* plIndividu=INTEGER_POINTER(AS_INTEGER(SIndividu));
int* plPere=INTEGER_POINTER(AS_INTEGER(SPere));
etc...
I've also read the last post on the list... is it because I can't send
pointers through a function?
thanks for the help,
Héloïse
--
Héloïse Gauvin
PhD student, Epidemiology
___
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] Wrapping uBlas Matrices into Rcpp Matrices
On Mon, Jun 6, 2011 at 6:55 AM, Romain Francois
rom...@r-enthusiasts.com wrote:
Le 02/06/11 14:43, Cedric Ginestet a écrit :
Hi again,
I have tried to do the same for Matrices. Here my naive attempt:
template typename T
Rcpp::Matrix Rcpp::traits::r_sexptype_traitsT::rtype
ublas2rcpp( const matrixT x ){
return Rcpp::Matrix Rcpp::traits::r_sexptype_traitsT::rtype (
x.begin(), x.end()
);
}
//
Obviously that doesn't work, and I get the following error message:
templatedFunction.h:63:5: error: ‘const class
boost::numeric::ublas::matrixint’ has no member named ‘begin’
templatedFunction.h:63:5: error: ‘const class
boost::numeric::ublas::matrixint’ has no member named ‘end’
I suppose that I either need to 'vectorized' the matrices or to run
through both set of row and column indices. What is the best way to do so?
Best wishes,
Cedric
Again untested, but you might like this constructor from Rcpp::Matrix:
template typename Iterator
Matrix( const int nrows_, const int ncols, Iterator start ) :
VECTOR( start, start + (nrows_*ncols) ),
nrows(nrows_)
{
VECTOR::attr( dim ) = Dimension( nrows, ncols ) ;
}
So you'd use it something like this:
template typename T
Rcpp::Matrix Rcpp::traits::r_sexptype_traitsT::rtype
ublas2rcpp( const matrixT x ){
return Rcpp::Matrix Rcpp::traits::r_sexptype_traitsT::rtype (
x.size1(), x.size2(), x.begin1()
);
}
This is untested by guessing what would do the functions found in the
documentation of uBlas:
http://www.boost.org/doc/libs/1_42_0/libs/numeric/ublas/doc/matrix.htm
I haven't looked much at the dense matrix structures in ublas but the
sparse matrix templated classes have many arguments with default
values. The contents can be represented in different types of vector
structures for which the default is the ublas::unbounded_arrayT
structure. However, you can use a std::vectorT instead - they just
feel that their unbounded_array template, which is slightly less
general than a std::vector template, will be more efficient.
So the first step is either to wrap the different ublas vector
structures or to use typedef's to specialize the matrix templates to
use column major dense representations with storage through
std::vector objects.
Romain
On 01/06/11 14:14, Romain Francois wrote:
Le 01/06/11 14:28, Cedric Ginestet a écrit :
Dear Romain,
Thank you very much for your help. I tried what you suggested by
including the following templated function in templatedFunction.h, as
follows:
template typename T
Rcpp::Vector Rcpp::traits::r_sexptype_traitsT::rtype
ublas2rcpp( const vectorT x ){
return Rcpp::Vector r_sexptype_traitsT::rtype (
x.begin(), x.end()
) ;
}
In addition, I have tested the function using in subgraph.cpp:
Rcpp::Vectorint xY = ublas2rcpp(Y);
And I got the following error messages:
templatedFunction.h: In function
‘Rcpp::VectorRcpp::traits::r_sexptype_traitsT::rtype
ublas2rcpp(const boost::numeric::ublas::vectorT)’:
templatedFunction.h:50:26: error: ‘r_sexptype_traits’ was not declared
in this scope
templatedFunction.h:50:45: error: template argument 1 is invalid
subgraph.cpp: In function ‘SEXPREC* cxx_Mask2Graph(SEXPREC*, SEXPREC*,
SEXPREC*, SEXPREC*)’:
subgraph.cpp:32:19: error: type/value mismatch at argument 1 in template
parameter list for ‘templateint RTYPE class Rcpp::Vector’
subgraph.cpp:32:19: error: expected a constant of type ‘int’, got ‘int’
subgraph.cpp:32:24: error: invalid type in declaration before ‘=’ token
subgraph.cpp:32:38: error: invalid conversion from ‘SEXPREC*’ to ‘int’
subgraph.cpp:34:8: error: invalid conversion from ‘int’ to ‘SEXPREC*’
...
Sure. This was a typo/thinko: go with something like this :
template typename T
Rcpp::Vector Rcpp::traits::r_sexptype_traitsT::rtype
ublas2rcpp( const vectorT x ){
return Rcpp::Vector Rcpp::traits::r_sexptype_traitsT::rtype (
x.begin(), x.end()
) ;
}
and Rcpp::Vectorint makes no sense, you probably want IntegerVector,
or (the same class):
Rcpp::Vector r_sexptype_traitsint::rtype
Rcpp::Vector is templated by the SEXP type.
Also, as an aside, I was wondering what I should use instead of
push_back for Rcpp Vectors. Do I necessarily have to specify the size of
the vector before I assign its elements to specific values?
That is much better yes. ublas probably gives a way to access the size
of the vector.
Thanks a lot,
Cedric
On 01/06/11 11:44, Romain Francois wrote:
Hi,
I've not used uBlas, but what you are trying to do is quite similar to
what we do in RcppArmadillo.
You can probably manage to guess the output type from the input type,
so you only have to parameterise your template on the input type.
something like (untested) :
template typename T
Rcpp::Vector
Re: [Rcpp-devel] Wrapping uBlas Matrices into Rcpp Matrices
On Tue, Jun 7, 2011 at 11:15 AM, Douglas Bates ba...@stat.wisc.edu wrote:
On Mon, Jun 6, 2011 at 6:55 AM, Romain Francois
rom...@r-enthusiasts.com wrote:
Le 02/06/11 14:43, Cedric Ginestet a écrit :
Hi again,
I have tried to do the same for Matrices. Here my naive attempt:
template typename T
Rcpp::Matrix Rcpp::traits::r_sexptype_traitsT::rtype
ublas2rcpp( const matrixT x ){
return Rcpp::Matrix Rcpp::traits::r_sexptype_traitsT::rtype (
x.begin(), x.end()
);
}
//
Obviously that doesn't work, and I get the following error message:
templatedFunction.h:63:5: error: ‘const class
boost::numeric::ublas::matrixint’ has no member named ‘begin’
templatedFunction.h:63:5: error: ‘const class
boost::numeric::ublas::matrixint’ has no member named ‘end’
I suppose that I either need to 'vectorized' the matrices or to run
through both set of row and column indices. What is the best way to do so?
Best wishes,
Cedric
Again untested, but you might like this constructor from Rcpp::Matrix:
template typename Iterator
Matrix( const int nrows_, const int ncols, Iterator start ) :
VECTOR( start, start + (nrows_*ncols) ),
nrows(nrows_)
{
VECTOR::attr( dim ) = Dimension( nrows, ncols ) ;
}
So you'd use it something like this:
template typename T
Rcpp::Matrix Rcpp::traits::r_sexptype_traitsT::rtype
ublas2rcpp( const matrixT x ){
return Rcpp::Matrix Rcpp::traits::r_sexptype_traitsT::rtype (
x.size1(), x.size2(), x.begin1()
);
}
This is untested by guessing what would do the functions found in the
documentation of uBlas:
http://www.boost.org/doc/libs/1_42_0/libs/numeric/ublas/doc/matrix.htm
I haven't looked much at the dense matrix structures in ublas but the
sparse matrix templated classes have many arguments with default
values. The contents can be represented in different types of vector
structures for which the default is the ublas::unbounded_arrayT
structure. However, you can use a std::vectorT instead - they just
feel that their unbounded_array template, which is slightly less
general than a std::vector template, will be more efficient.
So the first step is either to wrap the different ublas vector
structures or to use typedef's to specialize the matrix templates to
use column major dense representations with storage through
std::vector objects.
If you check the types overview,
http://www.boost.org/doc/libs/1_46_1/libs/numeric/ublas/doc/types_overview.htm,
you will see that you need to specify column-major ordering (default
is row-major) to be able to map a ublas matrix to an R matrix
structure.
Romain
On 01/06/11 14:14, Romain Francois wrote:
Le 01/06/11 14:28, Cedric Ginestet a écrit :
Dear Romain,
Thank you very much for your help. I tried what you suggested by
including the following templated function in templatedFunction.h, as
follows:
template typename T
Rcpp::Vector Rcpp::traits::r_sexptype_traitsT::rtype
ublas2rcpp( const vectorT x ){
return Rcpp::Vector r_sexptype_traitsT::rtype (
x.begin(), x.end()
) ;
}
In addition, I have tested the function using in subgraph.cpp:
Rcpp::Vectorint xY = ublas2rcpp(Y);
And I got the following error messages:
templatedFunction.h: In function
‘Rcpp::VectorRcpp::traits::r_sexptype_traitsT::rtype
ublas2rcpp(const boost::numeric::ublas::vectorT)’:
templatedFunction.h:50:26: error: ‘r_sexptype_traits’ was not declared
in this scope
templatedFunction.h:50:45: error: template argument 1 is invalid
subgraph.cpp: In function ‘SEXPREC* cxx_Mask2Graph(SEXPREC*, SEXPREC*,
SEXPREC*, SEXPREC*)’:
subgraph.cpp:32:19: error: type/value mismatch at argument 1 in template
parameter list for ‘templateint RTYPE class Rcpp::Vector’
subgraph.cpp:32:19: error: expected a constant of type ‘int’, got ‘int’
subgraph.cpp:32:24: error: invalid type in declaration before ‘=’ token
subgraph.cpp:32:38: error: invalid conversion from ‘SEXPREC*’ to ‘int’
subgraph.cpp:34:8: error: invalid conversion from ‘int’ to ‘SEXPREC*’
...
Sure. This was a typo/thinko: go with something like this :
template typename T
Rcpp::Vector Rcpp::traits::r_sexptype_traitsT::rtype
ublas2rcpp( const vectorT x ){
return Rcpp::Vector Rcpp::traits::r_sexptype_traitsT::rtype (
x.begin(), x.end()
) ;
}
and Rcpp::Vectorint makes no sense, you probably want IntegerVector,
or (the same class):
Rcpp::Vector r_sexptype_traitsint::rtype
Rcpp::Vector is templated by the SEXP type.
Also, as an aside, I was wondering what I should use instead of
push_back for Rcpp Vectors. Do I necessarily have to specify the size of
the vector before I assign its elements to specific values?
That is much better yes. ublas probably gives a way to access the size
of the vector.
Thanks a lot,
Cedric
On 01/06/11 11:44, Romain Francois
Re: [Rcpp-devel] Strange compiler error when using boost uBLAS on Ubuntu 11.04
Sorry to take so long to respond. On Sat, Jun 4, 2011 at 12:26 PM, Dirk Eddelbuettel e...@debian.org wrote: On 4 June 2011 at 11:52, Douglas Bates wrote: | With | | sessionInfo() | R version 2.14.0 Under development (unstable) (2011-05-26 r55995) | Platform: x86_64-unknown-linux-gnu (64-bit) | | locale: | [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C | [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 | [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 | [7] LC_PAPER=C LC_NAME=C | [9] LC_ADDRESS=C LC_TELEPHONE=C | [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C | | attached base packages: | [1] stats graphics grDevices utils datasets methods base | | other attached packages: | [1] Rcpp_0.9.4.1 inline_0.3.8 | | loaded via a namespace (and not attached): | [1] tools_2.14.0 | | and | | $ g++ --version | g++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 | $ wajig list libboost-dev | ii libboost-dev 1.42.0.1ubuntu1 | Boost C++ Libraries development files (default version) | | I get a strange compiler error when trying to compile the Hello | World example of the coordinate_matrix representation from Boost's | uBLAS, as shown in the enclosed. The first two examples (the | mapped_matrix and the compressed_matrix) compile for me but the third | and the fourth don't. The error I get is | | Error in compileCode(f, code, language = language, verbose = verbose) : | Compilation ERROR, function(s)/method(s) not created! In file | included from /usr/include/c++/4.5/bits/stl_algo.h:63:0, | from /usr/include/c++/4.5/algorithm:63, | from | /home/bates/R/x86_64-unknown-linux-gnu-library/2.14/Rcpp/include/RcppCommon.h:121, | from | /home/bates/R/x86_64-unknown-linux-gnu-library/2.14/Rcpp/include/Rcpp.h:27, | from file6b444b24.cpp:4: | /usr/include/c++/4.5/bits/stl_tempbuf.h: In constructor | ‘std::_Temporary_buffer_ForwardIterator, | _Tp::_Temporary_buffer(_ForwardIterator, _ForwardIterator) [with | _ForwardIterator = | boost::numeric::ublas::indexed_iteratorboost::numeric::ublas::index_triple_arraystd::vectorlong | unsigned int, std::vectorlong unsigned int, std::vectordouble , | std::random_access_iterator_tag, _Tp = | boost::numeric::ublas::index_tripleboost::numeric::ublas::index_triple_arraystd::vectorlong | unsigned int, std::vectorlong unsigned int, std::vectordouble | ]’: | /usr | In addition: Warning message: | running command '/home/bates/build/R-devel/bin/R CMD SHLIB | file6b444b24.cpp 2 file6b444b24.cpp.err.txt' had status 1 | | Do others get this error for other versions of boost or other compilers? Yes, confirmed. Examples one and two build, three and four puke. Can you try them without Rcpp to see if there is a side-effect? I did so. Trying to compile the example section of http://www.boost.org/doc/libs/1_46_1/libs/numeric/ublas/doc/matrix_sparse.htm#coordinate_matrix produces $ g++ -O3 -g0 foo.cpp -o foo In file included from /usr/include/c++/4.5/bits/stl_algo.h:63:0, from /usr/include/c++/4.5/algorithm:63, from /usr/include/boost/utility/swap.hpp:24, from /usr/include/boost/swap.hpp:10, from /usr/include/boost/array.hpp:37, from /usr/include/boost/serialization/array.hpp:26, from /usr/include/boost/numeric/ublas/storage_sparse.hpp:19, from /usr/include/boost/numeric/ublas/vector_sparse.hpp:16, from /usr/include/boost/numeric/ublas/matrix_sparse.hpp:16, from foo.cpp:1: /usr/include/c++/4.5/bits/stl_tempbuf.h: In constructor ‘std::_Temporary_buffer_ForwardIterator, _Tp::_Temporary_buffer(_ForwardIterator, _ForwardIterator) [with _ForwardIterator = boost::numeric::ublas::indexed_iteratorboost::numeric::ublas::index_triple_arrayboost::numeric::ublas::unbounded_arraylong unsigned int, boost::numeric::ublas::unbounded_arraylong unsigned int, boost::numeric::ublas::unbounded_arraydouble, std::allocatordouble , std::random_access_iterator_tag, _Tp = boost::numeric::ublas::index_tripleboost::numeric::ublas::index_triple_arrayboost::numeric::ublas::unbounded_arraylong unsigned int, boost::numeric::ublas::unbounded_arraylong unsigned int, boost::numeric::ublas::unbounded_arraydouble, std::allocatordouble ]’: /usr/include/c++/4.5/bits/stl_algo.h:3084:17: instantiated from ‘void std::inplace_merge(_BIter, _BIter, _BIter) [with _BIter = boost::numeric::ublas::indexed_iteratorboost::numeric::ublas::index_triple_arrayboost::numeric::ublas::unbounded_arraylong unsigned int, boost::numeric::ublas::unbounded_arraylong unsigned int, boost::numeric::ublas::unbounded_arraydouble, std::allocatordouble , std::random_access_iterator_tag]’ /usr/include/boost/numeric/ublas/matrix_sparse.hpp:4387:17: instantiated from ‘void
Re: [Rcpp-devel] Strange compiler error when using boost uBLAS on Ubuntu 11.04
On 7 June 2011 at 12:44, Douglas Bates wrote: | Sorry to take so long to respond. No worries. | On Sat, Jun 4, 2011 at 12:26 PM, Dirk Eddelbuettel e...@debian.org wrote: | Can you try them without Rcpp to see if there is a side-effect? | | I did so. Trying to compile the example section of | http://www.boost.org/doc/libs/1_46_1/libs/numeric/ublas/doc/matrix_sparse.htm#coordinate_matrix | | produces [...] Same for me, now that I checked. But it may be a Boost issue with that release. I'll fire up one of the currently sleeping Debian testing machines when I get home to try Boost 1.46. What I was able to confirm that with Boost 1.33 (!!) as on a CentOS box, I am in fact able to build it. 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] Strange compiler error when using boost uBLAS on Ubuntu 11.04
On Tue, Jun 7, 2011 at 1:03 PM, Dirk Eddelbuettel e...@debian.org wrote: On 7 June 2011 at 12:44, Douglas Bates wrote: | Sorry to take so long to respond. No worries. | On Sat, Jun 4, 2011 at 12:26 PM, Dirk Eddelbuettel e...@debian.org wrote: | Can you try them without Rcpp to see if there is a side-effect? | | I did so. Trying to compile the example section of | http://www.boost.org/doc/libs/1_46_1/libs/numeric/ublas/doc/matrix_sparse.htm#coordinate_matrix | | produces [...] Same for me, now that I checked. But it may be a Boost issue with that release. I'll fire up one of the currently sleeping Debian testing machines when I get home to try Boost 1.46. What I was able to confirm that with Boost 1.33 (!!) as on a CentOS box, I am in fact able to build it. I just tried with boost 1.43.0 and with boost 1.46.1. In both cases the error persists. What would you recommend trying with gcc-4.6.x? ___ 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] Strange compiler error when using boost uBLAS on Ubuntu 11.04
On 7 June 2011 at 13:07, Douglas Bates wrote: | On Tue, Jun 7, 2011 at 1:03 PM, Dirk Eddelbuettel e...@debian.org wrote: | But it may be a Boost issue with that release. I'll fire up one of the | currently sleeping Debian testing machines when I get home to try Boost 1.46. | What I was able to confirm that with Boost 1.33 (!!) as on a CentOS box, I am | in fact able to build it. | | I just tried with boost 1.43.0 and with boost 1.46.1. In both cases | the error persists. What would you recommend trying with gcc-4.6.x? Damn. Another bubble burst. In that case I'd try one of the Boost mailing lists. It is after all a piece of documented code which goes belly-up. 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] redimension help
On Tue, Jun 7, 2011 at 8:01 AM, Silkworth,David J.
silkw...@airproducts.com wrote:
I want you guys to know that I appreciate all the effort that you put
into the Rcpp package and this list. I am obviously one of the early
people to hurdle the new lowered bar for C++ development in R.
I have developed a function that builds a series of vectors and a matrix
of undetermined size. Rather than attempt dynamic objects (which I
wouldn't know how to do anyway) I have been able to initialize with row
dimensions that cannot be exceeded on these objects. I expect that code
that merely assigns values to these addresses will run faster than code
that must allocate space for each row entry anyway. But, at the end of
the process, my code realizes the true extent of these objects. It
would be really nice to clean these up before return to R.
I am aware of a Dimension class, but really don't know how to go about
using this in this case.
For the vectors it was relatively simple to execute a loop of erase()
methods:
// this works perfectly
for(int t=newTimes.size()-1; trow;t--) {
newTimes.erase(t);
}
Alas, for the Rcpp::IntegerMatrix this was not so easy.
Rcpp::IntegerMatrix opd (exists and has been populated)
for(int v=0; vnum_opl v++) {
for(int t=newTimes.size()-1; trow;t--) {
opd(_,0).erase(t);
}
}
This results in the compiler error: 'struct Rcpp::Matrix13::Column'
has no member named 'erase'
I'm sorry, but I am stuck.
I think we are stuck too in that we can't tell what you are trying to
do. (Well, at least I can't.).
Why do you bother erasing elements beyond the size() of the vector?
I'm pretty sure that will have no effect.
Perhaps if you were a bit more explicit about what you are trying to
do we could help. As it stands you are telling us that you have tried
to use a method that isn't defined and all we can say is, Yep, it
isn't defined.
___
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?
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 functions from LAPACK, presumably that means that R defines its
Re: [Rcpp-devel] RcppArmadillo inv() depends on Lapack, zgetri_ not available on CRAN / R-forge?
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?
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). I see; so basically the user will always need to have a full LAPACK installed.
Re: [Rcpp-devel] RcppArmadillo inv() depends on Lapack, zgetri_ not available on CRAN / R-forge?
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?
On Tue, Jun 7, 2011 at 4:20 PM, baptiste auguie baptiste.aug...@googlemail.com wrote: 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
Re: [Rcpp-devel] trans() changed in latest RcppArmadillo
For tiny matrices (ie. = 4x4), Armadillo by default uses fast algorithms for det(), inv() and solve(). In rare instances these fast algorithms may not be as precise as the standard algorithms found in Lapack. As such, in the updated version of Armadillo I've added an option to det(), inv() and solve() to force the use of the standard slow algorithms: http://arma.sourceforge.net/docs.html#inv On 8 June 2011 01:21, Savitsky, Terrance savit...@rand.org wrote: Hello Dr. Sanderson, I find no issues in RcppArmadillo 0.2.22. In fact, I was unable to reproduce the error (under 0.2.21) I found via a simple example; in my case, a simple Bayesian regression routine with unknown variances. I continue to experience a transient error that I believe derives from my end and is unrelated to Armadillo; in particular, the inversion of a matrix becomes numerically unstable, causing a crash of an MCMC routine. The error event is rare and I have been unable to duplicate it in a systematic way by running 100's of monte carlo simulations. ... ___ 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] redimension help
Further to our personal exchange I have reviewed Romain's recent post in reply
to Fatemeh Riahi
http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2011-May/002256.html
I've attempted to re-write my simple example in the list of vectors format as
shown by Romain.
src-'
int s = 7; // result of original oversize estimate before process runs
int c=3; //known column count established from a list argument (variable to
function)
int r = 4; // number of rows that more complex process found necessary to fill
int i=0;
Rcpp::List Lmv(c) ; // list of matrix column vectors
for( i=0; ic; i++) {
Rcpp::IntegerVector m(s) ;
// insertion of next three lines partially fills the matrix column vectors
// the same way as previous sample code
for( int j=0; jr; j++){
m[j]= (i+1)*(j+1);
}
Lmv[i]=m;
}
// this code does not access the vector elements as I wish
//for(int j=0; jr;j++) {
//for( i=0;ir;i++) {
//Lmv[i][j]= (i+1)*(j+1);} }
return Lmv;
'
fun - cxxfunction(signature(),src, plugin = Rcpp)
I can create the partially filled matrix as a list of vectors.
But I don't know how to access the individual vector elements outside of the
initialization loop.
Then, when I tried to perform the vector erasures I had more trouble:
Adding these lines before the return call does NOT work as I wanted either.
for(i=0; ic; i++) {
for(int e=s-1; er-1;e--) {
Lmv[i].erase(e); } // redimension the vector
}
I'm trying, but still stuck.
-Original Message-
From: Silkworth,David J.
Sent: Tuesday, June 07, 2011 3:42 PM
To: 'Douglas Bates'
Subject: RE: [Rcpp-devel] redimension help
My apologies, Doug.
I've tried to distill the issue to a simple, but complete example.
src - '
int s = 7; // result of original oversize estimate before process runs
int c=3; //known column count established from a list argument (variable to
function)
Rcpp::IntegerVector v(s);
Rcpp::IntegerMatrix m(s,c);
int r = 4; // number of rows that more complex process found necessary to fill
for(int x=1; xr+1;x++) { v[x-1]=x; } // just partial fill as process would
for(int j=0; jr;j++) { for(int i=0;ir;i++) {m(i,j)= (i+1)*(j+1);} }
for(int e=s-1; er-1;e--) { v.erase(e); } // redimension the vector
Rcpp::List L=Rcpp::List::create(v,m);
return L;
'
fun - cxxfunction(signature(),src, plugin = Rcpp)
The erase loop on the vector performs a redimension clean-up so to speak from
my over-estimate of required dimension. The estimate is made at run time, just
that it is made before the matrix is dimensioned and the rest of the function
has executed. The reason that there is shrinkage is that there are duplicate
entries that the process finds and adjusts its matrix fill operation for.
I cannot duplicate such an erase operation on the matrix. But I think that
there is probably a different approach that would work on both the vector and
matrix, if I was only smart enough.
I needed the matrix, because its number of columns is only determined at run
time, so I need a way to have indexed labels for the column vectors that it
creates.
Douglas Bates replied:
I think we are stuck too in that we can't tell what you are trying to
do. (Well, at least I can't.).
Why do you bother erasing elements beyond the size() of the vector?
I'm pretty sure that will have no effect.
Perhaps if you were a bit more explicit about what you are trying to
do we could help. As it stands you are telling us that you have tried
to use a method that isn't defined and all we can say is, Yep, it
isn't defined.
___
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] redimension help
On 7 June 2011 at 22:09, Silkworth,David J. wrote:
| Further to our personal exchange I have reviewed Romain's recent post in
reply to Fatemeh Riahi
| http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2011-May/002256.html
|
| I've attempted to re-write my simple example in the list of vectors format as
shown by Romain.
|
| src-'
| int s = 7; // result of original oversize estimate before process runs
| int c=3; //known column count established from a list argument (variable to
function)
| int r = 4; // number of rows that more complex process found necessary to
fill
| int i=0;
| Rcpp::List Lmv(c) ; // list of matrix column vectors
| for( i=0; ic; i++) {
| Rcpp::IntegerVector m(s) ;
| // insertion of next three lines partially fills the matrix column vectors
| // the same way as previous sample code
| for( int j=0; jr; j++){
| m[j]= (i+1)*(j+1);
| }
| Lmv[i]=m;
| }
| // this code does not access the vector elements as I wish
| //for(int j=0; jr;j++) {
| //for( i=0;ir;i++) {
| //Lmv[i][j]= (i+1)*(j+1);} }
Try this:
require(inline)
src - '
int s = 7; // result of original oversize estimate before process runs
int c = 3; //known column count established from a list argument (variable
to function)
int r = 4; // number of rows that more complex process found necessary to
fill
int i = 0;
Rcpp::List Lmv(c) ; // list of matrix column vectors
for( i=0; ic; i++) {
Rcpp::IntegerVector m(s) ;
// insertion of next three lines partially fills the matrix column vectors
// the same way as previous sample code
for( int j=0; jr; j++){
m(j)= (i+1)*(j+1);
}
Lmv[i] = m;
}
// this code does not access the vector elements as I wish
for(int j=0; jc; j++) {
for( i=0; ir; i++) {
Rcpp::IntegerVector v = Lmv(j);
v(i) = (i+1)*(j+1);
}
}
return Lmv;
'
fun - cxxfunction(signature(), src, plugin = Rcpp)
print(fun())
And please do search the list archives. I explained a few times already why
using [][] cannot work.
|
| return Lmv;
|
| '
|
| fun - cxxfunction(signature(),src, plugin = Rcpp)
|
| I can create the partially filled matrix as a list of vectors.
|
| But I don't know how to access the individual vector elements outside of the
initialization loop.
|
| Then, when I tried to perform the vector erasures I had more trouble:
|
| Adding these lines before the return call does NOT work as I wanted either.
| for(i=0; ic; i++) {
| for(int e=s-1; er-1;e--) {
| Lmv[i].erase(e); } // redimension the vector
| }
|
| I'm trying, but still stuck.
Not all STL methods exist in all Rcpp classes.
Dirk
|
|
|
| -Original Message-
| From: Silkworth,David J.
| Sent: Tuesday, June 07, 2011 3:42 PM
| To: 'Douglas Bates'
| Subject: RE: [Rcpp-devel] redimension help
|
| My apologies, Doug.
|
| I've tried to distill the issue to a simple, but complete example.
|
| src - '
| int s = 7; // result of original oversize estimate before process runs
| int c=3; //known column count established from a list argument (variable to
function)
| Rcpp::IntegerVector v(s);
| Rcpp::IntegerMatrix m(s,c);
|
| int r = 4; // number of rows that more complex process found necessary to
fill
| for(int x=1; xr+1;x++) { v[x-1]=x; } // just partial fill as process would
| for(int j=0; jr;j++) { for(int i=0;ir;i++) {m(i,j)= (i+1)*(j+1);} }
|
| for(int e=s-1; er-1;e--) { v.erase(e); } // redimension the vector
|
| Rcpp::List L=Rcpp::List::create(v,m);
| return L;
| '
|
| fun - cxxfunction(signature(),src, plugin = Rcpp)
|
| The erase loop on the vector performs a redimension clean-up so to speak
from my over-estimate of required dimension. The estimate is made at run time,
just that it is made before the matrix is dimensioned and the rest of the
function has executed. The reason that there is shrinkage is that there are
duplicate entries that the process finds and adjusts its matrix fill operation
for.
|
| I cannot duplicate such an erase operation on the matrix. But I think that
there is probably a different approach that would work on both the vector and
matrix, if I was only smart enough.
|
| I needed the matrix, because its number of columns is only determined at run
time, so I need a way to have indexed labels for the column vectors that it
creates.
|
|
|
| Douglas Bates replied:
|
| I think we are stuck too in that we can't tell what you are trying to
| do. (Well, at least I can't.).
|
| Why do you bother erasing elements beyond the size() of the vector?
| I'm pretty sure that will have no effect.
|
| Perhaps if you were a bit more explicit about what you are trying to
| do we could help. As it stands you are telling us that you have tried
| to use a method that isn't defined and all we can say is, Yep, it
| isn't defined.
|
|
| ___
| Rcpp-devel mailing list
| Rcpp-devel@lists.r-forge.r-project.org
|
Re: [Rcpp-devel] redimension help
I have not been slack on reviewing the archives, but they ARE hard to
search.
So far, I am led to believe that a list of vectors can only be accessed
during initialization.
This would seem to be a real problem for entering elements in looped
increments 10's of thousands of times.
The original matrix scheme DOES work, but I think I have to improve the
estimated size of rows, so that I don't create an excessive memory foot
print. Once dimensioned a matrix apparently is not going to be resized.
I am aware that as long as my individual vectors and my matrix row
lengths are the same size that these will combine into an
Rcpp::DataFrame.
Once in R I would have to either find a way to ignore the unfilled
elements or hopefully the following code would not be too oppressive:
RcppDF-RcppDF[1:r,]
I just thought it would be possible to do in C++
Try this:
require(inline)
src - '
int s = 7; // result of original oversize estimate before process
runs
int c = 3; //known column count established from a list argument
(variable to function)
int r = 4; // number of rows that more complex process found
necessary to fill
int i = 0;
Rcpp::List Lmv(c) ; // list of matrix column vectors
for( i=0; ic; i++) {
Rcpp::IntegerVector m(s) ;
// insertion of next three lines partially fills the matrix column
vectors
// the same way as previous sample code
for( int j=0; jr; j++){
m(j)= (i+1)*(j+1);
}
Lmv[i] = m;
}
// this code does not access the vector elements as I wish
for(int j=0; jc; j++) {
for( i=0; ir; i++) {
Rcpp::IntegerVector v = Lmv(j);
v(i) = (i+1)*(j+1);
}
}
return Lmv;
'
fun - cxxfunction(signature(), src, plugin = Rcpp)
print(fun())
And please do search the list archives. I explained a few times already
why
using [][] cannot work.
Not all STL methods exist in all Rcpp classes.
Dirk
___
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] redimension help
David, One last thing: you are trying something difficult with large multi-dimensional objects. I really recommend that you try to become more familiar with a more STL-ish way of doing things. Try something simpler on std::vector et al -- how you can change dimension, expand, remove, ... without _ever_ having to worry about manual memory allocation via new / delete (or, worse, malloc / free). That is a good thing. If you really know the size of objects, try reserve() or size(). Our Rcpp objects are pretty similar in some aspects, but because they really shadow the underlying R objects (those SEXPs) they are still different. It takes some getting used, and I have no better recommendation than to read more documentation and working code -- there are 20+ packages on CRAN using Rcpp. You may find something close to your needs for closer study. Hope this helps, 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
