[Rd] long double, C, fortran
I'm using .Call() to call C code from R under Windows (on an Intel Core 2 duo). The C code involves some very small numbers, and I think I'm losing precision using doubles. I thought I might use long doubles to see if I can get that precision back. I have a few questions: 1. Does this affect the portability to other OSs or processors? 2. I'm returning the results in a matrix. Will a matrix of REALs be sufficient for holding long doubles, or will it be cast back to doubles? 3. Will calls to FORTRAN BLAS (like dsymv, dpotrf, dpotri) still work with long doubles? Thanks for any help you can provide. -- Richard D. Morey Assistant Professor Psychometrics and Statistics Rijksuniversiteit Groningen / University of Groningen http://drsmorey.org/research/rdmorey __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problem with OSX binary package build?
I noticed that my package BayesFactor (http://cran.r-project.org/web/packages/BayesFactor/index.html) is not available on Mac OS, and the note says to see the check log. The only issue in the check log is a note: checking R code for possible problems ... NOTE all.Nways.env.mc : : no visible binding for global variable 'i' all.Nways.env.mc: no visible binding for global variable 'i' This is due to the fact that I'm using the foreach package. Do I need to change something to get the OSX binary on CRAN? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with OSX binary package build?
Yes, I was looking at the right package. At some point last night it changed from "not available (see check log)" to available. Previous to "not available (see check log)" it was "not available (the package is either new or...)" So when it changed to "not available (see check log)" I assumed there was a problem. Richard On 15/10/12 2:06 PM, Simon Urbanek wrote: On Oct 14, 2012, at 9:33 AM, Richard D. Morey wrote: I noticed that my package BayesFactor (http://cran.r-project.org/web/packages/BayesFactor/index.html) is not available on Mac OS, and the note says to see the check log. Are you sure you're looking at the right page? CRAN says Downloads: Package source: BayesFactor_0.8.3.tar.gz MacOS X binary: BayesFactor_0.8.3.tgz Windows binary: BayesFactor_0.8.3.zip Cheers, Simon The only issue in the check log is a note: checking R code for possible problems ... NOTE all.Nways.env.mc : : no visible binding for global variable 'i' all.Nways.env.mc: no visible binding for global variable 'i' This is due to the fact that I'm using the foreach package. Do I need to change something to get the OSX binary on CRAN? __ 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] concurrent requests (Rook, but I think the question is more general)
This question involves Rook, but I think the answer will be general
enough that it pays to post here. At any rate, I don't know enough to
know whether this is a Rook only issue or a general R issue.
Here's what I'd like to do (and indeed, have code that should do this):
1. Start R, Rook
2. Start an analysis via a HTTP request to Rook. This analysis uses
.Call() to some compiled C code, if that matters. The C code calls a
callback function to update a variable with its progress.
3. While the analysis is happening, use Rook to obtain current status
with an HTTP request
The problem is that once the analysis starts, Rook does not respond to
requests. All of the status requests to Rook pile up, and then are
answered when the analysis (step 2) is done. Here is some example code
to demonstrate what the issue:
##
library(Rook)
s <- Rhttpd$new()
s$add(
name="pingpong",
app=Rook::URLMap$new(
'/ping' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$write('This is ping.')
Sys.sleep(20)
res$finish()
},
'/pong' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$write("This is pong.")
res$finish()
},
'/?' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$redirect(req$to_url('/pong'))
res$finish()
}
)
)
s$start(quiet=TRUE)
s$browse('pingpong')
#
If you request /ping, R runs Sys.sleep() for 20 seconds. This is where
my .Call() statement would be. While the .Call() (Sys.sleep()) function
is doing its thing, I need to get Rook to respond on /pong (which would
simply respond with the progress), but if you run this code, request
/ping, then immediately request /pong, you'll see that the /pong request
will not be answered until the Sys.sleep() is done.
Of course, for a progress report to be useful, the requests have to be
answered immediately. Is this a Rook issue, or an R issue? Or am I
asking something unreasonable?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] concurrent requests (Rook, but I think the question is more general)
On 24/10/12 8:53 PM, Simon Urbanek wrote:
On Oct 24, 2012, at 2:13 PM, Richard D. Morey wrote:
This question involves Rook, but I think the answer will be general enough that
it pays to post here. At any rate, I don't know enough to know whether this is
a Rook only issue or a general R issue.
Here's what I'd like to do (and indeed, have code that should do this):
1. Start R, Rook
2. Start an analysis via a HTTP request to Rook. This analysis uses .Call() to
some compiled C code, if that matters. The C code calls a callback function to
update a variable with its progress.
3. While the analysis is happening, use Rook to obtain current status with an
HTTP request
You can't. R doesn't support threading so it's simply not possible to have an
asynchronous eval. The R HTTP server works by simply enqueuing an eval to run
while R is idle, it can't do that if R is busy. (Note that the HTTP server was
*only* designed for the internal help).
What you can do is have your C code start another thread that reports the
progress when asked e.g. on a socket, but that thread is not allowed to call
any R API so you want that progress to be entirely in your C code.
How can I start a new thread? By running R again from the command line,
or is there a better way?
Note that if your C code is robust enough, it can call R_CheckUserInterrupt()
to allow external events to happen, but a) your C code must in that case be
prepared for early termination (clean up memory etc.) and b) I don't remember
if the httpd is allowed to run during interrupt check on all platforms - you
may want to check that first.
I do use R_CheckUserInterrupt(), but if I understand what you're saying
then given that it doesn't work, httpd must not run during the interrupt
check. At least, on OSX, which is what I'm testing on.
Cheers,
Simon
The problem is that once the analysis starts, Rook does not respond to
requests. All of the status requests to Rook pile up, and then are answered
when the analysis (step 2) is done. Here is some example code to demonstrate
what the issue:
##
library(Rook)
s <- Rhttpd$new()
s$add(
name="pingpong",
app=Rook::URLMap$new(
'/ping' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$write('This is ping.')
Sys.sleep(20)
res$finish()
},
'/pong' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$write("This is pong.")
res$finish()
},
'/?' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$redirect(req$to_url('/pong'))
res$finish()
}
)
)
s$start(quiet=TRUE)
s$browse('pingpong')
#
If you request /ping, R runs Sys.sleep() for 20 seconds. This is where my
.Call() statement would be. While the .Call() (Sys.sleep()) function is doing
its thing, I need to get Rook to respond on /pong (which would simply respond
with the progress), but if you run this code, request /ping, then immediately
request /pong, you'll see that the /pong request will not be answered until the
Sys.sleep() is done.
Of course, for a progress report to be useful, the requests have to be answered
immediately. Is this a Rook issue, or an R issue? Or am I asking something
unreasonable?
__
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] concurrent requests (Rook, but I think the question is more general)
Richard D. Morey
Assistant Professor
Psychometrics and Statistics
Rijksuniversiteit Groningen / University of Groningen
http://drsmorey.org/research/rdmorey
On 24/10/12 9:23 PM, Simon Urbanek wrote:
On Oct 24, 2012, at 3:09 PM, Richard D. Morey wrote:
On 24/10/12 8:53 PM, Simon Urbanek wrote:
On Oct 24, 2012, at 2:13 PM, Richard D. Morey wrote:
This question involves Rook, but I think the answer will be general enough that
it pays to post here. At any rate, I don't know enough to know whether this is
a Rook only issue or a general R issue.
Here's what I'd like to do (and indeed, have code that should do this):
1. Start R, Rook
2. Start an analysis via a HTTP request to Rook. This analysis uses .Call() to
some compiled C code, if that matters. The C code calls a callback function to
update a variable with its progress.
3. While the analysis is happening, use Rook to obtain current status with an
HTTP request
You can't. R doesn't support threading so it's simply not possible to have an
asynchronous eval. The R HTTP server works by simply enqueuing an eval to run
while R is idle, it can't do that if R is busy. (Note that the HTTP server was
*only* designed for the internal help).
What you can do is have your C code start another thread that reports the
progress when asked e.g. on a socket, but that thread is not allowed to call
any R API so you want that progress to be entirely in your C code.
How can I start a new thread? By running R again from the command line, or is
there a better way?
No, you have to use the system thread API like pthreads, NSThread etc. If you
have to ask about this, you probably don't want to go there ;) - threads can be
quite dangerous if you are not familiar with them.
Another poor man's solution is to simply have your C code write out a file with
the progress. Along the same lines you could use a shared object to store the
progress (e.g. via bigmemory) ...
I'd be fine with the poor man's solution (maybe with tempfile()?) if I
can get access to the local file via javascript. But I don't think I
can, due to the security limitations of the browser. I may have to
rethink this significantly.
Note that if your C code is robust enough, it can call R_CheckUserInterrupt()
to allow external events to happen, but a) your C code must in that case be
prepared for early termination (clean up memory etc.) and b) I don't remember
if the httpd is allowed to run during interrupt check on all platforms - you
may want to check that first.
I do use R_CheckUserInterrupt(), but if I understand what you're saying then
given that it doesn't work, httpd must not run during the interrupt check. At
least, on OSX, which is what I'm testing on.
Yes, if your code calls R_CheckUserInterrupt() and httpd doesn't respond at
that point then it may not be allowed to run. On OS X you can try your luck
with R_ProcessEvents() as well.
Cheers,
Simon
Cheers,
Simon
The problem is that once the analysis starts, Rook does not respond to
requests. All of the status requests to Rook pile up, and then are answered
when the analysis (step 2) is done. Here is some example code to demonstrate
what the issue:
##
library(Rook)
s <- Rhttpd$new()
s$add(
name="pingpong",
app=Rook::URLMap$new(
'/ping' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$write('This is ping.')
Sys.sleep(20)
res$finish()
},
'/pong' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$write("This is pong.")
res$finish()
},
'/?' = function(env){
req <- Rook::Request$new(env)
res <- Rook::Response$new()
res$redirect(req$to_url('/pong'))
res$finish()
}
)
)
s$start(quiet=TRUE)
s$browse('pingpong')
#
If you request /ping, R runs Sys.sleep() for 20 seconds. This is where my
.Call() statement would be. While the .Call() (Sys.sleep()) function is doing
its thing, I need to get Rook to respond on /pong (which would simply respond
with the progress), but if you run this code, request /ping, then immediately
request /pong, you'll see that the /pong request will not be answered until the
Sys.sleep() is done.
Of course, for a progress report to be useful, the requests have to be answered
immediately. Is this a Rook issue, or an R issue? Or am I asking something
unreasonable?
__
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] concurrent requests (Rook, but I think the question is more general)
On 24/10/12 10:07 PM, Simon Urbanek wrote: On Oct 24, 2012, at 3:47 PM, Richard D. Morey wrote: I'd be fine with the poor man's solution (maybe with tempfile()?) if I can get access to the local file via javascript. But I don't think I can, due to the security limitations of the browser. I may have to rethink this significantly. That should be no problem, you can have another R instance serving the monitoring page (or you can use Rserve's HTTP server and have just one instance with arbitrarily many connections as needed). OK, I'm looking at Rserve. I get the impression that one needs to start a separate server, so it would be difficult to make this transparent to a user who installs my package and just wants to do an analysis with a GUI. It also appears that there is a separate binary install, at least on Windows, which would mean anyone using my package would need to install and run something separate. Is that accurate? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] concurrent requests (Rook, but I think the question is more general)
On 24/10/12 10:55 PM, Simon Urbanek wrote:
The point is that you need a separate monitoring process or threads. That
process can be R, Rserve or any thing else.
Thanks for the tips. This is what I'm currently contemplating:
1. Main interface starts in user's R session, and opens up the interface
(HTML/Javascript using Rook package)
2. When analysis starts, Rserve is started, with its own web server,
using Rook, for status updates
3. During analysis, main process calls a callback function which uses
RSassign() to send progress updates to the Rserve server
4. HTML/Javascript interface can connect to the webserver on the Rserve
server to get status updates
5. When analysis is done, use RSshutdown() and RSclose() to clean up.
Does this seem reasonable?
One problem I'm having is that when I start Rook on the Rserve server,
the webserver does not respond (although it is started). Does Rserve
only respond to requests on the port assigned for RSclient commands?
Best,
Richard
Here's an example:
###
library(Rserve)
### This works:
stuff = expression({
library(Rook)
s <- Rhttpd$new()
s$add(
app=system.file('exampleApps/helloworld.R',package='Rook'),
name='hello'
)
s$start(quiet=TRUE)
s$browse(1)
print(s$full_url(1))
})
# This will open the browser to the test app, asking for your name
eval(stuff)
### This does not:
Rserve(args="--no-save")
c <- RSconnect()
RSassign(c, stuff)
# This opens the browser to the correct URL, but the webserver doesn't
respond.
RSeval(c, quote(eval(stuff)))
#
# cleanup
RSshutdown(c)
RSclose(c)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] concurrent requests (Rook, but I think the question is more general)
On 25/10/12 7:14 PM, Dan Tenenbaum wrote:
On Thu, Oct 25, 2012 at 8:45 AM, Richard D. Morey wrote:
On 24/10/12 10:55 PM, Simon Urbanek wrote:
The point is that you need a separate monitoring process or threads. That
process can be R, Rserve or any thing else.
Thanks for the tips. This is what I'm currently contemplating:
1. Main interface starts in user's R session, and opens up the interface
(HTML/Javascript using Rook package)
2. When analysis starts, Rserve is started, with its own web server, using
Rook, for status updates
3. During analysis, main process calls a callback function which uses
RSassign() to send progress updates to the Rserve server
4. HTML/Javascript interface can connect to the webserver on the Rserve
server to get status updates
5. When analysis is done, use RSshutdown() and RSclose() to clean up.
Does this seem reasonable?
One problem I'm having is that when I start Rook on the Rserve server, the
webserver does not respond (although it is started). Does Rserve only
respond to requests on the port assigned for RSclient commands?
Best,
Richard
Here's an example:
###
library(Rserve)
### This works:
stuff = expression({
library(Rook)
s <- Rhttpd$new()
s$add(
app=system.file('exampleApps/helloworld.R',package='Rook'),
name='hello'
)
s$start(quiet=TRUE)
s$browse(1)
print(s$full_url(1))
})
# This will open the browser to the test app, asking for your name
eval(stuff)
### This does not:
Rserve(args="--no-save")
c <- RSconnect()
RSassign(c, stuff)
# This opens the browser to the correct URL, but the webserver doesn't
respond.
RSeval(c, quote(eval(stuff)))
#
# cleanup
RSshutdown(c)
RSclose(c)
This "works" for me if I omit the quote(). I get an error, but the
webapp seems to work. Also, I didn't eval(stuff) locally, only on the
server:
I'll try this in a bit and see what happens.
I forgot my sessionInfo()...
> sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8
attached base packages:
[1] tools stats graphics grDevices utils datasets methods
base
other attached packages:
[1] Rook_1.0-8 brew_1.0-6 Rserve_0.6-8
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] paths and Rook problems only in OSX CRAN binary package?
Hi everyone,
I'm trying to diagnose a problem in my R package, but it is a little
tricky since it seems to occur only with the Mac OSX CRAN binary build.
My package starts a Rook server and opens a browser. On my own system
(details below), when I build the package, I have no trouble. The Rook
server starts and the page loads in the browser.
However, if I've installed it from CRAN, I get the following error when
trying to open my Rook interface:
##
Warning message:
In normalizePath(file.path(root, path_info)) :
path[1]="/Volumes/XT3/Rdev-web/QA/Simon/packages/leopard-universal/Rlib/2.15/BayesFactor/.//www/warning.html":
No such file or directory
##
I assume "Simon" refers to Simon Urbanek.
www/warning.html is the file Rook is attempting to open. This looks like
a path from the CRAN build machine. How did this make it into my
package? I'm sort of baffled, and I don't know how to diagnose it.
To replicate:
#
install.packages('BayesFactor')
library(BayesFactor)
data(puzzles)
aovGUI(y = puzzles$RT, dataFixed = puzzles[,3:4], dataRandom = puzzles$ID)
#
When I set
options(warning.expression = quote(recover()))
I see where the problem lies. In the frame "15: file_server$call(env)",
the variable "root" is defined as:
Browse[1]> root
[1]
"/Volumes/XT3/Rdev-web/QA/Simon/packages/leopard-universal/Rlib/2.15/BayesFactor/."
But "find" returns nothing for "root":
Browse[1]> find("root")
character(0)
In the Rook source here
(https://github.com/jeffreyhorner/Rook/blob/master/Rook/R/File.R) is the
reference to "root", but I'm not sure where the specific path value
comes from.
Further information:
> sessionInfo()
R version 2.15.2 (2012-10-26)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.15.2
My Rook version is 1.0-8 and I'm running Mountain Lion (10.8.2). Any
hints would be appreciated.
Best,
Richard
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] preparing for R 3.0.0
I am preparing my package for the release of R 3.0.0 and thinking about the suggestion (from Duncan Murdoch) to maintain two versions of the package temporarily. Since my package contains knitr-compiled vignettes, I need to restrict it to 3.0.0 going forward. I'd like to submit a final version for 2.x that will not be updated but compiles the vignettes in the old manner; and a version for 3.x. My thought is that they will have the same version number, with the only difference being how the vignette is compiled and the DESCRIPTION files. Is it possible that they have the same version number; or, should I send two updates simultaneously with successive version numbers, flagging one as restricted to R >3.0.0? Thanks, Richard __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] missing exported methods when compiling vignettes in R 3.0.0 RC
A new problem has cropped up with compiling vignettes for my package BayesFactor. I'm not sure when it started, but I can tell you it didn't occur on R 2.15.3, and it does on 3.0.0 RC (2013-03-31 r62463) (session info is at the bottom of this message). I have defined methods for which.min and which.max for a class (I've defined both S3 and S4 methods for the class "BFBayesFactor") in my package. I've exported the S4 class using exportMethods, and declared the S3 method with S3method. You can see the NAMESPACE file here: https://r-forge.r-project.org/scm/viewvc.php/pkg/BayesFactorPCL/NAMESPACE?view=markup&root=bayesfactorpcl and the methods here: https://r-forge.r-project.org/scm/viewvc.php/pkg/BayesFactorPCL/R/methods-BFBayesFactor.R?view=markup&root=bayesfactorpcl I have code in a vignette that calls the which.max method on a BFBayesFactor object. However, when that happens as the vignette is being compiled, I get an error: which.max(bf) ## Error: no method for coercing this S4 class to a vector This also occurs with which.min, but oddly not any other method (including the is.na method, which is declared exactly the same way, as far as I can tell). This seems to imply that the which.min and which.max methods are not exported. When I use double colon notation - which as I understand, only works with exported functions - it works (see below). When I compile the Rmd file manually, I do not see this problem; I get no errors. This seems to be a problem unique to compiling the vignette. I've tried it in Rstudio, R from the command line, and using Rscript and calling knitr directly. It only occurs when building a vignette for the source package. Steps to reproduce: 1. Check out latest version of BayesFactor package from R-forge (https://r-forge.r-project.org/scm/?group_id=554) (revision 320) 2. Create a source package (which compiles the vignette) 3. Open tar to see compiled vignette HTML (doc/manual.html - or, alternatively, see https://www.dropbox.com/s/6csznytp8i1akjl/manual.html). Search for second occurrence of "which.max", and see the following lines: ## which model index is the best? is(bf, "BFBayesFactor") ## [1] TRUE BayesFactor::which.max(bf) ## complaints ## 1 BayesFactor::which.min(bf) ## critical + advance ## 21 which.max(bf) ## Error: no method for coercing this S4 class to a vector which.min(bf) ## Error: no method for coercing this S4 class to a vector I've been pulling my hair out on this, especially because something seems to have changed over the past few weeks that caused this, but I didn't catch exactly when, and I don't know if the issue lies with R 3.0.0 or my package. > sessionInfo() R version 3.0.0 RC (2013-03-31 r62463) Platform: x86_64-apple-darwin10.8.0 (64-bit) locale: [1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] BayesFactor_0.9.5 markdown_0.5.4 knitr_1.1.6 coda_0.16-1 lattice_0.20-15 loaded via a namespace (and not attached): [1] digest_0.6.3 evaluate_0.4.3 formatR_0.7 grid_3.0.0 mvtnorm_0.9-9994 [6] pbapply_1.0-5 stringr_0.6.2 tools_3.0.0 Any help would be greatly appreciated, Richard __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] missing exported methods when compiling vignettes in R 3.0.0 RC
OK, so I think until we figure this out and/or the fix is on CRAN I can work
around it using eval=FALSE with some hidden code blocks to hide the double
colon notation. I've installed the latest revision of knitr, and it does fix
the problem.
On Tuesday, 2 April 2013 at 4:40 AM, Yihui Xie wrote:
> I do not know much about S4, but I figured out one possible solution
> on knitr's side, which I do not really understand. In short, your S4
> methods need to be evaluated in globalenv(), but knitr uses the
> parent.frame() by default, which is not the global environment when it
> is called as the vignette builder.
>
> Now I have forced the evaluation to be in the global environment, and
> pushed the changes to the knitr development version on Github:
> https://github.com/yihui/knitr
>
> Regards,
> Yihui
> --
> Yihui Xie mailto:xieyi...@gmail.com)>
> Phone: 515-294-2465 Web: http://yihui.name
> Department of Statistics, Iowa State University
> 2215 Snedecor Hall, Ames, IA
>
>
> On Mon, Apr 1, 2013 at 7:37 PM, Henrik Bengtsson (mailto:h...@biostat.ucsf.edu)> wrote:
> > Hi,
> >
> > things have indeed changed on how non-Sweave vignettes are built (this
> > happened around R devel 2013-03-05 r62130). However, it's not clear
> > to me what changes would be behind your problems, if any.
> >
> > Build your vignette with the following buildVignette(), which emulates
> > what R does when it builds vignettes (cf. tools::buildVignettes()).
> > As you'll see, it reproduces your error:
> >
> > if (!exists("buildVignette", mode="function")) {
> > source("http://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/R.rsp/R/buildVignette.R?root=r-dots";);
> > }
> >
> > EXAMPLE (in a fresh R session):
> >
> > url <-
> > "http://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/BayesFactorPCL/vignettes/manual.Rmd?root=bayesfactorpcl";
> > if (!file.exists("manual.Rmd")) download.file(url, "manual.Rmd");
> >
> > output <- buildVignette("manual.Rmd", buildPkg="knitr");
> > browseURL(output);
> >
> > bfr <- readLines(output);
> > idxs <- grep("which.max(bf)", bfr, fixed=TRUE);
> > idxs <- sort(sapply(idxs, FUN=function(idx) idx+(-5:5)));
> > cat(sprintf("%03d: %s\n", idxs, bfr[idxs]));
> >
> > > cat(sprintf("%03d: %s", idxs, bfr[idxs]), sep="\n")
> > 2517:
> > 2518:
> > 2519: ## [1] TRUE
> > 2520:
> > 2521:
> > 2522: BayesFactor::which.max(bf)
> > 2523:
> > 2524:
> > 2525: ## complaints
> > 2526: ## 1
> > 2527:
> > 2531:
> > 2532: ## critical + advance
> > 2533: ## 21
> > 2534:
> > 2535:
> > 2536: which.max(bf)
> > 2537:
> > 2538:
> > 2539: ## Error: no method for coercing this S4 class to a vector
> > 2540:
> > 2541:
> >
> > So, have a look at browseVignette() and how it calls the 'knitr' weave
> > function. That should help you narrow down what's going on.
> >
> > > sessionInfo()
> > R version 3.0.0 RC (2013-03-31 r62463)
> > Platform: x86_64-w64-mingw32/x64 (64-bit)
> >
> > 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] tools stats graphics grDevices utils datasets methods
> > [8] base
> >
> > other attached packages:
> > [1] BayesFactor_0.9.3 markdown_0.5.4 coda_0.16-1 lattice_0.20-15
> > [5] knitr_1.1.7
> >
> > loaded via a namespace (and not attached):
> > [1] digest_0.6.3 evaluate_0.4.3 formatR_0.7 grid_3.0.0
> > [5] mvtnorm_0.9-9994 pbapply_1.0-5 stringr_0.6.2
> >
> > Hope this helps
> >
> > /Henrik
> >
> > On Mon, Apr 1, 2013 at 4:52 PM, Richard D. Morey > (mailto:r.d.mo...@rug.nl)> wrote:
> > > A new problem has cropped up with compiling vignettes for my package
> > > BayesFactor. I'm not sure when it started, but I can tell you it didn't
> > > occur on R 2.15.3, and it does on 3.0.0 RC (2013-03-31 r62463) (session
> > > info is at the bottom of this message).
> > >
> > > I have defined methods for which.min and which.max for a class (I've
> > > defined both S3 and S4 methods for the class "BFBayesFactor") in my
> > > package. I've exported the S4 c
[Rd] matrix algebra in c
I'd like to use some matrix algebra in my c code that is called from R. I need matrix multiplication, transposition, and Cholesky decomposition. I haven't come across any easy way to do this, but from browsing the web and R-devel a few options come to mind: 1. use F77_CALL() to call matrix multiplication functions from blas. This should be ok as long as I remember that c and FORTRAN store matrices differently. 2. include gsl code and link against the gsl binaries? This seems like it would cause problems compiling it on different systems. 3. write my own code (bad idea) 4. Call R from my C code (slow?) What's the best/easiest way? I don't really care how the matrices are represented in c (could be gsl_matrix, SEXP, whatever) as long as it works. Thanks, Richard Morey __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
