I would like to utilize both RcppArmadillo and RcppGSL via sourceCpp. Basically I am interested in modifying the B-spline example
http://dirk.eddelbuettel.com/blog/2012/12/08/
so that the B-splines are functions of R^3 instead of only R^1. This entails working with 3-dimensional arrays which apparently is not supported in GSL (there is an extension here http://savannah.nongnu.org/projects/marray though). However, RcppArmadillo has the arma::cube type which I could use if only I could get RcppArmadillo and RcppGSL to "work together." This I am unfortunately not able to do. I have looked at
Multiple plugins in cxxfunction
but have not succeeded in creating the mentioned combined plugin. Any help is greatly appreciated!
Adam
Edit: It seems like it is actually possible to compile a .cpp file with sourceCpp containing the following sequence of commands at the top:
// [[Rcpp::depends(RcppGSL)]]
// [[Rcpp::depends(RcppArmadillo)]]
#include <RcppArmadillo.h>
#include <RcppGSL.h>
#include <gsl/gsl_bspline.h>
Furthermore, it also seems possible to store values like
double gsl_vector_get (const gsl_vector * v, size_t i)
in an arma::cube structure.
RcppArmadillo.h and RcppGSL.h are modelled similarly. They first include RcppCommon.h, then some forward declarations, then they include Rcpp.h that uses those forward declarations, then implementations.
It is definitely possible to use them both if you come up with the right order of includes.
This is definitely an Rcpp question as what is preventing you from using them both is (good or bad) design decisions.
You need to study RcppArmadillo.h and RcppGSL.h and come up with the right include order, or wait for someone to follow these hints and give you the answer. I might not have time to do it myself in the next few days.
Armadillo types and GSL types are not interchangeable.
You could rewrite the GSL algorithm for Armadillo, but it is not automatic but any means. I am also not sure if the theory behind splines extends just like that from the real line to three-dimensions.
Related
I'm learning to use Rcpp in R. Would you please explain me the difference between R::runif() and Rcpp::runif().
I mean 3 questions:
Do these 2 functions produce the same stream of random numbers given that we set the same seed before running each of them ?
Which function is preferable when using Rcpp ? I mean, it seems to me that the 2 functions produce the same thing, but Rcpp::runif() will run more fastly.
How to call Rcpp::runif() in a .R file ? Is it true that the Rcpp::runif() can be called only from a .cpp file and not in R? (I mean, it seems to me that the function Rcpp::runif() is of extensively used to write other C++ functions, then I will import that function by sourcecpp() to use in R)
Thank you very much for your help!
I suspect this question is a duplicate so I may close this but here goes:
Yes they do. The whole point of the RNG interfaces is guaranteeing just that
Entirely up to you. Sometimes you want to wrap or use a C API example and you have R::runif() for that. Sometimes you want efficient vector operations for which you have Rcpp::runif().
You write a C++ function accessing the C++ API. Note that not all those functions will be faster than calling what R offers when what R offers is already vectorised. Your wrapping of Rcpp::runif() will not be much different in performance from calling stats::runif(). You use the C++ accessor in C++ code writing something you cannot easily get from R.
Edit: This Rcpp Gallery post has some background and examples.
I'm implementing a compiler compiling a source language to a target language (assembly like) in Haskell.
For debugging purpose, a source map is needed to map target language assembly instruction to its corresponding source position (line and column).
I've searched extensively compiler implementation, but none includes a source map.
Can anyone please point me in the right direction on how to generate a source map?
Code samples, books, etc. Haskell is preferred, other languages are also welcome.
Details depend on a compilation technique you're applying.
If you're doing it via a sequence of transforms of intermediate languages, as most sane compilers do these days, your options are following:
Annotate all intermediate representation (IR) nodes with source location information. Introduce special nodes for preserving variable names (they'll all go after you do, say, an SSA-transform, so you need to track their origins separately)
Inject tons of intrinsic function calls (see how it's done in LLVM IR) instead of annotating each node
Do a mixture of the above
The first option can even be done nearly automatically - if each transform preserves source location of an original node in all nodes it creates from it, you'd only have to manually change some non-trivial annotations.
Also you must keep in mind that some optimisations may render your source location information absolutely meaningless. E.g., a value numbering would collapse a number of similar expressions into one, probably preserving a source location information for one random origin. Same for rematerialisation.
With Haskell, the first approach will result in a lot of boilerplate in your ADT definitions and pattern matching, even if you sugar coat it with something like Scrap Your Boilerplate (SYB), so I'd recommend the second approach, which is extensively documented and nicely demonstrated in LLVM IR.
I do not need roxygen2 and Rcpp to create for me the R functions (or maybe I do?) for the exported C++ functions - is there any way to tell Rcpp::export not to create them? I would be perfectly happy with just .Call-ing them directly.
I went through Writing R Extensions, and Rcpp Attributes and Writing a package that uses Rcpp vignettes, documentation of roxygen2 and multiple threads on SO (like here) but I did not find anything helpful.
If I understand your question correctly, then it is as simple "well if you don't want a stub function created, do no put an [[Rcpp::export]] tag there".
You also confuse what roxygen2 does for documentation with what the compileAttributes() function does for exporting.
To be plain, only the latter has anything to do with creating interfaces between R and C++. And on the margin, you do want them for the free exception handling and RNG setting they give you. But hey, if you'd rather do without, you can, and that is documented.
When I have searched for the header unistd.h, in The Open Group, I found that it contains the standard symbolic constants & types and for sys/types.h it said for data types.
Then I found that both have uid_t, pid_t and several similar types.
I am confused why they have divided so and what are the differences between them. I have googled but I didn't get a satisfactory answers.
I will be thankful if some one can give me detailed explanation.
Thank you.
The division of the POSIX and C header in fine grained files probably comes from the old days when compilation might take a long time, and adding unnecesary header files made the time longer.
If you only need the OS types, say for the prototypes of your functions, then just #include <sys/types.h>. However if you need the function definitions, then you #include <unistd.h> or any of the other system headers, as needed.
Naturally there are types that are in both headers, as you cannot declare some functions without their necessary types.
But these different declarations of the same type are guaranteed to be the same, so there is no problem if you include both.
I'm writing a snake game in Haskell. These are some of the things I have:
A Coord data type
A Line data type
A Rect data type
A Polygon type class, which allows me to get a Rect as a series of lines ([Line]).
An Impassable type class that allows me to get a Line as a series of Coords ([Coord]) so that I can detect collisions between other Impassables.
A Draw type class for anything that I want to draw to the screen (HSCurses).
Finally I'm using QuickCheck so I want to declare Arbitrary instances for a lot of these things.
Currently I have a lot of these in separate modules so I have lots of small modules. I've noticed that I have to import a lot of them for each other so I'm kind of wondering what the point was.
I'm particularly confused about Arbitrary instances. When using -Wall I get warnings about orphaned instances when I but those instances together in one test file, my understanding is that I can avoid that warning by putting those instances in the same module as where the data type is defined but then I'll need to import Test.QuickCheck for all those modules which seems silly because QuickCheck should only be required when building the test executable.
Any advice on the specific problem with QuickCheck would be appreciated as would guidance on the more general problem of how/where programs should be divided into modules.
You can have your cake and eat it too. You can re-export modules.
module Geometry
( module Coord, module Line, module Rect, module Polygon, module Impassable )
where
I usually use a module whenever I have a complete abstraction -- i.e. when a data type's meaning differs from its implementation. Knowing little about your code, I would probably group Polygon and Impassable together, perhaps making a Collision data type to represent what they return. But Coord, Line, and Rect seem like good abstractions and they probably deserve their own modules.
For testing purposes, I use separate modules for the Arbitrary instances. Although I generally avoid orphan instances, these modules only get built when building the test executable so I don't mind the orphans or that it's not -Wall clean. You can also use -fno-warn-orphans to disable just this warning message.
I generally put more emphasis on the module interface as defined by the functions it exposes rather than the data types it exposes. Do some of your types share a common set of functions? Then I would put them in the same module.
But my practise is probably not the best since I usually write small programs. I would advise looking at some code from Hackage to see what package maintainers do.
If there were a way to sort packages by community rating or number of downloads, that would be a good place to start. (I thought there was, but now that I look for it, I can't find it.) Failing that, look at packages that you already use.
One solution with QuickCheck is to use the C preprocessor to selectively enable the Arbitrary instances when you are testing. You put the Arbitrary instances straight into your main modules but wrap them with preprocessor macros, then put a "test" flag into your Cabal file.