[Rcpp-devel] Segfault error during simulation in Rcpp

[Ivan Popivanov]

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20130516/d1f40230/attachment.html>