[Rd] Problem with dgamma function.
Hi, All, I am getting some funny results trying to use R's built in distribution functions. In R: > dgamma(4.775972,1.37697964405418, 0.106516604930466) [1] 0.05585295 > dgamma(4.775972,1.37697964405418, 0.106516604930466,TRUE) ### THIS IS JUST > WRONG! [1] 0.01710129 > log(dgamma(4.775972,1.37697964405418, 0.106516604930466)) [1] -2.885033 > In C: dgamma(4.775972,1.37697964405418, 0.106516604930466,TRUE) Returns: -41.046764 dgamma(4.775972,1.37697964405418, 0.106516604930466,FALSE) Returns: 0.00 SESSION INFO: R version 2.9.0 (2009-04-17) x86_64-unknown-linux-gnu Any indication of what I may be doing wrong is very much appreciated. Thanks, Charles -- Postdoctoral Fellow Cornell University 169 Biotechnology Building Ithaca, NY 14853 Phone (Lab, 467 Biotech Bldg.): 607-255-4743 E-mail: dan...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Returning vectors of two different data types back to R environment (from C).
Hello, Quick question. I have written a C function - I would like to make it return two vectors to the R environment - one STRSXP vector, and one INTSXP vector. Is this possible/ easy to do using the API? I looked, but could not find the answer to this question in the "Writing R Extensions" guide. Thanks very much for your help! Charles [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] SEXP size management.
Hi,
Trying to decrease the size of a SEXP variable without reassigning
values individually in a loop.
So far, I've tried using Realloc, as the follow source demonstrates:
SEXP dothis() {
SEXP Rblah;
PROTECT(Rblah = NEW_INTEGER(6));
int* blah = INTEGER(Rblah);
blah[0] = 1;
blah[1] = 2;
blah[2] = 3;
Realloc(Rblah, 3, INTEGER);
UNPROTECT(1);
return(Rblah);
}
According to the documentation, I think that this should work, however
it returns an error on compile: "test.c:17: error: expected expression
before ')' token" (line 17 refers to the Realloc line).
Another solution that will suit my needs is managing the variable in C
and assigning the pointer to an R type in the end. The following code
gets at this, but int* and SEXP, INTEGER are incompatible:
SEXP dothat() {
int* blah = malloc(3);// = INTEGER(Rblah);
blah[0] = 1;
blah[1] = 2;
blah[2] = 3;
SEXP Rblah;
PROTECT(Rblah = blah);
UNPROTECT(1);
return(Rblah);
}
Any suggestions for someone still new to SEXP memory management?
Thanks,
Charles
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SEXP size management.
Hi, Oleg,
Thanks very much for your answer! I was indeed confused; thinking
that Realloc was intended to be an analog to realloc (except for SEXP
variables).
Is there a way to do either of the following:
-- resize the SEXP directly (for my purpose, I ONLY need to decrease
the size), or
-- assign it to to a C pointer that was allocated and used previously
in the function (and can thus be resized with realloc).
Thanks again,
Charles
On Wed, Mar 5, 2008 at 11:14 AM, Oleg Sklyar <[EMAIL PROTECTED]> wrote:
> Rblah in your example is a SEXP structure. Realloc is an interface to C
> realloc and is not intended to resize SEXP structures -- it is used to
> resize user-controlled memory (which is generally not created by
> allocVector/INTEGER).
>
> You would expect a call like:
>
> int * val;
> ...
> Realloc(val, 20, int);
>
> Best,
> Oleg
>
>
>
> Charles Danko wrote:
> > Hi,
> >
> > Trying to decrease the size of a SEXP variable without reassigning
> > values individually in a loop.
> >
> > So far, I've tried using Realloc, as the follow source demonstrates:
> > SEXP dothis() {
> > SEXP Rblah;
> > PROTECT(Rblah = NEW_INTEGER(6));
> >
> > int* blah = INTEGER(Rblah);
> > blah[0] = 1;
> > blah[1] = 2;
> > blah[2] = 3;
> >
> > Realloc(Rblah, 3, INTEGER);
> >
> > UNPROTECT(1);
> > return(Rblah);
> > }
> >
> > According to the documentation, I think that this should work, however
> > it returns an error on compile: "test.c:17: error: expected expression
> > before ')' token" (line 17 refers to the Realloc line).
> >
> > Another solution that will suit my needs is managing the variable in C
> > and assigning the pointer to an R type in the end. The following code
> > gets at this, but int* and SEXP, INTEGER are incompatible:
> > SEXP dothat() {
> > int* blah = malloc(3);// = INTEGER(Rblah);
> > blah[0] = 1;
> > blah[1] = 2;
> > blah[2] = 3;
> >
> > SEXP Rblah;
> > PROTECT(Rblah = blah);
> >
> > UNPROTECT(1);
> > return(Rblah);
> > }
> >
> > Any suggestions for someone still new to SEXP memory management?
> >
> > Thanks,
> > Charles
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Dr Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +44-1223-494466
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] cbind speed.
cbind/ rbind/ data.frame functions are very convenient for merging vectors of different types into a single data frame, but take quite a bit of time to execute on larger data sets. Is it possible to speed these up a bit? What functions do you use instead? Thanks & regards, Charles __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Warning about undocumented data sets
Hi, List,
Sorry in advance if this turns out to be a stupid question -- I've
been trying to work it out for awhile, and I don't have any new ideas
-- I'm very new to R documentation/ LATEX.
I am running "R CMD check " on a package that I am trying to write;
the only warning is:
* checking for missing documentation entries ... WARNING
Undocumented data sets:
Einter KG
All user-level objects in a package should have documentation entries.
See the chapter 'Writing R documentation files' in manual 'Writing R
Extensions'.
I have checked "Writing R Extensions" manual, found here:
http://stuff.mit.edu/afs/sipb/project/r-project/arch/i386_rhel3/lib/R/doc/manual/R-exts.html
As instructed in the Documenting data sets, Einter and KG both have
corresponding .Rd files in the PACKAGE/man/ directory.
The contents of the applicable .Rd files are pasted below.
Does anyone have any suggestions!
Thanks very much in advance!
Charles
PACKAGE/man/KG.Rd:
\name{KG}
\docType{data}
\alias{gene positions}
\title{Position of known genes in the first 2 Mb of human chromosome 1-3. }
\description{
A data frame with 146 observations on the following 5 variables.
\describe{
\item{\code{name}}{a factor with levels \code{AB003592}
\code{AB007916} \code{AB010962} \code{AB033099} \code{AB051503}
\code{AB052096} \code{AF002246} \code{AF006011} \code{AF057061}
\code{AF057062} \code{AF067519} \code{AF070597} \code{AF070603}
\code{AF116687} \code{AF153686} \code{AF161351} \code{AF178986}
\code{AF241229} \code{AF250320} \code{AF274944} \code{AF305818}
\code{AF343078} \code{AF346307} \code{AF461903} \code{AF469129}
\code{AF490905} \code{AJ003029} \code{AJ278736} \code{AK000549}
\code{AK000591} \code{AK000615} \code{AK000886} \code{AK001208}
\code{AK021939} \code{AK023110} \code{AK023114} \code{AK023356}
\code{AK024448} \code{AK024481} \code{AK027269} \code{AK027277}
\code{AK055593} \code{AK056065} \code{AK074112} \code{AK075017}
\code{AK091144} \code{AK093189} \code{AK093239} \code{AK093438}
\code{AK093927} \code{AK093954} \code{AK094155} \code{AK094502}
\code{AK094642} \code{AK097327} \code{AK123641} \code{AK124054}
\code{AK124125} \code{AK125828} \code{AK125883} \code{AK126501}
\code{AK126870} \code{AK127149} \code{AK127994} \code{AK128042}
\code{AK128271} \code{AK128357} \code{AK128434} \code{AK128780}
\code{AK128833} \code{AL049665} \code{AL050373} \code{AL136813}
\code{AL137269} \code{AL137714} \code{AL834179} \code{AL834441}
\code{AY037150} \code{AY050570} \code{AY116620} \code{AY217347}
\code{AY358391} \code{AY358490} \code{AY358517} \code{AY358544}
\code{AY358877} \code{BC000675} \code{BC003543} \code{BC004186}
\code{BC004366} \code{BC004874} \code{BC007422} \code{BC008041}
\code{BC008070} \code{BC008374} \code{BC008375} \code{BC008788}
\code{BC009938} \code{BC013904} \code{BC014101} \code{BC014270}
\code{BC014316} \code{BC014464} \code{BC015393} \code{BC015400}
\code{BC015549} \code{BC016010} \code{BC016333} \code{BC017225}
\code{BC017762} \code{BC018701} \code{BC018779} \code{BC020699}
\code{BC021851} \code{BC022808} \code{BC025719} \code{BC029929}
\code{BC030778} \code{BC031359} \code{BC032379} \code{BC034304}
\code{BC046345} \code{BC047001} \code{BC048328} \code{BC050454}
\code{BC051194} \code{BC059409} \code{BC062579} \code{BC063107}
\code{BC063682} \code{BC066360} \code{BT007082} \code{BT007136}
\code{BT007305} \code{BX537637} \code{J02969} \code{M37712}
\code{M83653} \code{NM_003327} \code{X04526} \code{X75962}
\code{Y16846}}
\item{\code{chrom}}{a factor with levels \code{chr1} \code{chr2}
\code{chr3}}
\item{\code{strand}}{a factor with levels \code{-} \code{+}}
\item{\code{txStart}}{a numeric vector}
\item{\code{txEnd}}{a numeric vector}
}
}
\usage{data(KG)}
\format{data frame}
\source{The UCSC genome browser (http://genome.ucsc.edu).}
\keyword{datasets}
PACKAGE/man/Einter.Rd:
\name{Einter}
\docType{data}
\alias{intensities}
\title{Sample intensities for human promoter tiling array. }
\description{
Einter is a data frame consisting of 3 position information columns
(Unique ID, Start position of probe, Chromosome) and normalized
intensity data from 4 samples. Data is given for the first 3Mb of
human chromosomes 1-3.
>From the Affymetrix human promoter tiling array v02-3.
}
\usage{data(Einter)}
\format{data frame}
\source{Unpublished data, courtosy of Yanli Zhang and Frank Middleton.}
\keyword{datasets}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Dynamic linking to binary code from other packages??
Dear R-devel, I am writing a package that needs some C++ functions from an external SDK (Affymetrix fusion). The same functions are already compiled into another package (affxparser). Can I dynamically link to the compiled code in affxparser, rather than re-compiling these separately into my package? Not a lot of experience on this subject! Thanks, Charles __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Dynamic linking to binary code from other packages??
Dear, R-devel, Thanks very much for the response! Here is what I am trying to do (also listed below in the previous messages): "I am writing a package that needs some C++ functions from an external SDK (Affymetrix fusion). The same functions are already compiled into another package (affxparser)." I've looked through the "Writing R Extensions" manual, and can't find this documented very clearly. A previous question to the list gave me the very kind response pasted below. I've looked at the suggested examples (lme4 using C functions from Matrix). For lme4 to include Matrix C functions, I find it does this: -- lme4 uses the line "LinkingTo" in the description file. -- "Matrix.h" is an include in the C files. Is this all that I need to do to my package? But, of course, the header files still have to be included in the Matrix install to make this work. In the case of Matrix, it looks like the header file is located at: /usr/local/lib/R/site-library/Matrix/include/Matrix.h (under Ubuntu 8.10) How does Matrix knows to export the Matrix.h header file here? What else is the Matrix package doing to allow other packages to share its C functions? I apologize in advance if this is something obvious that I am missing! Thanks, and warmest regards, Charles On Sat, Oct 25, 2008 at 3:15 PM, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote: > > On 25 October 2008 at 16:05, Charles Danko wrote: > | Dear R-devel, > | > | I am writing a package that needs some C++ functions from an external > | SDK (Affymetrix fusion). The same functions are already compiled into > | another package (affxparser). > | > | Can I dynamically link to the compiled code in affxparser, rather than > | re-compiling these separately into my package? > > Yes. Working examples are lme4 using Matrix. This is documented in the 'R > Extensions' manual. > > | Not a lot of experience on this subject! > > I don't think it is the easiest way around. Maybe start by 'just' > recompiling and relinking. > > Dirk > > -- > Three out of two people have difficulties with fractions. > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Dynamic linking to binary code from other packages??
Dear list,
Thanks very much for all of the detailed responses! I am beginning to
understand how all of this can work, and learning quite a bit about
the C language in the process!
Can this be applied to either C++ classes or to member functions of a
class? Please forgive my lack of general C/C++ knowledge, which may
be abundantly clear in my specific questions:
It seems pretty clear that one may not register a pointer to a class
declaration and share it in this way?!
Will it work to register a pointer to a class' member functions, using
the code described by either Jeff or Simon? I looked into this, and
am pretty sure that it can not work. (Here is a good article on
registering a pointer to a class' member function:
http://www.goingware.com/tips/member-pointers.html).
So, is there any way to share either C++ classes or class member
functions with another package in R?
Again, please do forgive my inexperience.
Best,
Charles
On Thu, Nov 13, 2008 at 9:15 AM, Simon Urbanek
<[EMAIL PROTECTED]> wrote:
> On Nov 12, 2008, at 23:16 , Jeff Ryan wrote:
>
>> Charles,
>>
>>> I've looked through the "Writing R Extensions" manual, and can't find
>>> this documented very clearly. A previous question to the list gave me
>>> the very kind response pasted below. I've looked at the suggested
>>> examples (lme4 using C functions from Matrix).
>>
>> It isn't really "clearly" explained. I will give it a try though.
>>
>> You can't use compiled/packaged functions from within _your_ compiled
>> code unless the package that you are referring to (affxparser) makes
>> them available for export.
>>
>> If affxparser doesn't do this you are back to Dirk's method.
>>
>> For the sake of others who have gone down this road I will explain
>> what I know, and probably in the process learn what I may be doing
>> wrong. (all of this I learned by reading the sources for R and lme4
>> and Matrix).
>>
>> Matrix has a copy of the Matrix.h header in its /inst directory,
>> specifically /inst/include/Matrix.h
>>
>> This gets installed as /include/Matrix.h, which is where LinkingTo
>> links to during compilation.
>>
>> You (or the affxparser author) will also need a handful of C calls
>> that are complementary to ones in the package you are getting the
>> functions from.
>>
>> An example from Matrix:
>>
>> /include/Matrix_stubs.c contains
>>
>> ...
>> CHM_DN attribute_hidden
>> M_as_cholmod_dense(CHM_DN ans, SEXP x)
>> {
>> static CHM_DN(*fun)(CHM_DN,SEXP) = NULL;
>> if(fun == NULL)
>>fun = (CHM_DN(*)(CHM_DN,SEXP))
>>R_GetCCallable("Matrix", "as_cholmod_dense");
>> return fun(ans, x);
>> }
>> ...
>>
>
> FWIW this is not exactly the most efficient way to do it. It's much easier
> to do it the commonly used way of setting the function pointers directly
> (taking the situation above):
>
> CHM_DN(*M_as_cholmod_dense)(CHM_DN,SEXP);
>
> in the initialization function of the package populate all the pointers:
>
> M_as_cholmod_dense = (CHM_DN(*)(CHM_DN,SEXP)) R_GetCCallable("Matrix",
> "as_cholmod_dense");
>
> By setting the functions right away you save yourself the trouble of
> checking it on every call and using a function call twice. This allows you
> to use the function transparently in your code, so you don' t need any
> function wrappers:
>
> x = M_as_cholmod_dense(a, b);
>
> This is pretty much standard C programming, so the above should be quite
> obvious (I hope).
>
> The only reason to do it the complicated way above is if you want to do some
> extra processing in the wrapper function so your function pointer is not
> visible from outside the function.
>
> Cheers,
> Simon
>
>
>> The above is far from obvious, so I will try my best to explain.
>>
>> With respect to the R_GetCCallable call, Writing R Extensions says:
>>
>> " p_myCfun = R_GetCCallable("packA", "myCfun");
>> The author of packB is responsible for ensuring that p_myCfun has an
>> appropriate declaration. What exactly that means was hard to determine
>> at first."
>>
>> Taking the first line, the first CHM_DN is the function return type
>> (could be int, SEXP, etc), and the second (along with the SEXP) is the
>> argument type(s).
>>
>> Generalized you'd have something like:
>>
>> SEXP attribute_hidden
>> FUNNAME(SEXP ans, SEXP x)
>> {
>> static SEXP(*fun)(SEXP,SEXP) = NULL;
>> if(fun == NULL)
>>fun = (SEXP(*)(SEXP,SEXP))
>>R_GetCCallable("PACKAGE", "FUNCTION");
>> return fun(ans, x);
>> }
>>
>> lme4 then simply "#include"s this .c file in a file
>> /src/local_stubs.c, which is compiled right along side of the src code
>> in lme4.
>>
>> At this point you can then use the functions that are
>> 'exported/registered' as you would a C function defined in your own
>> package.
>>
>> The other side of this is what the Matrix (affxparser?) package needs
>> to do. It needs a registration routine that specifically registers
>> the routines as callable using:
>> R_RegisterCCallable (which is documented in Writing R Extension
