Re: [Rd] merging environments

[Gabor Grothendieck]

On Fri, Mar 7, 2008 at 3:15 PM, hadley wickham <[EMAIL PROTECTED]> wrote:
> 2008/3/7 Ben Bolker <[EMAIL PROTECTED]>:
> >
>
> >Despite the spirited arguments of various R-core folks
> >  who feel that mle() doesn't need a "data" argument, and
> >  that users would be better off learning to deal with function
> >  closures, I am *still* trying to make such things work
> >  in a reasonably smooth fashion ...
> >
> >Is there a standard idiom for "merging" environments?
> >  i.e., suppose a function has an environment that I want
> >  to preserve, but _add_ the contents of a data list --
> >  would something like this do it? Is there a less ugly
> >  way?
> >
> >  x <- 0
> >  y <- 1
> >  z <- 2
> >
> >  f <- function() {
> >  x+y+z
> >  }
> >
> >  f2 <- function(fun,data) {
> >  L <- ls(pos=environment(fun))
> >  mapply(assign,names(data),data,
> >   MoreArgs=list(envir=environment(fun)))
> >  print(ls(pos=environment(fun)))
> >  }
> >
> >  f2(f,list(a=1))
>
> I think you're doomed to be ugly if you don't use closures - I think
> any explicit manipulation of environments is worse than the implicit
> manipulation by closures.
>
> f <- function(data) with(data, x + y + z)
> f2 <- function(fun, data) function() fun(data)
>
> f2(f, list(x = 10))()
>
> Although it would be even nicer if you could do:
>
> f <- function()  x + y + z
> f2 <- function(fun, data) function() with(data, fun())


This last one is close to what you can do with proto and is referred
to as the method of proxies here:
http://r-proto.googlecode.com/files/prototype_approaches.pdf

f <- function() x + y + z
f2 <- function(fun, ...) with(proto(environment(fun), ..., g = fun), g())
f2(f, x = 1, y = 2, z = 3)

The proto call creates an anonymous proto object whose parent is
the parent of fun.  The anonymous proto object contains the ...
arguments to f2 and g.g is just fun with its environment reset to
the anonymous proto object. We then call g.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] merging environments

[hadley wickham]

2008/3/7 Ben Bolker <[EMAIL PROTECTED]>:
>
>Despite the spirited arguments of various R-core folks
>  who feel that mle() doesn't need a "data" argument, and
>  that users would be better off learning to deal with function
>  closures, I am *still* trying to make such things work
>  in a reasonably smooth fashion ...
>
>Is there a standard idiom for "merging" environments?
>  i.e., suppose a function has an environment that I want
>  to preserve, but _add_ the contents of a data list --
>  would something like this do it? Is there a less ugly
>  way?
>
>  x <- 0
>  y <- 1
>  z <- 2
>
>  f <- function() {
>  x+y+z
>  }
>
>  f2 <- function(fun,data) {
>  L <- ls(pos=environment(fun))
>  mapply(assign,names(data),data,
>   MoreArgs=list(envir=environment(fun)))
>  print(ls(pos=environment(fun)))
>  }
>
>  f2(f,list(a=1))

I think you're doomed to be ugly if you don't use closures - I think
any explicit manipulation of environments is worse than the implicit
manipulation by closures.

f <- function(data) with(data, x + y + z)
f2 <- function(fun, data) function() fun(data)

f2(f, list(x = 10))()

Although it would be even nicer if you could do:

f <- function()  x + y + z
f2 <- function(fun, data) function() with(data, fun())

but I think that's confusing different types of scoping.

Hadley
-- 
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] merging environments

[Gabor Grothendieck]

You can either use the facilities of environments or
the proto package can do this if you take advantage of the fact
that a proto object is an environment:

> library(proto)
> f <- function() {}
> # put a into the environment of f
> do.call(proto, c(list(a = 1), envir = environment(f)))

attr(,"class")
[1] "proto"   "environment"
> ls(environment(f))
[1] "a" "f"

which does what you ask although you might prefer to create
a new environment/proto object with f in it to avoid explicit
environment manipulation:

# create proto object, i.e. environment, with a and f in it
p <- proto(a = 1, f = function(.) {})

# and you can add more variables later:
p$b <- 2
p[["c"]] <- 3
ls(p)
with(p, ls(environment(f))) # same

or with environments not using proto:

# create an unnamed environment and put a and f in
# adding b and c to it later
f <- local({ a <- 1; function(){} })
environment(f)$b <- 2
environment(f)[["c"]] <- 3

ls(environment(f))

2008/3/7 Ben Bolker <[EMAIL PROTECTED]>:
>
>   Despite the spirited arguments of various R-core folks
> who feel that mle() doesn't need a "data" argument, and
> that users would be better off learning to deal with function
> closures, I am *still* trying to make such things work
> in a reasonably smooth fashion ...
>
>   Is there a standard idiom for "merging" environments?
> i.e., suppose a function has an environment that I want
> to preserve, but _add_ the contents of a data list --
> would something like this do it? Is there a less ugly
> way?
>
> x <- 0
> y <- 1
> z <- 2
>
> f <- function() {
> x+y+z
> }
>
> f2 <- function(fun,data) {
> L <- ls(pos=environment(fun))
> mapply(assign,names(data),data,
>  MoreArgs=list(envir=environment(fun)))
> print(ls(pos=environment(fun)))
> }
>
> f2(f,list(a=1))
>
>
>
> __
> 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] merging environments

[Duncan Murdoch]

On 3/7/2008 2:02 PM, Ben Bolker wrote:
>Despite the spirited arguments of various R-core folks
> who feel that mle() doesn't need a "data" argument, and
> that users would be better off learning to deal with function
> closures, I am *still* trying to make such things work
> in a reasonably smooth fashion ...
> 
>Is there a standard idiom for "merging" environments?

One way is to set one as the parent of the other.  If they both already 
have non-empty parents, you're out of luck.

> i.e., suppose a function has an environment that I want
> to preserve, but _add_ the contents of a data list --
> would something like this do it? Is there a less ugly
> way?
> 
> x <- 0
> y <- 1
> z <- 2
> 
> f <- function() {
>  x+y+z
> }
> 
> f2 <- function(fun,data) {
>  L <- ls(pos=environment(fun))
>  mapply(assign,names(data),data,
>   MoreArgs=list(envir=environment(fun)))
>  print(ls(pos=environment(fun)))
> }
> 
> f2(f,list(a=1))

Luckily lists and data.frames don't have parents, so you can make a new 
environment, put the elements of data into it, and set the old 
environment as its parent.  That's sort of like what you did, but 
slightly different, and with fewer bad side effects:

bothenvs <- function(fun,data) {
  newenv <- new.env(hash=TRUE, parent=environment(fun))
  mapply(assign,names(data),data,
   MoreArgs=list(envir=newenv))
  newenv
}

It would sure be nice if as.environment() took a list as an arg and 
turned it into an environment, but no such luck.

Duncan Murdoch

> 
> 
> 
> 
> 
> 
> __
> 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] merging environments

[Ben Bolker]

  Despite the spirited arguments of various R-core folks
who feel that mle() doesn't need a "data" argument, and
that users would be better off learning to deal with function
closures, I am *still* trying to make such things work
in a reasonably smooth fashion ...

  Is there a standard idiom for "merging" environments?
i.e., suppose a function has an environment that I want
to preserve, but _add_ the contents of a data list --
would something like this do it? Is there a less ugly
way?

x <- 0
y <- 1
z <- 2

f <- function() {
x+y+z
}

f2 <- function(fun,data) {
L <- ls(pos=environment(fun))
mapply(assign,names(data),data,
 MoreArgs=list(envir=environment(fun)))
print(ls(pos=environment(fun)))
}

f2(f,list(a=1))




signature.asc
Description: OpenPGP digital signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Build options for R

[Simon Urbanek]

On Mar 7, 2008, at 11:20 AM, Scott Zentz wrote:

> Hello Everyone,
>
> I had posted the message below to the r-help listserv...
>
>> Recently I was given a Java servlet based web calculator that will
>> call R (libR.so to be exact) but I am having trouble trying to  
>> disable R
>> from requiring --save, --no-save or --vanilla... Is there any way to
>> build R on linux and disable R from asking --save, --no-save or
> --vanilla??
>
> I received this reply from someone...
>
>> If you are calling libR.so, it is an option set when you initialize  
>> R.
>> See Rf_initEmbeddedR in 'Writing R Extensions' and the examples in  
>> the
> tests/Embedded directory in the sources.
>> BTW, discussion of embedded R is definitely off topic for R-help: use
> the R-devel list.
>
> Now my question is. Is there any way to modify the source so that I  
> can
> force R to use the --no-save option? If so, would someone be kind  
> enough
> to show me what code I would modify to force the --no-save option?
>

Simply specify it:

char *args[]={ "R", "--no-save", 0 };
Rf_initialize_R(2, args);

Cheers,
S

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Build options for R

[Scott Zentz]

Hello Everyone,

I had posted the message below to the r-help listserv...

 >Recently I was given a Java servlet based web calculator that will
 >call R (libR.so to be exact) but I am having trouble trying to disable R
 >from requiring --save, --no-save or --vanilla... Is there any way to
 >build R on linux and disable R from asking --save, --no-save or 
--vanilla??

I received this reply from someone...

 >If you are calling libR.so, it is an option set when you initialize R.
 >See Rf_initEmbeddedR in 'Writing R Extensions' and the examples in the 
tests/Embedded directory in the sources.
 >BTW, discussion of embedded R is definitely off topic for R-help: use 
the R-devel list.

Now my question is. Is there any way to modify the source so that I can 
force R to use the --no-save option? If so, would someone be kind enough 
to show me what code I would modify to force the --no-save option?

Thanks!

-scz

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [R] R-Logo

[Barry Rowlingson]

[Think this is more R-devel than R-help now]

Gabor Csardi wrote:
> Jean,
> 
> this is nice, but 1) the logo is a bitmap, it is ugly if you 
> resize it, 2) you don't need a pdf version for pdflatex, it 
> handles jpg (and maybe also png as well), so you can 
> just use the logos at the R developer site. 
> 
> It would be really nice to have a non-bitmap version, though.
> If it exists.

  I was pondering this the other day, and decided to have a play at 
making a new R logo. Drawing inspiration from the original, and playing 
with the numbers 0, 1 and 2, I produced this:

http://www.maths.lancs.ac.uk/~rowlings/Graphics/Logo/R/logos.svg

[PNG version: 
http://www.maths.lancs.ac.uk/~rowlings/Graphics/Logo/R/logos.png ]

  - I think I've refined it a bit since then, but that has the basic 
idea and some examples of how it looks on different backgrounds. With a 
purely optional '3.0' power flash.

  As an SVG file it's purely vector and scalable.

  If the powers that be like it then I'll find my other versions (prob 
on my PC at home) and make them available.

Barry

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] NA warnings for r() {aka "patch for random.c"}

[Berwin A Turlach]

G'day Martin (and "listeners"),

On Fri, 7 Mar 2008 15:01:26 +0100
Martin Maechler <[EMAIL PROTECTED]> wrote:

[...]
> >> If you feel like finding another elegant patch...
> 
> BAT> Well, elegance is in the eye of the beholder. :-) 
> 
> BAT> I attach two patches.  One that adds warning messages at
> BAT> the other places where NAs can be generated.
> 
> ok. The result is very simple ``hence elegant''.
> 
> But actually, part of the changed behavior may be considered
> undesirable:
> 
>   rnorm(2, mean = NA)
> 
> which gives two NaN's  would now produce a warning,
> where I could argue that 
>'arithmetic with NAs should give NAs without a warning'
> since
>   1:2 + NA
> also gives NAs without a warning.
> 
> So we could argue that a warning should *only* be produced in a
> case where the parameters of the distribution are not NA.
> 
> What do others (particularly R-core !) think?

I can agree with that point of view.  But then, should a warning not
be issued only if one of the parameters of the distribution is NA, or
should it also not be issued if any non-finite parameter is
encountered?  After all, 

> 1:2 + Inf
[1] Inf Inf

does not create any warning either.  In that case, a patch as the
attached should do, it checks all parameters for finiteness and then
checks whether the generated number is not finite.  

Thus, with the patch applied I see the following behaviour:

> rnorm(2, mean=NA)
[1] NaN NaN
> rnorm(5, mean=c(0,Inf, -Inf, NA, NaN))
[1] 1.897874  NaN  NaN  NaN  NaN
> rbinom(2, size=20, p=1.2)
[1] NaN NaN
Warning message:
In rbinom(2, size = 20, p = 1.2) : NAs produced
> rexp(2, rate=-2)
[1] NaN NaN
Warning message:
In rexp(2, rate = -2) : NAs produced


Without the patch:

> rnorm(2, mean=NA)
[1] NaN NaN
> rnorm(5, mean=c(0,Inf, -Inf, NA, NaN))
[1] -0.1719657NaNNaNNaNNaN
> rbinom(2, size=20, p=1.2)
[1] NaN NaN
> rexp(2, rate=-2)
[1] NaN NaN
Warning message:
In rexp(2, rate = -2) : NAs produced

On my machine, "make check FORCE=FORCE" passes with this patch.

[...]
> For now, I will ignore this second patch.
> 
>  - it does bloat the code slightly  (as you conceded)

Fair enough. :)  I also proved my point that more complicated code is
harder to maintain.  In the two parameter case I was testing twice na
for being one instead of testing na and nb...

[...]
> but most importantly:
> 
>  - we have no idea if the speedup (when  is TRUE)
>is in the order of  10%, 1% or 0.1%
>  
>My guess would be '0.1%' for rnorm(), and that would
>definitely not warrant the extra check.

I would not bet against this.  Probably even with all the additional
checks for finiteness of parameters there would be not much speed
difference.  The question might be whether you want to replace the
(new) R_FINITE()'s rather by ISNA()'s (or something else).  One could
also discuss in which order the checks should be made (first generated
number then parameters of distribution or vice versa).  But I will
leave this to R-core to decide. :)

> >> Thank you Berwin, for your contribution!
> 
> and thanks again!

Still my pleasure. :)

Cheers,

Berwin
Index: src/main/random.c
===
--- src/main/random.c   (revision 44693)
+++ src/main/random.c   (working copy)
@@ -44,7 +44,7 @@
 for (i = 0; i < n; i++) {
ai = a[i % na];
x[i] = f(ai);
-   if (!R_FINITE(x[i])) naflag = 1;
+   if (!R_FINITE(x[i]) && R_FINITE(ai)) naflag = 1;
 }
 return(naflag);
 }
@@ -81,6 +81,7 @@
 if (na < 1) {
for (i = 0; i < n; i++)
REAL(x)[i] = NA_REAL;
+warning(_("NAs produced"));
 }
 else {
PROTECT(a = coerceVector(CADR(args), REALSXP));
@@ -116,14 +117,14 @@
ai = a[i % na];
bi = b[i % nb];
x[i] = f(ai, bi);
-   if (!R_FINITE(x[i])) naflag = 1;
+   if (!R_FINITE(x[i]) && R_FINITE(ai) && R_FINITE(bi)) naflag = 1;
 }
 return(naflag);
 }
 
 #define RAND2(num,name) \
case num: \
-   random2(name, REAL(a), na, REAL(b), nb, REAL(x), n); \
+   naflag = random2(name, REAL(a), na, REAL(b), nb, REAL(x), n); \
break
 
 /* "do_random2" - random sampling from 2 parameter families. */
@@ -155,6 +156,7 @@
 if (na < 1 || nb < 1) {
for (i = 0; i < n; i++)
REAL(x)[i] = NA_REAL;
+warning(_("NAs produced"));
 }
 else {
PROTECT(a = coerceVector(CADR(args), REALSXP));
@@ -200,14 +202,14 @@
bi = b[i % nb];
ci = c[i % nc];
x[i] = f(ai, bi, ci);
-   if (!R_FINITE(x[i])) naflag = TRUE;
+   if (!R_FINITE(x[i]) && R_FINITE(ai) && R_FINITE(bi) && R_FINITE(ci)) 
naflag = TRUE;
 }
 return(naflag);
 }
 
 #define RAND3(num,name) \
case num: \
-   random3(name, REAL(a), na, REAL(b), nb, REAL(c), nc, REAL(x), 
n); \
+   naflag = random3(name, REAL(a), na, RE

[Rd] NA warnings for r() {aka "patch for random.c"}

[Martin Maechler]

Hi Berwin (and "listeners"),

> "BAT" == Berwin A Turlach <[EMAIL PROTECTED]>
> on Wed, 5 Mar 2008 20:26:24 +0800 writes:

BAT> G'day Martin, On Mon, 3 Mar 2008 10:16:45 +0100 Martin
BAT> Maechler <[EMAIL PROTECTED]> wrote:

>> > "BAT" == Berwin A Turlach <[EMAIL PROTECTED]> >
>> on Fri, 29 Feb 2008 18:19:40 +0800 writes:
>> 
BAT> while looking for some inspiration of how to organise
BAT> some code, I studied the code of random.c and noticed
BAT> that for distributions with 2 or 3 parameters the user
BAT> is not warned if NAs are created while such a warning
BAT> is issued for distributions with 1 parameter. [...] The
BAT> attached patch rectifies this.  [...]
>> 
>> I cannot imagine a design reason for that.  If there was,
>> it should have been mentioned as a comment in the C code.
>> 
>> I'll commit your patch (if it passes the checks).

BAT> Sorry, I was a bit in a hurry when writing the e-mail,
BAT> so I forgot to mention that the source code modified by
BAT> this patch compiles and passes "make check FORCE=FORCE"
BAT> on my machine.

ok.

BAT> And in my hurry, I also posted from my NUS account,
BAT> without realising it, which forced you to intervene as
BAT> moderator and to approve the posting.  My apologies for
BAT> the extra work.  But this gave me the idea to also
BAT> subscribe to r-devel with my NUS account and configure
BAT> the subscriptions so that I only receive e-mail at my
BAT> UWA account.  Thus, hopefully, you will not have to
BAT> intervene again.  (Which this e-mail should test.)

(and it succeeded)
 
BAT> BTW, there are other places in the code were NAs can be
BAT> created but no warning is issued.  E.g:
>> 
>> >> rexp(2, rate=numeric())
BAT> [1] NA NA
>> >> rnorm(2, mean=numeric())
BAT> [1] NA NA
>> 
BAT> I wonder whether a warning should be issued in this
BAT> case too.
>> 
>> Yes, "should in principle".
>> 
>> If you feel like finding another elegant patch...

BAT> Well, elegance is in the eye of the beholder. :-) 

BAT> I attach two patches.  One that adds warning messages at
BAT> the other places where NAs can be generated.

ok. The result is very simple ``hence elegant''.

But actually, part of the changed behavior may be considered
undesirable:

  rnorm(2, mean = NA)

which gives two NaN's  would now produce a warning,
where I could argue that 
   'arithmetic with NAs should give NAs without a warning'
since
  1:2 + NA
also gives NAs without a warning.

So we could argue that a warning should *only* be produced in a
case where the parameters of the distribution are not NA.

What do others (particularly R-core !) think?

BAT> The second one in additiona rearranges the code a bit
BAT> such that in the case when all the "vectors" that
BAT> contain the parameter values of the distribution, from
BAT> which one wants to simulate, are of length one some
BAT> unnecessary calculations is taken out of the for loop.

BAT> I am not sure how much time is actually saved in this
BAT> situation, but I belong to the school that things such
BAT> kind of optimisation should be done. :) 

I understand, but I think most of R-core are "from the school" 
that teaches
 "if you want to optimize, first *measure*"

BAT> If you think it bloats the code too much (or duplicates
BAT> things too much leading to hard to maintain code), then
BAT> feel free to ignore this second patch.

For now, I will ignore this second patch.

 - it does bloat the code slightly  (as you conceded)
 - it uses an if() test which makes the code slightly
   *slower* for the (probably rare) case when the  is false.

but most importantly:

 - we have no idea if the speedup (when  is TRUE)
   is in the order of  10%, 1% or 0.1%
 
   My guess would be '0.1%' for rnorm(), and that would
   definitely not warrant the extra check.

>> Thank you Berwin, for your contribution!

and thanks again!
Martin

BAT> My pleasure.

BAT> Cheers,
BAT>Berwin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Installing latest version under Windows (PR#10908)

[Duncan Murdoch]

On 3/6/2008 9:35 PM, [EMAIL PROTECTED] wrote:
> Dear Debuggers,
> 
> =20
> 
> I'm trying to install R for the first time, however, the exe file
> referred to does not exist: Installation is via the installer
> R-2.6.2-win32.exe
> 
> =20
> 
> I've downloaded R several times and the file does not exist.

This statement doesn't make sense.  Either you downloaded it and it does 
exist, or it does not exist because you failed to download it.

What URL are you using?  I see that file at

http://cran.r-project.org/bin/windows/base/R-2.6.2-win32.exe

Is that what you're downloading?

Duncan Murdoch

> 
> =20
> 
> I've tried renaming Rgui.exe.manifest and Rterm.exe.manifest to have
> only the .exe extension and but this doesn't work.=20
> 
> =20
> 
> What are your suggestions?
> 
> =20
> 
> Regards
> 
> =20
> 
> Rebecca
> 
> 
> 3 Installing R under Windows
> 
> 
> The bin/windows directory of a CRAN site contains binaries for a base
> distribution and a large number of add-on packages from CRAN to run on
> Windows 95, 98, NT4, 2000, ME, XP, 2003 Server and Vista (at least) on
> Intel x86 and clones (including AMD64/EM64T chips and Windows x64).=20
> 
> Your file system must allow long file names (as is likely except perhaps
> for some network-mounted systems).=20
> 
> Installation is via the installer R-2.6.2-win32.exe. Just double-click
> on the icon and follow the instructions. You can uninstall R from the
> Control Panel. (Note that you will probably (depending on the Windows
> language settings) be asked to choose a language for installation, and
> that choice applies to both installation and un-installation but not to
> running R itself.)=20
> 
> See the R Windows FAQ
>   for more
> details.=20
> 
> =20
> 
> __
> 
> 
> 
> Rebecca Oyomopito [EMAIL PROTECTED]
> TASER Surveillance and Monitoring Study Coordinator=20
> Biostatistics and Databases Program
> National Centre in HIV Epidemiology and Clinical Research (NCHECR)
> The University of New South Wales
> 376 Victoria Street Sydney NSW  2010 AUSTRALIA
> Phone: + 61 (0) 2 9385 0900
> Fax: + 61 (0) 2 9385 0920
> http://web.med.unsw.edu.au/nchecr/
> 
> 
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> 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] Installing latest version under Windows (PR#10908)

[Royomopito]

Dear Debuggers,

=20

I'm trying to install R for the first time, however, the exe file
referred to does not exist: Installation is via the installer
R-2.6.2-win32.exe

=20

I've downloaded R several times and the file does not exist.

=20

I've tried renaming Rgui.exe.manifest and Rterm.exe.manifest to have
only the .exe extension and but this doesn't work.=20

=20

What are your suggestions?

=20

Regards

=20

Rebecca


3 Installing R under Windows


The bin/windows directory of a CRAN site contains binaries for a base
distribution and a large number of add-on packages from CRAN to run on
Windows 95, 98, NT4, 2000, ME, XP, 2003 Server and Vista (at least) on
Intel x86 and clones (including AMD64/EM64T chips and Windows x64).=20

Your file system must allow long file names (as is likely except perhaps
for some network-mounted systems).=20

Installation is via the installer R-2.6.2-win32.exe. Just double-click
on the icon and follow the instructions. You can uninstall R from the
Control Panel. (Note that you will probably (depending on the Windows
language settings) be asked to choose a language for installation, and
that choice applies to both installation and un-installation but not to
running R itself.)=20

See the R Windows FAQ
  for more
details.=20

=20

__



Rebecca Oyomopito [EMAIL PROTECTED]
TASER Surveillance and Monitoring Study Coordinator=20
Biostatistics and Databases Program
National Centre in HIV Epidemiology and Clinical Research (NCHECR)
The University of New South Wales
376 Victoria Street Sydney NSW  2010 AUSTRALIA
Phone: + 61 (0) 2 9385 0900
Fax: + 61 (0) 2 9385 0920
http://web.med.unsw.edu.au/nchecr/




[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel