I'm trying to figure out a way to call stats package's "dpois_raw" routine rather than the "dpois" wrapper using .Call .External or whatever means.
"dpois_raw" is not listed in the package environment (stats:::C_*) nor when I do getDLLRegisteredRoutines("stats") so I am probably out of luck, but I wonder whether someone R/C expert knows of a workaround.
The dpois_raw routine is provided by the Rmath.h header, and it doesn't appear to actually be exposed as part of the stats package (or otherwise); however, it is made available to C / C++ code through the Rmath.h header.
The simplest way to expose it would be with your own C / C++ code exposing that code, e.g. (code stub)
#include <R.h>
#include <Rmath.h>
SEXP my_dpois_raw(<...>) {
double result = dpois_raw(<...>);
return result;
}
This routine would then be callable from R with something like
.Call("my_dpois_raw", <...>)
See Hadley's r-pkgs section on using compiled code in R packages for some more information on including C / C++ code in an R package.
Related
I am currently developing an R package where most of the computational work is done in C code. In particular, I have several complex C routines for which I then wrap with an R function. These I know I can test using testthat because the namespace includes the C function called (I am using roxygen comments to generate the namespace).
The difficulty I am having is that some of these C routines have a few complicated subroutines, the output of which is non-trivial to check. These functions are never called from R directly, so there is no code in my R/ directory that has a roxygen comment that results in the namespace making these functions available. What I want to do is write an R routine that performs the same computation and then use testthat to compare against the output of the C function. I have done this and it works great when I load the entire shared library (using dyn.load), but I don't think this is the proper approach for tests in a package that I intend to submit to CRAN.
My current workaround is to create a dummy function in a file in my R/ directory that then has a roxygen comment for each of the functions I wish to load. That way when I run devtools::document(), these functions are included in the namespace.
Is this the best approach, or is there another method that is better/preferred?
I'm writing some C programs (I'm quite a beginner in C), that I compile and call from R. In order to be as efficient as possible, I try to use as much as possible functions from Lapack and BLAS (which contain highly optimised routine to perform basic operations).
I compile my .c codes thanks to, classically:
system ('R CMD SHLIB blablabla.c')
Here is the "preamble" of my average .c code:
#include <math.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <R_ext/blas.h>
#include <R_ext/Lapack.h>
Here is my "dummy" problem: I need to compute the "argmin of a real vector", i.e., the index of the minimal component of the vector (in practice, for huge vectors and a lot of times, so that I really like to use an optimised routine, and not a basic "for" loop).
"Unfortunately", in "R_ext/blas.h", the function IDMIN does not appear ("R_ext/blas.h" only contains the function IDAMAX, that returns the index of the maximum absolute value component).
In R, such a task is easily achieved by "which.min()" (which is, I guess, based on an optimised code), so I guess that it should "somewhere" exists the C code (certainly based on a FORTRAN code) that achieves this task, and this is exactly what I need...
In other words: what library should I add to my ".c preamble" and what C function should I use to be able to use an "optimised which.min()" in my C code (that I compile and call from R) ?
Another question: On Mac OS X, how to add some C libraries to the existing C libraries of R (still, with the view to compile and use C from R, which is in my view very convenient) ?
Thanks.
I've been struggling to find proper information on the web to solve this problem, in case it is an easy task please guide me through.
My final goal is to write some R functions that call C subroutines with the .Call function. In general there are no problems in doing this when R.h and Rinternals.h are sufficient.
My problem is: I would need to use in the C code some functions that are in a "personal.h" C library. I already compiled this library with gcc, but if I just try to add
#include "personal.h"
at the beginning after
#include <R.h>
#include <Rinternals.h>
like I would do if it was a standalone C file, when I then call any function from that package in the code, while compiling with R CMD SHLIB I get an error message telling me that it was not possible to find that function.
What should I do in order to include a C library in a C routine callable from R?
Read the "Writing R Extensions" manual which came with your copy of R.
Here, you need PKG_CPPFLAGS to tell R about your include files / headers. Later, you will need to tell it about your library.
Look at other small packages using C code as eg my digest package. And yes, there are in fact numerous tutorials on the Web for this too.
I am organizing some R code I have written into a package. This code contains MCMC algorithms for inference on parameters in ordinary differential equation models, so I will be solving the ODE thousands of times. Thus it is necessary to pass the model into the ode function of the deSolve package using compiled code instead of an R function. Normally, I use the commands
system('R CMD SHLIB mymodel.c')
dyn.load(mymodel)
to use the compiled versions. Instead, I would like R to automatically generate the .so files when I install the package. I cannot find a way to do this because these C functions are not for use as an R function. I just need the path to the valid DLL to pass into the ode function. It doesn't seem to make sense to make a wrapper for the ODE model since I can't use the function inside of R, but maybe I am confused. I cannot find a package on CRAN that uses C code in this manner, so maybe it is not possible.
So, I have a set of interdependent .c and .h files, and I'm trying to figure out exactly how C/C++-to-Pascal works (my delphi/pascal work otherwise was pretty basic). The c files are steps 1-N (in order) of a mathematical algorithm (each one is a separate function), one header specifies the variables used in each function (I'm using record to recreate the .h files in delphi), and the other header details a custom variable type. The goal is to access the functions without having to re-write the C code into Pascal/Delphi syntax, linking from delphi code to some existing c. There are too many lengthy files (12 .c and 4 .h) for me to snip, and my C is horribly rusty, but I'll try.
For example, I have a file funcs.h:
#ifndef _FUNCS_H
#ifndef _FUNCS_H
#ifdef __cplusplus
extern "C" {
#endif
#include "New_Type.h" // custom variable used in funcs.h
#include "Optional.h" // optional set of more functions
typedef struct {
int a1[4];
double b1[10];
// Computed if optional functions are requested
double c1[10];
int d1[4];
} func1;
typedef struct {
new_type c2, d2;
} func2;
}
#endif
#endif
and files func1.c and func2.c do some mathematical manipulation (mostly linear algebra) of the above variables. My immediate questions are:
Do I need multiple delphi files, much like there are multiple C headers?
What do the delphi files' "skeletons" look like (premable, function calls)?
What is {$LINKLIB C}, cdecl, and CALLBACK? Their common in other question/answers I've seen
Maybe I need to change my search/question, but I'm honestly not sure how to properly ask this. I don't need a specific answer, honestly I'd prefer if someone could point me to some links (heck a book: I'll be using this language in the future), I'd really appreciate it.
Thanks in advance for all the help.
Starting with #2: In Delphi, both the header and the implementation go in the same file. So here's a basic skeleton of a class showing where your header stuff (.h) and implementation stuff (.c) will fit into the structure of a unit/file in Delphi.
unit Unit1;
interface
uses // List of header dependencies goes here...
// Stuff from the .h file will go here
implementation
uses // List of implementation dependencies goes here...
// Stuff from the .c file will go here
end.
Back to #1: It's not strictly necessary to have a 1:1 mapping of your C header files to Delphi files, but if that was a good level of granularity per file in C, it's probably going to work out similarly in Delphi. Unless you have a good reason to change it, I'd leave them mapped at one C header file to one Delphi file.
About.com has a pretty detailed section on Delphi development, the page, for example, on working with units could be a good starting point on learning about the structure of a Delphi file. I also find myself using DelphiBasics as a reference site a lot (though it's more aimed at methods than structures). And definitely do not discount the official documentation on Embarcadero's website. Their Language Guide section is practically a textbook on learning Delphi, and is sufficiently detailed to get the fundamentals of the language.
And then as far as #3: This could easily be several separate full questions on stack overflow if you want more depth. But in general, it sounds like you're looking at code for calling c code directly from Delphi. CDecl is one of the calling conventions (the one that happens to match c...) which specifies which order parameters are passed to methods. Read more about it in Embarcadero's documentation. $LINKLIB is used to link to a library (in this case the C library, which you would do if you're calling c code), and callback is roughly equivalent to a function pointer in c.
From the overall sound of your third sub-question, I'm guessing you've been reading up on how to use C code in a Delphi project, without having to re-write the C code into Pascal/Delphi syntax, linking from delphi code to some existing c library you don't want to re-write or convert. If that's your ultimate goal, to just link to your C library without rewriting it, this article on using C in FreePascal may be of good help. For the purposes of linking to C code, the differences between FreePascal and Delphi, both variants of Pascal, are going to be relatively negligible). Basically, you have to re-write or convert the c header into Pascal syntax so that Delphi knows what functions are in your C library, so you can call them. Dr. Bob has a good detailed page about using C dlls in Delphi if you're looking for more info about converting header files. Amongst other useful information about how type names match, there is an example on that page of automated tools that exist for converting c header files to delphi headers. It may be easier to use an automated tool to convert your header to delphi syntax, if your goal is just to call or utilize your existing c code from a Delphi application without fully porting the entire code-library to Delphi.
And for the sake of example, your header from your question, converted through Dr. Bob's HeadConverter tool, gives output like this: (the actual output is longer and includes code for loading your c code as a dll and some comments as well)
unit FILE1;
interface
uses
Windows;
{$INCLUDE "New_Type.h"}
{$INCLUDE "Optional.h"}
type
func1 = record
a1: Array[0..4-1] of Integer;
b1: Array[0..10-1] of Double;
c1: Array[0..10-1] of Double;
d1: Array[0..4-1] of Integer;
end {func1};
type
func2 = record
c2, d2: NEW_TYPE;
end {func2};
{...}
implementation
{...}
end.