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

2013-07-12 Thread Changi Han
I apologize if my emails were badly phrased, or disrespectful. No intention
of saying anything was broken, suspicious or wrong.

I second Gabor. His described use case matches mine. The outer loop is an
optimization routine coming from other libraries. Rcpp is used to speed up
the objective, gradient and hessian computations and hence the data is
constantly passed along to all of these functions. Another use case to
consider is recursion with data passed along. A toy example is gib(0) =
values(0); gib(1) = values(1); gib(x) = gib(x-1) + gib(x-2) + values(x).
Values = vector of non negative integers. A naive implementation with aux
memory allocation may cause the number of copies in memory to grow with
exponential order in x.


 In case ii) I'd try to use a different design and make it more like i):
 You
  generally do not want to call down from R to object code a bazillion
 times as
  there is always some overhead, and multiplying even something rather
  efficient by a veryBigNumber can make small times large in the aggregate.

 Sure and sugar, rcpparmadillo and other facilities do make it easier to
 move
 more functionality into C++; nevertheless, it can be the case that a
 relatively
 small amount of R code repeatedly
 invoked is responsible for the performance hit in a program and from
 the viewpoint
 of reducing complexity and increasing maintainability it can be
 desirable to just
 move that minimum portion to the C++ side minimizing the dual language
 aspect
 of the code.  By making call overhead as fast
 as one can while retaining any automatic Rcpp features then this
 is facilitated.  If its not possible in general then if it were just
 possible
 for Armadillo objects and selected other situations then this would
 still be nice.

 
  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] Forcing a shallow versus deep copy

2013-07-11 Thread Changi Han
I am sure there are better ways to achieve the goal. I would suggest that
these two be similar if possible. I think the naive expectation is for them
to be consistent.

// [[Rcpp::export]]
stuff function(Rcpp::stuff) {
}

// [[Rcpp::export]]
stuff function(arma::stuff) {
}

Thank you again. Cheers.


On Thu, Jul 11, 2013 at 9:22 PM, 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