[Rcpp-devel] Segfault error during simulation in Rcpp

[Matteo Fasiolo]

Jonathan,

| ^ I could have been more explicit. This is what I meant. You might may or
may not be able to do this in the sourceCpp() framework, though. How you do
| this is much more obvious if you go the route of making an Rcpp package.
For as much as the convenience functions are a blessing, I've always found
it  | hard to think about how I'd do more complex things with them. It
could be possible, I just don't see it. I find the package approach to be a
nice balance |between abstracting away from some details but keeping some
in the forefront of your mind. If you email me off the list and I can send
you a very small |package that using Rcpp. Multiple C++ functions are
created, only some are exposed to R.


Your are right creating a package is probably the best thing to do
especially in the long term (when hopefully this stuff will go in an
article and
the code in a CRAN package). I'll email you to ask you the package you
where talking about.


On Fri, May 17, 2013 at 11:32 AM, Matteo Fasiolo
<matteo.fasiolo at gmail.com>wrote:

> Sorry yesterday evening by mistake I sent a message only to Dirk:
>
> Thanks, you are right I'll try cxxfunction and/or I'll see whether I can
> move avoid doing so many calls to C++.
>
> For the sake of minimality: this code is enough to have a segfault or to
> make R stall
> (at least on my computer):
>
> library(Rcpp)
> myFun <- cppFunction('NumericMatrix myFun(NumericMatrix input){ return
> input; }')
>
> n <- 10
> x <- 1:n^2
> N <- 1e6
> b <- 0
> A <- matrix(x, n, n)
> for (j in 1:N) {
>     res <- myFun(A)
>     a <- res[1,1]
>     b <- b + a
> }
>
> cat(sprintf("Done, b is %d\n", b))
>
> Thanks a lot to everybody for the help!
>
>
> On Fri, May 17, 2013 at 4:17 AM, Ivan Popivanov <ivan.popivanov at gmail.com>wrote:
>
>> Ignore my previous mail ...
>>
>>
>> On Thu, May 16, 2013 at 11:12 PM, Ivan Popivanov <
>> ivan.popivanov at gmail.com> wrote:
>>
>>> How is this code supposed to work? If n=1e6, then the matrix has 1e12
>>> elements, right? That's in the terabyte range - the memory manager is going
>>> to blow up or overflow and the results would be unpredictable. Or am I
>>> missing something?
>>>
>>> Regards,
>>> Ivan
>>>
>>>
>>> On Thu, May 16, 2013 at 7:14 PM, Jonathan Olmsted <jpolmsted at gmail.com>wrote:
>>>
>>>> Matteo,
>>>>
>>>>
>>>>
>>>>> The other obvious of course is that you are not forced to control a
>>>>> loop over
>>>>> 10^6 elements from R either:  pass N=10^6 down to C++ code, and run
>>>>> your N
>>>>> loops there.  You will also get a considerable speed boost.
>>>>>
>>>>>
>>>> ^ I could have been more explicit. This is what I meant. You might may
>>>> or may not be able to do this in the sourceCpp() framework, though. How you
>>>> do this is much more obvious if you go the route of making an Rcpp package.
>>>> For as much as the convenience functions are a blessing, I've always found
>>>> it hard to think about how I'd do more complex things with them. It could
>>>> be possible, I just don't see it. I find the package approach to be a nice
>>>> balance between abstracting away from some details but keeping some in the
>>>> forefront of your mind. If you email me off the list and I can send you a
>>>> very small package that using Rcpp. Multiple C++ functions are created,
>>>> only some are exposed to R.
>>>>
>>>> It seems like you'd probably do something similar.
>>>>
>>>> -Jonathan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>  | On Thu, May 16, 2013 at 8:11 PM, Dirk Eddelbuettel <edd at debian.org>
>>>>> wrote:
>>>>> |
>>>>> |
>>>>> |     On 16 May 2013 at 14:49, Jonathan Olmsted wrote:
>>>>> |     | Several things.
>>>>> |     |
>>>>> |     | Xiao, Dirk's code gives me a segfault immediately and reliably.
>>>>> |     |
>>>>> |     | All, when I do this whole song and dance using the "old"
>>>>> Rcpp/inline/
>>>>> |     | cxxfunction approach, I don't have any issues. One obvious
>>>>> difference you
>>>>> |     can
>>>>> |     | see (like was mentioned) in the generated code (visibile using
>>>>> verbose=
>>>>> |     TRUE) is
>>>>> |     | the declaration of an RNGScope object.
>>>>> |     |
>>>>> |     | But, if the memory issue crops up when you call a C++
>>>>> function (syncing
>>>>> |     with
>>>>> |     | R's RNG state) 1e6 times AND you are already writing C++ maybe
>>>>> this is
>>>>> |     an
>>>>> |     | opportunity to just put one more layer of the code into C++
>>>>> and create
>>>>> |     only one
>>>>> |     | such RNGScope object?
>>>>> |
>>>>> |     Beautiful. So we get to blame R Core after all?  ;-)
>>>>> |
>>>>> |     Dirk
>>>>> |
>>>>> |     --
>>>>> |     Dirk Eddelbuettel | edd at debian.org |
>>>>> http://dirk.eddelbuettel.com
>>>>> |     _______________________________________________
>>>>> |     Rcpp-devel mailing list
>>>>> |     Rcpp-devel at lists.r-forge.r-project.org
>>>>> |
>>>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>>>>> |
>>>>> |
>>>>>
>>>>> --
>>>>> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Rcpp-devel mailing list
>>>> Rcpp-devel at 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 at lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20130517/53bd2957/attachment-0001.html>