Re: [Rcpp-devel] Rcpp syntactic sugar equivalent for R's optimize() function
I have just noticed that optimize() is already a C function, as is suggested
below:
> stats::optimize
function (f, interval, ..., lower = min(interval), upper = max(interval),
maximum = FALSE, tol = .Machine$double.eps^0.25)
{
if (maximum) {
val <- .External2(C_do_fmin, function(arg) -f(arg, ...),
lower, upper, tol)
list(maximum = val, objective = f(val, ...))
}
else {
val <- .External2(C_do_fmin, function(arg) f(arg, ...),
lower, upper, tol)
list(minimum = val, objective = f(val, ...))
}
}
Is there a way I can just call that function in Rcpp rather than having to
install new libraries or create my own? (I presume that there is probably a
“C_do_fmin.c” file somewhere that I can use?)
On 27 Feb 2014, at 20:02, Dirk Eddelbuettel wrote:
>
> Last time I neeed a 1-d solver, I just quicky coded one up, based on another
> implementation of Brent's method. That was a one-off and at work, but it
> really isn't that involved.
>
> Otherwise, please do look around at CRAN. There are now 176 packages using
> Rcpp, and quite a few use, or implement, optimization approaches. You just
> find something to work off.
>
> 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] Rcpp syntactic sugar equivalent for R's optimize() function
Hi Hideyoshi, > Is there a way I can just call that function in Rcpp rather than having to > install new libraries or create my own? (I presume that there is probably a > “C_do_fmin.c” file somewhere that I can use?) This questions has been discussed in this list about a month ago: http://r.789695.n4.nabble.com/Linking-to-native-routines-in-other-packages-tt4683969.html#none I am now using the approach that Romain suggested in this thread. Be sure to include PKG_CPPFLAGS+=-I../inst/include/ in the Makevars and Makevars.win files. AFAIK know this mechanism is not automated (yet), see http://r.789695.n4.nabble.com/LinkingTo-self-tt4684613.html Best, Gregor ___ 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] Rcpp syntactic sugar equivalent for R's optimize() function
On 28 February 2014 at 11:52, Gregor Kastner wrote: | Hi Hideyoshi, | | > Is there a way I can just call that function in Rcpp rather than having to | > install new libraries or create my own? (I presume that there is probably a | > “C_do_fmin.c” file somewhere that I can use?) | | This questions has been discussed in this list about a month ago: | | http://r.789695.n4.nabble.com/Linking-to-native-routines-in-other-packages-tt4683969.html#none Not exactly. That question was about calling from another package for which the calling-registered-functions approach was discussed; Hideyoshi wants to call a function from an R base package. That can be done, but can also be tricky because they don't exactly have the same calling interface: /* fmin(f, xmin, xmax tol) */ SEXP do_fmin(SEXP call, SEXP op, SEXP args, SEXP rho) It is a good exercise to work through the call, op, args arguments once :) In short, this is not trivial. Which is why I chose to quickly reimplement / rewrite the Brent algorithm in another function for (internal, not distributed) use as I alluded to in my earlier answer. 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] Rcpp syntactic sugar equivalent for R's optimize() function
Le 28 févr. 2014 à 11:52, Gregor Kastner a écrit : > Hi Hideyoshi, > >> Is there a way I can just call that function in Rcpp rather than having to >> install new libraries or create my own? (I presume that there is probably a >> “C_do_fmin.c” file somewhere that I can use?) > > This questions has been discussed in this list about a month ago: > > http://r.789695.n4.nabble.com/Linking-to-native-routines-in-other-packages-tt4683969.html#none As Dirk said, this is not the same thing. The level of complexity of calling an internal function of the stats package is quite high. I’d suggest : - reimplement clean c++ code as Dirk says - call the R function optimize form C++. Chances are the overhead of doing that is minimal and anecdotic compared to calling the objective function. - use something else as Dale says. > I am now using the approach that Romain suggested in this thread. Be sure to > include > > PKG_CPPFLAGS+=-I../inst/include/ As it has been reported to me by Brian Ripley, += is a gnu-ism so it is not portable. Also, you should not have the last `/` So: PKG_CPPFLAGS = -I../inst/include > in the Makevars and Makevars.win files. AFAIK know this mechanism is not > automated (yet), see > http://r.789695.n4.nabble.com/LinkingTo-self-tt4684613.html > > Best, > Gregor ___ 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] Rcpp syntactic sugar equivalent for R's optimize() function
"In short, this is not trivial." No, it isn't. If you are not completely wedded to optimize(), I would suggest another route. Again, I recommend nlopt or some other package which has the algorithms you need. And you can investigate nloptr if you want to call the routines in that R package as Dirk pointed out below, and as in the list archives. The C++ interface to nlopt uses std::vector. Using the facilities of Rcpp, I'm able to easily go from NumericVector to std::vector. This makes for very clean code. FWIW, I'm implementing model prototypes in R, then re-implementing in C++ so I can then compare results via Rcpp. Thus, nlopt is a very good solution for me. Dale Smith, Ph.D. Senior Financial Quantitative Analyst Financial & Risk Management Solutions Fiserv Office: 678-375-5315 www.fiserv.com -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 Dirk Eddelbuettel Sent: Friday, February 28, 2014 7:14 AM To: Gregor Kastner Cc: rcpp-de...@r-forge.wu-wien.ac.at Subject: Re: [Rcpp-devel] Rcpp syntactic sugar equivalent for R's optimize() function On 28 February 2014 at 11:52, Gregor Kastner wrote: | Hi Hideyoshi, | | > Is there a way I can just call that function in Rcpp rather than | > having to install new libraries or create my own? (I presume that | > there is probably a “C_do_fmin.c” file somewhere that I can use?) | | This questions has been discussed in this list about a month ago: | | http://r.789695.n4.nabble.com/Linking-to-native-routines-in-other-pack | ages-tt4683969.html#none Not exactly. That question was about calling from another package for which the calling-registered-functions approach was discussed; Hideyoshi wants to call a function from an R base package. That can be done, but can also be tricky because they don't exactly have the same calling interface: /* fmin(f, xmin, xmax tol) */ SEXP do_fmin(SEXP call, SEXP op, SEXP args, SEXP rho) It is a good exercise to work through the call, op, args arguments once :) In short, this is not trivial. Which is why I chose to quickly reimplement / rewrite the Brent algorithm in another function for (internal, not distributed) use as I alluded to in my earlier answer. 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
[Rcpp-devel] Pb compilation windows 64 : minGW32 is selected
Hello, I developed a Rcpp module which compiles and works fine on linux and win32 but fails to compile on win64. This module makes a "call lib" to a dll compiled with visual and the "R CMD INSTALL" fails during the link process with a message "skipping incompatible NameOFMyLibraryCompiledWithVisual [...] cannot find -lNameOFMyLibraryCompiledWithVisual" After a quick goolgle seach I discovered that it was due to the fact that my Rcpp module was compiled in 32 bits mode and Visual built a 64 bits library. This is confirmed by the traces I get on my DOS windows when I launch a R CMD INSTALL g++ -m32 -share etc ... etc ... I do not understand why the R command calls the win32 (flag -m32) version of minGW. I set my path to set PATH=C:\R\Rtools\bin;C:\R\Rtools\gcc-4.6.3\bin;C:\R\R-3.0.2\bin\x64;C:\Windows;C:\Windows\system32; as required I think ? So I do not understand why the (-m32) flag is set. I hope someone in the mailing list already had the problem and can answer me ? ___ 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: Exposed class works within cpp func, bombs via module
On Wed, Feb 26, 2014 at 1:48 PM, Thell Fowler wrote:
> On Wed, Feb 26, 2014 at 12:56 PM, Thell Fowler wrote:
>> On Wed, Feb 26, 2014 at 12:33 PM, Dirk Eddelbuettel wrote:
>>>
>>> On 26 February 2014 at 12:26, Thell Fowler wrote:
>>> | BTW - what was the fix/issue you tackled yesterday? Possibly any
>>> relation?
>>>
>>> Unrelated, mostly, as it was a for loop with iterators using comparison
>>> (wrongly) and arithmetic on the iterator object. In that case using
>>> old-school indices worked more reliably. Somewhat related in the sense that
>>> unnecessary complexity was added by trying to be clever via iterators.
>>>
>>> Here we don't know. It could be something in our backend, or it could be
>>> your
>>> code.
>>>
>>> Dirk
>>>
>>> --
>>> Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
>>
>>
>> Good point regarding 'being clever' with the iterators.
>>
>> Here's a small reproducible sample of without _anything_ else going on...
>>
>> https://gist.github.com/Thell/9231866
>>
--->8---
>
> Narrowed down to invalidation of pointer because data (vec) is moved
> _after_ the constructor exits. Setting the iterator member after the
> construction has completed looks to resolve the issue.
>
> So, construct, { init, use }...
>
> Is that change of address on purpose to facilitate the Rcpp/R bridge
> or is it a side effect?
>
> --
> Sincerely,
> Thell
I just wanted to report that if the std::vector vectors are
changed to IntegerVector vectors the addresses reported in BadIter do
not change when the constructor completes.
--
Sincerely,
Thell
___
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: Exposed class works within cpp func, bombs via module
Hi Thell,
Thanks for all the work you've done investigating this. Can you please
consolidate the information you have and post it as an issue here:
https://github.com/RcppCore/Rcpp/issues?state=open?
And, if you're willing to dive in and figure out what exactly is
happening, patches are much appreciated -- we will try to investigate
as well.
Thanks,
Kevin
On Fri, Feb 28, 2014 at 3:18 PM, Thell Fowler wrote:
> On Wed, Feb 26, 2014 at 1:48 PM, Thell Fowler wrote:
>> On Wed, Feb 26, 2014 at 12:56 PM, Thell Fowler wrote:
>>> On Wed, Feb 26, 2014 at 12:33 PM, Dirk Eddelbuettel wrote:
On 26 February 2014 at 12:26, Thell Fowler wrote:
| BTW - what was the fix/issue you tackled yesterday? Possibly any
relation?
Unrelated, mostly, as it was a for loop with iterators using comparison
(wrongly) and arithmetic on the iterator object. In that case using
old-school indices worked more reliably. Somewhat related in the sense that
unnecessary complexity was added by trying to be clever via iterators.
Here we don't know. It could be something in our backend, or it could be
your
code.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
>>>
>>>
>>> Good point regarding 'being clever' with the iterators.
>>>
>>> Here's a small reproducible sample of without _anything_ else going on...
>>>
>>> https://gist.github.com/Thell/9231866
>>>
>
> --->8---
>
>>
>> Narrowed down to invalidation of pointer because data (vec) is moved
>> _after_ the constructor exits. Setting the iterator member after the
>> construction has completed looks to resolve the issue.
>>
>> So, construct, { init, use }...
>>
>> Is that change of address on purpose to facilitate the Rcpp/R bridge
>> or is it a side effect?
>>
>> --
>> Sincerely,
>> Thell
>
> I just wanted to report that if the std::vector vectors are
> changed to IntegerVector vectors the addresses reported in BadIter do
> not change when the constructor completes.
>
> --
> Sincerely,
> Thell
> ___
> 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] Rcpp attributes, default values for enums
Hi All,
it seems that this is currently not supported.
For this:
// [[Rcpp::export("L_tree")]]
NumericMatrix rogdf_tree_layout(GraphAttributes graph,
double siblingDistance=20, double subtreeDistance=20,
double levelDistance=50, double treeDistance=50,
bool orthogonalLayout=false,
Orientation orientation=topToBottom,
TreeLayout::RootSelectionType selectRoot=TreeLayout::rootIsSource) {
...
where the last two arguments are enums, I get:
Warning messages:
1: Unable to parse C++ default value 'topToBottom' for argument orientation
of function rogdf_tree_layout
2: Unable to parse C++ default value 'TreeLayout::rootIsSource' for
argument selectRoot of function rogdf_tree_layout
and there are no default values in the generated R code.
Is there a workaround? Any chance of adding support for it? How hard do you
think it is to support it?
Thanks, Best,
Gabor
___
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: Exposed class works within cpp func, bombs via module
On Fri, Feb 28, 2014 at 5:28 PM, Kevin Ushey wrote: > Hi Thell, > > Thanks for all the work you've done investigating this. Can you please > consolidate the information you have and post it as an issue here: > https://github.com/RcppCore/Rcpp/issues?state=open? > > And, if you're willing to dive in and figure out what exactly is > happening, patches are much appreciated -- we will try to investigate > as well. > > Thanks, > Kevin > --->8--- Issue opened. As stated in a prior message of this thread, and in the opened issue... I'm still not sure if this is even an issue. It is an unfortunate behavior, but it may well be intended. The issue is #122 and the sourcecpp file is available here... https://gist.github.com/Thell/9286048 I'll wait until someone in the know states if this is a side-effect, bug, or what not before diving any deeper. Thell ___ 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
