[Rd] PR#9848
Oops -- I meant R version 2.5.1, not 1.5.1. My apologies. -- Russell V. Lenth, Professor Department of Statistics & Actuarial Science(319)335-0814FAX (319)335-3017 The University of Iowa [EMAIL PROTECTED] Iowa City, IA 52242 USA http://www.stat.uiowa.edu/~rlenth/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Hin-Tak Leung wrote:
> Tobias Verbeke wrote:
>
>> Actually, I think Hin-Tak is right about the absolute path. Even when
>> the R code will call the executable that resides in that directory, R
>> will call it from any directory and that (current) directory will be
>> resolved (at least that is what I observe experimentally).
>>
>> When such an absolute path is coded in, everything runs fine -- we now
>> can run a BUGS script from within R under GNU/Linux !
>>
>> It would however be nice to solve the remaining problem of the
>> absolute path in the dlopen() call, i.e. being able to fill in
>> `dynamically' the library path to which the package is actually
>> installed.
>>
>> Is there a way to have the library path to which a package is
>> installed available during package installation and then to do some
>> text-processing to fill in this path dynamically into the C file i.e.
>> as argument of dlopen() before compiling it?
>
>
> I don't know if there is a neater way of doing this, but one somewhat
> clunky way is to process the result of .libPath() , append each of its
> elements by /inst/OpenBUGS/bugs.so and test if the file exists,
> (.libPath() should be quite a small character vector so it should be too
> slow to test every one), then pass the result as an explicit
> argument to the main bugs binary before everything else it takes.
>
> I think there is a more clever way of telling where the current package
> is installed/located but it escapes me at the moment. Perhaps the source
> code of data() (just typying 'data' without the () at the comment prompt
> will display the source), can shed some lights on this, since data()
> does something quite similiar.
Thank you, Hin-Tak, for pointing me in the right direction.
Please find below the final C code I use to get OpenBUGS
running.
#include
#include
#include
int main (int argc, char *argv[])
{
void * handle;
void (*cli)(void);
char * error;
char * sopath;
sopath = argv[1]; /* path of brugs.so */
handle = dlopen(sopath, RTLD_LAZY);
if (!handle) {
fprintf (stderr, "%s\n", dlerror());
exit(1);
}
* (void **) (&cli) = dlsym(handle, "CLI");
if ((error = dlerror()) != NULL) {
fprintf (stderr, "%s\n", error);
exit(1);
}
(*cli)();
dlclose(handle);
return 0;
}
At the R level, the use of system.file seemed to me to be
the most generally applicable. The relevant lines from the
calling R code are:
## construct system command
exe <- if (iswin) "bugs.exe" else "linbugs"
sofile <- "brugs.so"
OpenBUGSpath <- system.file("OpenBUGS", package = "CGHmix")
pathexe <- file.path(OpenBUGSpath, exe)
pathso <- file.path(OpenBUGSpath, sofile)
cmd <- if (iswin){
paste(pathexe, "<", scriptfile, ">", resultsfile, sep = " ")
} else {
paste(pathexe, pathso, "<", scriptfile, ">", resultsfile,
sep = " ")
}
system(cmd)
The resulting package now allows for using an embedded OpenBUGS
on GNU/Linux without relying on WINE. Thanks to all for their helpful
comments.
Kind regards,
Tobias
--
Tobias Verbeke - Consultant
Business & Decision Benelux
Rue de la révolution 8
1000 Brussels - BELGIUM
+32 499 36 33 15
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] PR#9848
The behaviour you quote is the documented behaviour in R 2.5.1.
Please do RTFM, especially ?install.packages:
'install.packages' can be used to install new packages/bundles. It
takes a vector of names and a destination library, downloads the
packages from the repositories and installs them. (If the library
is omitted it defaults to the first directory in '.libPaths()',
with a warning if there is more than one.) If 'lib' is omitted or
is of length one and is not a (group) writeable directory, the
code offers to create a personal library tree (the first element
of 'Sys.getenv("R_LIBS_USER")') and install there. Detection of a
writeable directory is problematic on Windows: see the Warning
section.
Now, it is entirely possible that Windows is mis-reporting on the
permissions available, but that would not be a bug in R and one that is
warned about (twice) on the help page.
That you can write a specific file there is not the issue, as the help
page explains in detail. You need to be able to write specfic types of
files there, and a recent WinXP patch stops you being able to do that on
networked drives.
On Mon, 13 Aug 2007, [EMAIL PROTECTED] wrote:
> Oops -- I meant R version 2.5.1, not 1.5.1. My apologies.
So you did mean 1.4.1? Two separate major version errors suggest that you
really are insufficiently unaware of what you are using.
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hasNA() / anyNA()?
Why not hasNA <- function(x) !is.na(match(NA, x)) -Ben __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hasNA() / anyNA()?
On Tue, 2007-08-14 at 07:48 -0400, Benjamin Tyner wrote: > Why not > > hasNA <- function(x) !is.na(match(NA, x)) > > -Ben It does not save anything: Vec1 <- c(NA, rep(1, 1000)) Vec2 <- c(rep(1, 1000), NA) > system.time(!is.na(match(NA, Vec1))) user system elapsed 1.053 0.217 1.404 > system.time(!is.na(match(NA, Vec2))) user system elapsed 1.049 0.242 1.360 Note, there is no difference in execution time between the two. Review the source code for match() in unique.c and you will see why. Now try: > system.time(any(is.na(Vec1))) user system elapsed 0.242 0.079 0.358 > system.time(any(is.na(Vec2))) user system elapsed 0.255 0.067 0.321 Still essentially no time difference, but notably faster than using match(). To get much faster, you would likely need to code a new function in C, patterned after Kurt's reply. HTH, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hasNA() / anyNA()?
On Tue, 14 Aug 2007, Benjamin Tyner wrote: > Why not > > hasNA <- function(x) !is.na(match(NA, x)) It hashes the whole table (here x) and so is both slower and uses more memory than is.na(x). I am not clear what is meant by 'efficiency' here, or why it is needed (we have not been told). But writing a C-level function to do this would have taken less time that this discussion has already taken -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hasNA() / anyNA()?
S-PLUS has an anyMissing() function, for which the default is:
anyMissing.default <-
function(x){
(length(which.na(x)) > 0)
}
This is more efficient than any(is.na(x)) in the usual case that there
are few or no missing values. There are methods for vectors that drop
to C code, and methods for data frames and other classes.
The code below seems to presume a list, and would be very slow for vectors.
For reasons of consistency between S-PLUS and R, I would ask that an R
function be called anyMissing rather than hasNA or anyNA.
Tim Hesterberg
>is there a hasNA() / an anyNA() function in R? Of course,
>
>hasNA <- function(x) {
> any(is.na(x));
>}
>
>would do, but that would scan all elements in 'x' and then do the
>test. I'm looking for a more efficient implementation that returns
>TRUE at the first NA, e.g.
>
>hasNA <- function(x) {
> for (kk in seq(along=x)) {
>if (is.na(x[kk]))
> return(TRUE);
> }
> FALSE;
>}
>
>Cheers
>
>Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Fwd: behavior of L-BFGS-B with trivial function triggers bug in stats4::mle]
On Mon, Aug 13, 2007 at 05:49:51PM -0400, Ben Bolker wrote: [snip] > an undefined condition), but it leads to a bug in stats4::mle -- > a spurious error saying that a better fit > has been found during profiling if one tries to profile > a 1-parameter model that was originally fitted with "L-BFGS-B". [snip] Could you also include a script, which reproduces the problem? Just to see under which conditions the problem occurs and how it looks like exactly. Petr Savicky. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Fwd: behavior of L-BFGS-B with trivial functi on triggers bug in stats4::mle]
Petr Savicky cs.cas.cz> writes: > Could you also include a script, which reproduces the problem? Just > to see under which conditions the problem occurs and how it > looks like exactly. > > Petr Savicky. > The original post has such a script, just under the dashed line and above the diff/patch. Sorry if I wasn't clear about that. cheers Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Tobias Verbeke businessdecision.com> writes: > The resulting package now allows for using an embedded OpenBUGS > on GNU/Linux without relying on WINE. Thanks to all for their helpful > comments. woo-hoo! this is great! Any chance that this will propagate to the R2WinBUGS package at some point ... ??? Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Fwd: behavior of L-BFGS-B with trivial function triggers bug in stats4::mle]
Ben Bolker wrote: > Petr Savicky cs.cas.cz> writes: > > > >> Could you also include a script, which reproduces the problem? Just >> to see under which conditions the problem occurs and how it >> looks like exactly. >> >> Petr Savicky. >> >> > > The original post has such a script, just under the dashed line > and above the diff/patch. Sorry if I wasn't clear about that. > > Patch inserted in r-devel now. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sligthly OT Re: Makefile for embedding OpenBUGS in R package
Hi Ben, > Tobias Verbeke businessdecision.com> writes: > >> The resulting package now allows for using an embedded OpenBUGS >> on GNU/Linux without relying on WINE. Thanks to all for their helpful >> comments. > > woo-hoo! this is great! Any chance that this will propagate > to the R2WinBUGS package at some point ... ??? A quick look at R2WinBUGS reveals that this package does not embed the OpenBUGS distribution within the package. This is not needed per se, but will then imply that the user has to compile the C file that accesses the brugs.so shared library (or a variant as the path to the bugs executable is an argument to the bugs function in R2WinBUGS). When I worked on this (for a specific application a client had in mind), I deliberately chose to avoid any administration in addition to ordinary R package installation. The BRugs package, on the contrary, embeds a (previous) version of OpenBUGS and could use what we found out in this thread, but then the interface of BRugs is more designed for interactive use of BUGS which currently still is possible only on Windows. It might be an idea to modify the BRugsFit function (BRugs' meta function) to run a script file in one go when it runs on GNU/Linux. This modification is needed as the current BRugsfit uses the "interactive" commands modelCheck(), modelCompile() etc. in separate steps. If the maintainer (in cc) would think this is a good idea, the following things should then be assured within the BRugs package in addition of changing BRugsFit function for it to work under Linux: (1) all of the BUGS files (data, model, inits and script files) should have CR LF line endings (2) the script file produced should end on modelQuit() without any additional character (no newline) Alternatively, it could be put into (yet another) R <-> BUGS package, but this would duplicate a lot of the BRugs code. Kind regards, Tobias -- Tobias Verbeke - Consultant Business & Decision Benelux Rue de la révolution 8 1000 Brussels - BELGIUM +32 499 36 33 15 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
