[Rd] LAPACK Headers
Hey Everyone, I'm running R 2.4.0 on Debian etch 4.0, and I'm trying to call some LAPACK functions from the C code in my package. Actually, to be honest I'm not really having trouble using commands such as La_dgesv from within my C code, but I do get warning when compiling the package saying: ***.c: In function '***': ***.c:37: warning: implicit declaration of function 'La_dgesv' ***.c:37: warning: assignment makes pointer from integer without a cast I tried using: #include but it won't compile the package at all with that included, complaining that ***.h:5:30: error: Rmodules/Rlapack.h: No such file or directory Can someone explain to me how I should include the headers to this AWESOME wrapper code to the LAPACK libraries? Am I not following the proper protocol by using these La_* commands in my package source code? Note, I also have the following in Makevars PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) TIA! I initially posted this question on the general list, but I didn't get any responses. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] LAPACK Headers
On Thu, Jun 14, 2007 at 11:27:44PM +0100, Hin-Tak Leung wrote:
> Try this? (this is on 2.5.0, I don't use 2.4.x anymore)
>
> #include
>
I tried this, but I still get the warning of implicit declaration of
function. It does compile though.
> Have you actually tried grep dgesv $R_HOME/include/* $R_HOME/include/*/*
> to see which file to include for dgesv ??
Well, when I grep the R source files, I get:
$ find . -name "*" -print | xargs grep -i 'La_dgesv'
./src/main/basedecl.h:SEXP La_dgesv(SEXP, SEXP, SEXP);
./src/main/lapack.c:SEXP La_dgesv(SEXP A, SEXP B, SEXP tol)
./src/main/lapack.c:SEXP La_dgesv(SEXP A, SEXP B, SEXP tol)
./src/main/registration.c:CALLDEF(La_dgesv, 3),
./src/library/base/R/solve.R: .Call("La_dgesv", a, b, tol, PACKAGE
= "base")
./src/library/base/R/solve.R: drop(.Call("La_dgesv", a,
as.matrix(b), tol, PACKAGE = "base")))
./src/modules/lapack/Lapack.c:static SEXP modLa_dgesv(SEXP A, SEXP
Bin, SEXP tolin)
./src/modules/lapack/Lapack.c:tmp->dgesv = modLa_dgesv;
./src/include/Rmodules/Rlapack.h:typedef SEXP (*Rf_La_dgesv)(SEXP A,
SEXP B, SEXP tol);
./src/include/Rmodules/Rlapack.h:Rf_La_dgesv dgesv;
So it looks like La_dgesv is declared in basedecl.h, but I don't see
this file anywhere else on my machine. Maybe I shouldn't be using
this function in my package?
>
> HTL
>
> [EMAIL PROTECTED] wrote:
> >Hey Everyone,
> >
> >I'm running R 2.4.0 on Debian etch 4.0, and I'm trying to call some
> >LAPACK functions from the C code in my package. Actually, to be
> >honest I'm not really having trouble using commands such as La_dgesv
> >from within my C code, but I do get warning when compiling the package
> >saying:
> >
> >***.c: In function '***':
> >***.c:37: warning: implicit declaration of function 'La_dgesv'
> >***.c:37: warning: assignment makes pointer from integer without
> >a cast
> >
> >I tried using:
> >
> >#include
> >
> >but it won't compile the package at all with that included,
> >complaining that
> >
> >***.h:5:30: error: Rmodules/Rlapack.h: No such file or directory
> >
> >Can someone explain to me how I should include the headers to this
> >AWESOME wrapper code to the LAPACK libraries? Am I not following the
> >proper protocol by using these La_* commands in my package source
> >code?
> >
> >Note, I also have the following in Makevars
> >
> >PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
> >
> >TIA!
> >
> >I initially posted this question on the general list, but I didn't get
> >any responses.
> >
> >__
> >R-devel@r-project.org mailing list
> >https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian J. Lopes
PhD Student
Department of Statistics and Operations Research
University of North Carolina at Chapel Hill
To know that we know what we know, and that we do not know what we do
not know, that is true knowledge --Henry David Thoreau (quoting
Confucius): Walden
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] LAPACK Headers
Prof. Ripley,
I had a feeling I was going a little too deep into the R source code
in order to pull out these functions. I particularly like these La_*
functions calling the LAPACK routines, because they have so much of
the error checking already built-in. I can just copy the code over,
and hopefully it will pick up everything in my package, but I do have
two questions.
1. I seem to vaguely recall that the R-ext documentation mentions
that routines such as this could possibly change. So if someone
wants to use any of the LAPACK or BLAS routines in their source
code, they should really only refer to the programs in
R_ext/Lapack.h?
2. I think the LAPACK utilities are key in R, and help new
researchers avoid having to use proprietary code such as Numerical
Recipes when doing their research. Is there a reason why code
such as the La_* wrapper functions are not ``public''? I really
think they're quite useful.
Thanks,
Brian
On Fri, Jun 15, 2007 at 06:45:09AM +0100, Prof Brian Ripley wrote:
> He wants "La_dgesv", which is not an LAPACK entry point at all, but a
> private part of R. The header it is in is private and not installed.
>
> There is no guarantee that it will remain visible to an R package, and the
> only safe thing to do is to copy the code.
>
> On Thu, 14 Jun 2007, [EMAIL PROTECTED] wrote:
>
> >On Thu, Jun 14, 2007 at 11:27:44PM +0100, Hin-Tak Leung wrote:
> >>Try this? (this is on 2.5.0, I don't use 2.4.x anymore)
> >>
> >>#include
> >>
> >
> >I tried this, but I still get the warning of implicit declaration of
> >function. It does compile though.
> >
> >>Have you actually tried grep dgesv $R_HOME/include/* $R_HOME/include/*/*
> >>to see which file to include for dgesv ??
> >
> >Well, when I grep the R source files, I get:
> >
> >$ find . -name "*" -print | xargs grep -i 'La_dgesv'
> >./src/main/basedecl.h:SEXP La_dgesv(SEXP, SEXP, SEXP);
> >./src/main/lapack.c:SEXP La_dgesv(SEXP A, SEXP B, SEXP tol)
> >./src/main/lapack.c:SEXP La_dgesv(SEXP A, SEXP B, SEXP tol)
> >./src/main/registration.c:CALLDEF(La_dgesv, 3),
> >./src/library/base/R/solve.R: .Call("La_dgesv", a, b, tol, PACKAGE
> >= "base")
> >./src/library/base/R/solve.R: drop(.Call("La_dgesv", a,
> >as.matrix(b), tol, PACKAGE = "base")))
> >./src/modules/lapack/Lapack.c:static SEXP modLa_dgesv(SEXP A, SEXP
> >Bin, SEXP tolin)
> >./src/modules/lapack/Lapack.c:tmp->dgesv = modLa_dgesv;
> >./src/include/Rmodules/Rlapack.h:typedef SEXP (*Rf_La_dgesv)(SEXP A,
> >SEXP B, SEXP tol);
> >./src/include/Rmodules/Rlapack.h:Rf_La_dgesv dgesv;
> >
> >So it looks like La_dgesv is declared in basedecl.h, but I don't see
> >this file anywhere else on my machine. Maybe I shouldn't be using
> >this function in my package?
> >
> >
> >
> >>
> >>HTL
> >>
> >>[EMAIL PROTECTED] wrote:
> >>>Hey Everyone,
> >>>
> >>>I'm running R 2.4.0 on Debian etch 4.0, and I'm trying to call some
> >>>LAPACK functions from the C code in my package. Actually, to be
> >>>honest I'm not really having trouble using commands such as La_dgesv
> >>>from within my C code, but I do get warning when compiling the package
> >>>saying:
> >>>
> >>>***.c: In function '***':
> >>>***.c:37: warning: implicit declaration of function 'La_dgesv'
> >>>***.c:37: warning: assignment makes pointer from integer without
> >>>a cast
> >>>
> >>>I tried using:
> >>>
> >>>#include
> >>>
> >>>but it won't compile the package at all with that included,
> >>>complaining that
> >>>
> >>>***.h:5:30: error: Rmodules/Rlapack.h: No such file or directory
> >>>
> >>>Can someone explain to me how I should include the headers to this
> >>>AWESOME wrapper code to the LAPACK libraries? Am I not following the
> >>>proper protocol by using these La_* commands in my package source
> >>>code?
> >>>
> >>>Note, I also have the following in Makevars
> >>>
> >>>PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
> >>>
> >>>TIA!
> >>>
> >>>I initially posted this question on the general list, but I didn't get
> >>>any responses.
> >>>
> >>>__
> >>>R-devel@r-project.org mailing list
> >>>https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> >
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
--
Brian J. Lopes
PhD Student
Department of Statistics and Operations Research
University of North Carolina at Chapel Hill
To know that we know what we know, and that we do not know what we do
not know, that is true knowledge --Henry David Thoreau (quoting
Confucius): Walden
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Basic Question on error(_(...
I'm sorry to bother this list with such trivial questions, but I'm
trying to take Prof. Ripley's advice in porting some Lapack wrappers
into my own code, because they are not public. I'm specifically
choosing programs from R-2.5.0/src/modules/lapack/Lapack.c.
I can't seem to understand the context in functions such as:
error(_("the leading minor of order %d is not positive
definite"),
i);
in functions such as modLa_chol. Is there some place I can look to
understand the usage of the underscore '_', or could someone explain
this to me?
Thanks for the help!
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Nested SEXP functions
Hey All,
I was wondering if I could solicit a little advice. I have been
experiencing some quirkiness in my C code through .Call.
Unfortunately, my program is rather large, so I'm trying to create a
brief example. Yet before I do, I thought maybe a conceptual question
would be sufficient.
Basically, I'm writing up a multidimensional Gaussian likelihood (with
spatial covariances and other enhancements). What I'm noticing is
that when I have nested SEXP functions I get inconsistent results.
Here is what I am essentially trying to accomplish when looking at the
Gaussian kernel:
l(beta) = (y-X*beta)^T V^{-1} (y-X*beta)
Now in order to accomplish this, I wrote various linear algebra
subroutines to handle the R objects, we'll call this:
SEXP XtimesY(SEXP X,SEXP Y); // X*Y
SEXP XminusY(SEXP X,SEXP Y); // X-Y
SEXP tX(SEXP X); // X^T
SEXP mycholinv(SEXP V); // Use cholesky decomposition for inverse
Now, what I'm noticing is that if I call each routine individually
such as:
pt1=XtimesY(X,beta); // X*beta
pt2=Xminus(Y,pt1); // Y-X*beta
pt3=tX(pt2); // (Y-X*beta)^T
pt4=mycholinv(V); //V^{-1}
pt5=XtimesY(pt2,pt4); // (Y-X*beta)^T V^{-1}
result=XtimesY(pt5,pt2); //(y-X*beta)^T V^{-1} (y-X*beta)
Then the result is correct. But if instead I want to save some lines
of code, and I use:
result=XtimesY(XtimesY(tX(XminusY(Y,XtimesY(X,beta))),mycholinv(V)),XminusY(Y,XtimesY(X,beta)))
I don't always get the same result. Now my question is, should I
expect weird and ugly things to happen when nesting SEXP functions
such as this? Or is it even highly discouraged in general in C to do
something like this?
If this should work, then I'll need to go through each one of the
functions and try to diagnose where the problem lies. Yet if it
shouldn't work, I'll stick with the first approach I have going now.
Thanks in advance for your input!
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Nested SEXP functions
On Thu, Nov 15, 2007 at 11:53:53PM +, Oleg Sklyar wrote:
> You assume that when you call any of those functions its arguments are
> protected (as it is the case when the function is called from within R).
> However, I do not see why they would be if you do not do it explicitly.
> Therefore, it is very likely that a result of one function, used in turn
> in a call to the other one, is garbage collected on the way and what you
> get can be totally wrong. The more R API calls you have within each of
> those functions, the more likely it is that the unprotected argument is
> garbage collected as the events are triggered within some of those
> calls.
>
> One should be very careful about protecting things in .Call interface.
> Now here is what I mean in a coding example:
Oleg,
Ah Ha!!! I was sure that I protected everything within each one of
the modular functions, so I couldn't understand why my results were
similar to a garbage collection issue. That is, on small examples I
would get the right result, but on large data it would keep failing
with wild numbers.
What you say makes complete sense, and is completely consistent with
the documentation. I appreciate the examples and how they emphasize
your point, and I'm even more grateful that you saved me the effort of
having to write sample code to ask my question.
After reading your advice, I just realized something. Instead of
doing this all within my main program, I could reduce the annoying
steps in my main code by writing the Gaussian kernel as another
modular function. It would essentially accomplish the same goal!
Thanks!
>
> ## R CODE #
> z1 = .Call("interfaceCFun1", as.numeric(x)) # OK
> z2 = .Call("interfaceCFun12", as.numeric(x)) # Can be !OK
>
> SEXP f1(SEXP);
>
> // C code
> SEXP interfaceCFun(SEXP x) {
> / /x is protected, so it prints smth and returns new var to R
> return f1(x);
> }
> SEXP interfaceCFun2(SEXP x) {
> // for first call to f1 it prints smth of x and returns new var
> // to the second call, however in the second call the argument is no
> // more x, it is no more protected and can be released by GC, so it is
> // no clear what it is going to print there!
> return f1(f1(x));
>
> // this would be correct:
> SEXP y;
> PROTECT(y=f1(x));
> // now when we print in the following function we have memory
> protected
> y = f1(y)
> UNPROTECT(1);
> return y;
> }
>
> SEXP f1(SEXP x) {
> Rprintf("\n"); // can possibly trigger garbage collector
> Rprintf(REAL(x)[0]);
> return allocVector(REALSXP,2);
> }
>
> Best,
>
> Oleg
>
>
> On Thu, 2007-11-15 at 17:10 -0500, [EMAIL PROTECTED] wrote:
> > Hey All,
> >
> > I was wondering if I could solicit a little advice. I have been
> > experiencing some quirkiness in my C code through .Call.
> > Unfortunately, my program is rather large, so I'm trying to create a
> > brief example. Yet before I do, I thought maybe a conceptual question
> > would be sufficient.
> >
> > Basically, I'm writing up a multidimensional Gaussian likelihood (with
> > spatial covariances and other enhancements). What I'm noticing is
> > that when I have nested SEXP functions I get inconsistent results.
> >
> > Here is what I am essentially trying to accomplish when looking at the
> > Gaussian kernel:
> >
> > l(beta) = (y-X*beta)^T V^{-1} (y-X*beta)
> >
> > Now in order to accomplish this, I wrote various linear algebra
> > subroutines to handle the R objects, we'll call this:
> >
> > SEXP XtimesY(SEXP X,SEXP Y); // X*Y
> > SEXP XminusY(SEXP X,SEXP Y); // X-Y
> > SEXP tX(SEXP X); // X^T
> > SEXP mycholinv(SEXP V); // Use cholesky decomposition for inverse
> >
> > Now, what I'm noticing is that if I call each routine individually
> > such as:
> >
> > pt1=XtimesY(X,beta); // X*beta
> > pt2=Xminus(Y,pt1); // Y-X*beta
> > pt3=tX(pt2); // (Y-X*beta)^T
> > pt4=mycholinv(V); //V^{-1}
> > pt5=XtimesY(pt2,pt4); // (Y-X*beta)^T V^{-1}
> > result=XtimesY(pt5,pt2); //(y-X*beta)^T V^{-1} (y-X*beta)
> >
> > Then the result is correct. But if instead I want to save some lines
> > of code, and I use:
> >
> > result=XtimesY(XtimesY(tX(XminusY(Y,XtimesY(X,beta))),mycholinv(V)),XminusY(Y,XtimesY(X,beta)))
> >
> > I don't always get the same result. Now my question is, should I
> > expect weird and ugly things to happen when nesting SEXP functions
> > such as this? Or is it even highly discouraged in general in C to do
> > something like this?
> >
> > If this should work, then I'll need to go through each one of the
> > functions and try to diagnose where the problem lies. Yet if it
> > shouldn't work, I'll stick with the first approach I have going now.
> >
> > Thanks in advance for your input!
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Returning vectors of two different data types back to R environment (from C).
On Fri, Nov 16, 2007 at 03:49:09PM -0500, Charles Danko wrote: > 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. Yes, it's really quite reasonable to do, although it's not documented in detail in the R-extensions manual. As stated earlier, this will only work with .Call and SEXP functions where you can handle R objects within C. In Section 5.9 "Evaluating R expressions in C" it has an example using lists in C. Basically, lists are VECSXP objects so you can search for that in R-exts. Also, I would recommend looking at 5.7.6 "Handling lists" and the function: SEXP getListElement(SEXP list, char *str) You should look for that, and then grep the source files for examples. If you don't have grep to search the files, then I would recommend the R gonzui site: http://rgonzui.nakama.ne.jp/ Personally, I found the source code for det() to be a useful example, you can search for that on R gonzui. Good Luck __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
