[Rd] R + C + Lapack toy regression example
dear list,
since matrix manipulations is often of interest in statistical
computations, i'd like to get a working example of using Lapack for
regression. However, i run into an error.
My matrix-lapack-example.c file:
#include
void reg(const char* trans, const int* m, const int* n,
const int* nrhs, double* a, const int* lda,
double* b, const int* ldb,
double* work, const int* lwork, int* info)
{
F77_CALL(dgels)(trans, m, n, nrhs, a, lda, b, ldb, work, lwork, info);
}
My matrix-lapack-example.R file:
dyn.load( "matrix-lapack-example.so" )
regression <- function( X, Y ){
m <- nrow( X )
n <- ncol( X )
stopifnot( m >= n , is.vector( Y ), n != length( Y ) )
mn <- min( m, n )
lwork <- mn + max( mn, 1 )
### to be used with dgels
### http://www.netlib.org/lapack/double/dgels.f
rslt <- .C( "reg"
, trans=as.character( "N" )
, m=as.integer( m ), n=as.integer( n )
, nrhs=as.integer( 1 ), a=as.double( X )
, lda=as.integer( m ), b=as.double( Y )
, ldb=as.integer( m ) , work=double( lwork )
, lwork=as.integer( lwork )
, info=integer( 1 ) )
##F77_NAME(dgels)(const char* trans, const int* m, const int* n,
##const int* nrhs, double* a, const int* lda,
##double* b, const int* ldb,
##double* work, const int* lwork, int* info);
return( rslt )
}
n <- 100
x <- rnorm( 100 )
y <- 2.5 + 3*x + rnorm( n )
X <- cbind( 1, x )
temp <- regression( X=X, Y=y )
dgels does linear least squares. the C code compile fines with a
warning (ld: warning, duplicate dylib
/usr/local/lib/libgcc_s.1.dylib). in R, i get the following when i
run regression():
> temp <- regression( X=X, Y=y )
Parameter 1 to routine DGELS was incorrect
Mac OS BLAS parameter error in DGELS , parameter #0, (unavailable), is 0
Process R exited abnormally with code 1 at Wed Sep 23 00:21:59 2009
am i doing something wrong? is my as.character() used wrong here?
i know R uses fortran code for lm. but suppose i wanted to do
regression in C/C++. is this lapack method the recommended / "best
practice" route? i just want to know whats the recommended method for
doing matrix manipulations in C. thanks!
vinh
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A couple of suggestions: source function (package base)
The
extra "\n" is located at line 142 of the current source function:
cat("\n", dep, if (do.trunc)...
HTH,
--
///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\
Jose Claudio Faria
Estatistica - prof. Titular
UESC/DCET/Brasil
joseclaudio.fa...@gmail.com
///\\\///\\\///\\\///\\\///\\\///\\\///\\\///\\\
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Strange behaviour with global variable in C
I understand global variables can be a bad idea, but even so I would like to
understand what is going on here...
### DESCRIPTION OF PROGRAM ###
...I have a strange bug on a global variable in some C code which I am compiling
using
$ MAKEFLAGS="CFLAGS=-g -O0" R CMD SHLIB myProgram.c
the global variable in question is the log likelihood. In an old version of the
program I initialized this as
double loglik = -999
and in current versions I initialize this as
double loglik = 0.0
and long sequences of 9s do not appear anywhere in the program now (I confirmed
this using the grep command in bash)
A function called update_loglik() exists in the file loglik.c and so myProgram.c
includes the line
#include "loglik.c"
prior to the main() function.
The first line in the function update_loglik() is
loglik = 0.0;
and then later in the function there is a loop containing the line
loglik += some_value_corresponding_to_one_observation
### DESCRIPTION OF BUG ###
If I add printf("%f",loglik) at the second line of update_loglik() it prints
"0.0", BUT if I set a breakpoint here and execute
(gdb) p loglik
in gdb it prints
-999
worse, the value being added to in the loop of update_loglik() is neither that
being printed by printf nor that being printed by gdb. Moreover, if I put
update_loglik() into a loop and printf the values I get
itter 0 loglik -1242105.108051
itter 1 loglik -602880.293985
itter 2 loglik -590470.733006
itter 3 loglik -578061.172026
itter 4 loglik -565651.611046
itter 5 loglik -553242.050066
itter 6 loglik -540832.489086
itter 7 loglik -528422.928106
### A CLUE ###
This is clearly a pointer problem, in fact I believe gdb gives us a good clue
(gdb) b loglik.c:100
Breakpoint 3 at 0xb7a2eba4: file loglik.c, line 100. (2 locations)
(gdb) i b
Num Type Disp Enb AddressWhat
3 breakpoint keep y0xb7a2eba4
3.1 y 0xb7a2eba4 in update_loglik at loglik.c:100
3.2 y 0xb7a2895a in update_loglik at loglik.c:100
for some reason gdb associates this breakpoint with two addresses (line 100 by
the way is where I try to set loglik to 0.0, described above)
I should perhaps also add that my project is subject to bzr (bazaar) version
control, so I wonder if this almost ghost-like resurrection of the
- is due to either gcc or gdb confusing information from current
bzr versions with previous bzr versions. This resurrection occurs even after
turning off the computer and rebooting so it shouldn't be to do with memory
leaks.
So why is gdb giving multiple addresses for a single line breakpoint and why
gdb's ghostly resurrection of a long line of 9s even after a reboot?
thanks
David
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behaviour with global variable in C
To answer my own question...
I have two copies of my program
1) a working copy stored in $PROJECT/analysis/c
2) a packaged copy stored in $PROJECT/analysis/myPackage_1.0.2.tar.gz
I have been running a script which does the following
library(myPackage)
load(myData)
detach("package:myPackge")
dyn.load("$PROJECT/analysis/c/myProgram.so")
.C("main", ...)
The "resurrection" comes from values of loglik set in the packaged version and
not used in the working version. I had assumed detach would remove all traces
of the package but this is clearly wrong.
I wonder what over developers do when they want to switch from working with a
packaged version to a working version without restarting R and without
generating conflicts between the two? (Perhaps I can find that in
documentation somewhere...)
David
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] enabling core dumps
usually what happens is (# meant to be a comment char) % R -d gdb -f test.R gdb> run ...segfault happens, breaks into gdb gdb> bt # print the backtrace gdb> up # move up the stack, to get to 'your' frame gdb> l # show source listing, use -O0 compiler flag, see gdb> help dir gdb> print some_suspect_variable gdb> call Rf_PrintValue(some_suspect_sexp) gdb> break suspect_function gdb> run # restart script, but break at suspect_function to continue a slightly old thread... ... If I launch gdb this way I don't have any means to navigate through previously executed gdb lines using M-p and M-n, but following a (gdb) run or (gdb) continue I can use M-p and M-n to recall previous R commands If I launch gdb in other ways M-p and M-n function as expected. I suppose there is a confusion between gdb's M-p and ESS's M-p so that M-p only functions in the ESS session. I quite like running gdb using R's -d flag, but not being able to navigate through the line history is sub-optimal. I'd be interested to hear if other people running gdb this way encountered this problem and how they resolved it. thanks David __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] warnings handled oddly in functions with browser calls (PR#13967)
Full_Name: Rich Calaway
Version: 2.9.2
OS: Windows Vista
Submission from: (NULL) (65.47.30.18)
Consider the following function:
myfun <- function(){
print(log(-1))
browser()
print("Good-bye!")
}
In the default case, with options(warn=0), if I call this function and type
nothing but standard browser commands (c, n, where, Q) at the browser prompt,
the warning produced by log(-1) is shown at the completion of the function, as
expected:
> myfun()
[1] NaN
Called from: myfun()
Browse[1]> c
[1] "Good-bye!"
Warning message:
In log(-1) : NaNs produced
However, if I type any other sort of R expression at the browser prompt, the
warning is issued immediately after that expression's output:
> myfun()
[1] NaN
Called from: myfun()
Browse[1]> print("hello")
[1] "hello"
Warning message:
In log(-1) : NaNs produced
Browse[1]> c
[1] "Good-bye!"
The warnings should be stored until myfun() returns.
This bug has been present at least since 2.7.2, and persists in the current
R-devel build.
Here's the sessionInfo():
> sessionInfo()
R version 2.10.0 Under development (unstable) (2009-09-21 r49780)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug 13937 (setRepositories() doesn't allow graceful cancellation from GUI menu) (PR#13968)
Hi, all- This one was moved to features&FAQ, which appears to be the "works as documented" folder, with the following note: intentional: you do need to set repositories or interrupt R. If this is true, there's still a bug, and in fact two of them: the graphical menu dialog should have no Cancel button, and the choice 0 in the text menu should send you back to the menu until you actually choose some repositories. However, there are default repositories chosen for you, and cancelling doesn't alter them, so I am not convinced that the note is true. And the original point of my bug report remains-it just seems strange to be dropped to a text menu when cancelling from a graphical menu. Rich Calaway Documentation Manager REvolution Computing, Inc. richcala...@revolution-computing.com 206-577-4778 x3204 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] FW: RE: Bug 13937 (setRepositories() doesn't allow graceful cancellation from GUI menu) (PR#13969)
Hi, again- But I see the behavior has been fixed in the current R-devel build, so sorry for the noise, and thanks for keeping R such a great package! --Rich Calaway _ From: Rich Calaway [mailto:richcala...@revolution-computing.com] Sent: Wednesday, September 23, 2009 12:32 PM To: 'r-b...@r-project.org' Subject: RE: Bug 13937 (setRepositories() doesn't allow graceful cancellation from GUI menu) Hi, all- This one was moved to features&FAQ, which appears to be the "works as documented" folder, with the following note: intentional: you do need to set repositories or interrupt R. If this is true, there's still a bug, and in fact two of them: the graphical menu dialog should have no Cancel button, and the choice 0 in the text menu should send you back to the menu until you actually choose some repositories. However, there are default repositories chosen for you, and cancelling doesn't alter them, so I am not convinced that the note is true. And the original point of my bug report remains-it just seems strange to be dropped to a text menu when cancelling from a graphical menu. Rich Calaway Documentation Manager REvolution Computing, Inc. richcala...@revolution-computing.com 206-577-4778 x3204 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Crash due to extreme example
Hello,
I was trying this bit of code (i know it is an extreme case)
g=function(r){
if(r==1)
return(list(x=1))
else
return(list(x=g(r-1)))
}
For z=g(500), the code runs but when I print z i.e
>> z
I get
*** caught bus error ***
address 0x1, cause 'non-existent physical address'
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
Running on Leopard, Macbook (intel, 4gb ram)
R version 2.9.2 (2009-08-24)
(No libraries loaded)
Saptarshi Guha | saptarshi.g...@gmail.com | http://www.stat.purdue.edu/~sguha
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Crash due to extreme example
On 23/09/2009 7:10 PM, Saptarshi Guha wrote:
Hello,
I was trying this bit of code (i know it is an extreme case)
g=function(r){
if(r==1)
return(list(x=1))
else
return(list(x=g(r-1)))
}
For z=g(500), the code runs but when I print z i.e
>> z
I get
*** caught bus error ***
address 0x1, cause 'non-existent physical address'
Thanks, an equivalent error happens here. I'll track it down.
Duncan Murdoch
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
Running on Leopard, Macbook (intel, 4gb ram)
R version 2.9.2 (2009-08-24)
(No libraries loaded)
Saptarshi Guha | saptarshi.g...@gmail.com | http://www.stat.purdue.edu/~sguha
__
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
[Rd] R v2.10.0: Doc clarification for cross references and where are we heading?
Hi,
in 'Writing R Extensions" of R v2.10.0, under Section
'Cross-references' (2009-09-07) it says:
1. "The markup \link{foo} (usually in the combination
\code{\link{foo}}) produces a hyperlink to the help for foo. Here foo
is a topic, that is the argument of \alias markup in another Rd file
(possibly in another package)."
2. "You can specify a link to a different topic than its name by
\link[=dest]{name} which links to topic dest with name name. This can
be used to refer to the documentation for S3/4 classes, for example
\code{"\link[=abc-class]{abc}"} would be a way to refer to the
documentation of an S4 class "abc" defined in your package, and
\code{"\link[=terms.object]{terms}"} to the S3 "terms" class (in
package stats). To make these easy to read, \code{"\linkS4class{abc}"}
expands to the form given above."
3. "There are two other forms of optional argument specified as
\link[pkg]{foo} and \link[pkg:bar]{foo} to link to the package pkg, to
files foo.html and bar.html respectively. These are rarely needed,
perhaps to refer to not-yet-installed packages (but there the HTML
help system will resolve the link at run time) or in the normally
undesirable event that more than one package offers help on a topic20
(in which case the present package has precedence so this is only
needed to refer to other packages). They are only in used in HTML help
(and ignored for hyperlinks in LaTeX conversions of help pages), and
link to the file rather than the topic (since there is no way to know
which topics are in which files in an uninstalled package). The *only*
reason to use these forms for base and recommended packages is to
force a reference to a package that might be further down the search
path. Because they have been frequently misused, as from R 2.10.0 the
HTML help system will look for topic foo in package pkg if it does not
find file foo.html."
Trying to summarize the above, do we have the following markups/rules?
A. \link{} - where must occur as an \alias{},
but not necessarily as an \name{}. The link will be display as
the string .
B. \link[=]{} - where must occur as an
\alias{} with a \name{}. The link will be display as the
string .
C. \link{]{} - where must be a \name{}
in a package named . The link will be display as the
string .
D. \link{:]{} - where must be a
\name{} in a package named . The link will be
display as the string . There are no restrictions on .
E. \linkS4class{} expands to
\link[=-class]{}. From (B) it then follows that
there must be an \alias{-class} and a \name{}.
Q1. Is that correct? To me it look a bit inconsistent.
Q2. Are there more?
Q3. Will there be more?
Q4. What about
\link[=]{}
\link{:]{}
where can be (almost) any string?
Q4. Are (A) and (B) only supposed to be used for linking within a
package, or can it be used to link to "wherever" exist?
Q5. It sounds that (C) and (D) should be avoided. Is that correct?
Q6. What if exist in two packages 'pkgA' and 'pkgB' and I want
to specify that I mean topic of package 'pkgA', cf namespaces
and pkgA::foo()?
Q7. I the 1st paragraph above it says "(possibly in another package)"
and in the 3rd paragraph above it is mentioned at "The only reason to
use these forms [...] is to force a reference to a package that might
be further down the search path" - is that the answer to Q4? Will
\link{} be *dynamically* linked to whatever comes first on the
search() path - to reflect the running environment rather than the
intention of the document?
Reading between the lines, the development of Rd looks exiting.
Instead of 2nd guessing where we are heading, could someone in charge
please give some thoughts on what the plans are and an estimate on how
long it will take before we are there - what R version?
MISC:
I understand that \link[=-class]{} is part of
standard Rd conventions, but to the best of my knowledge
\link[=.class]{} is not, correct? I would like
to suggest to write a separate paragraph for S4 classes without
mentioning S3 classes. The following also adds to the confusion -
there exists one Rd page with \name{terms} and one with
\name{terms.object}, so it is not really clear what
\link[=terms.object]{terms} is strictly supposed to do - is it of form
\link[=]{} or \link[=]{}. Maybe it is
helpful to clarify what the static/dynamic link will be and what will
be display.
Thanks
Henrik
PS. This is related to today's (Sept 23, 2009) BioConductor posts by
Gordon Smyth - "[Bioc-devel] BioC 2.5: "suspect" interpackage links";
https://stat.ethz.ch/pipermail/bioc-devel/2009-September/001975.html
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R v2.10.0: Doc clarification for cross references and where are we heading?
On 23/09/2009 10:08 PM, Henrik Bengtsson wrote:
Hi,
in 'Writing R Extensions" of R v2.10.0, under Section
'Cross-references' (2009-09-07) it says:
1. "The markup \link{foo} (usually in the combination
\code{\link{foo}}) produces a hyperlink to the help for foo. Here foo
is a topic, that is the argument of \alias markup in another Rd file
(possibly in another package)."
2. "You can specify a link to a different topic than its name by
\link[=dest]{name} which links to topic dest with name name. This can
be used to refer to the documentation for S3/4 classes, for example
\code{"\link[=abc-class]{abc}"} would be a way to refer to the
documentation of an S4 class "abc" defined in your package, and
\code{"\link[=terms.object]{terms}"} to the S3 "terms" class (in
package stats). To make these easy to read, \code{"\linkS4class{abc}"}
expands to the form given above."
3. "There are two other forms of optional argument specified as
\link[pkg]{foo} and \link[pkg:bar]{foo} to link to the package pkg, to
files foo.html and bar.html respectively. These are rarely needed,
perhaps to refer to not-yet-installed packages (but there the HTML
help system will resolve the link at run time) or in the normally
undesirable event that more than one package offers help on a topic20
(in which case the present package has precedence so this is only
needed to refer to other packages). They are only in used in HTML help
(and ignored for hyperlinks in LaTeX conversions of help pages), and
link to the file rather than the topic (since there is no way to know
which topics are in which files in an uninstalled package). The *only*
reason to use these forms for base and recommended packages is to
force a reference to a package that might be further down the search
path. Because they have been frequently misused, as from R 2.10.0 the
HTML help system will look for topic foo in package pkg if it does not
find file foo.html."
Trying to summarize the above, do we have the following markups/rules?
A. \link{} - where must occur as an \alias{},
but not necessarily as an \name{}. The link will be display as
the string .
B. \link[=]{} - where must occur as an
\alias{} with a \name{}. The link will be display as the
string .
C. \link{]{} - where must be a \name{}
in a package named . The link will be display as the
string .
D. \link{:]{} - where must be a
\name{} in a package named . The link will be
display as the string . There are no restrictions on .
E. \linkS4class{} expands to
\link[=-class]{}. From (B) it then follows that
there must be an \alias{-class} and a \name{}.
Q1. Is that correct? To me it look a bit inconsistent.
No, \name{} is irrelevant for links. It's the filename that matters in
the 3rd form.
Q2. Are there more?
Q3. Will there be more?
Q4. What about
\link[=]{}
\link{:]{}
where can be (almost) any string?
The first is what the 2nd form refers to. "Name" there is what is
displayed in the file making the link.
The second is new, as of 2.10.0, and is the fallback if a filename
matching is not found.
Q4. Are (A) and (B) only supposed to be used for linking within a
package, or can it be used to link to "wherever" exist?
They should work anywhere. The difficulty arises if you link to
something that a user doesn't have installed, or if the link is ambiguous.
Q5. It sounds that (C) and (D) should be avoided. Is that correct?
I think good practice is to make sure that the base of the filename
(less .Rd) is also an alias in the file, and also the \name{} of the
file. The system would probably be less confusing if this were forced,
but there are lots of files out there where it's not true.
You want the filename to be an alias because links sometimes go to
aliases and sometimes to filenames; you want the name to match because
that's what is displayed at the top of the page, so people might
remember "just go to the Foo man page".
Q6. What if exist in two packages 'pkgA' and 'pkgB' and I want
to specify that I mean topic of package 'pkgA', cf namespaces
and pkgA::foo()?
If you follow the good practice above, then use \link[pkgA]{topic}. If
you don't follow that practice, you may be out of luck, because R will
look for the filename topic.Rd in pkgA, not \alias{topic}. However, as
of 2.10.0, it will fall back to the latter.
Q7. I the 1st paragraph above it says "(possibly in another package)"
and in the 3rd paragraph above it is mentioned at "The only reason to
use these forms [...] is to force a reference to a package that might
be further down the search path" - is that the answer to Q4? Will
\link{} be *dynamically* linked to whatever comes first on the
search() path - to reflect the running environment rather than the
intention of the document?
In 2.10.0, I believe this will be the case (but I'd have to check the
code to be sure). I'd recommend being explicit if you are worried about
this possibility.
Reading between the lines, the development of Rd loo
Re: [Rd] R v2.10.0: Doc clarification for cross references and where are we heading?
On Wed, Sep 23, 2009 at 10:54 PM, Duncan Murdoch wrote: > > - Ways to link from man pages to vignettes. The reverse would be nice, but > it's not possible with the current design, so that would be far off. > If feasible I would like to be able to link to any text, html or pdf file in the package. For example, it would be nice to be able to link to the NEWS file and pdf files that are included in the package even if they are not vignettes, etc. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R v2.10.0: Doc clarification for cross references and where are we heading?
> You want the filename to be an alias because links sometimes go to aliases > and sometimes to filenames; you want the name to match because that's what > is displayed at the top of the page, so people might remember "just go to > the Foo man page". It would be really good to emphasise this somewhere. I didn't that this was best practice. It would be nice to have a base R function that converts a function name to a filename - then there would be a convention for how to do so, and perhaps some of the filename <-> function name mismatches would be resolved. A heuristic along the following lines might work: - replace . with - - modify the following special strings: * +,-,/,* to add, subtract, divide, multiply * [ to subset, [[ to subset2 * $ to dollar * $<- dollar-assign * [<- subset-assign, [[ subset2-assign Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R v2.10.0: Doc clarification for cross references and where are we heading?
On 09/24/2009 05:21 AM, Gabor Grothendieck wrote: On Wed, Sep 23, 2009 at 10:54 PM, Duncan Murdoch wrote: - Ways to link from man pages to vignettes. The reverse would be nice, but it's not possible with the current design, so that would be far off. If feasible I would like to be able to link to any text, html or pdf file in the package. For example, it would be nice to be able to link to the NEWS file and pdf files that are included in the package even if they are not vignettes, etc. I would second this wish. Adding content to the package index (00Index.html) would be a bonus as well, so that we could link the files from the index page. In addition to those mentionned by Gabor, I'm also thinking about other forms of documentation that might be in a package such as unit test results, javadoc generated documentation of java code, doxygen generated documentation of c++ code, ... Romain -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc |- http://tr.im/yw8E : New R package : sos `- http://tr.im/y8y0 : search the graph gallery from R __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
