Re: [Rd] upgrading an R installation to next versoin

[Gabor Grothendieck]

I have been thinking a bit more about the Windows R installation
upgrade discussion below and there are really two cases:

1. one wants to upgrade R and is no longer interested in preserving
the old versions of R

In this case one could configure R to have a ..\R\library folder that 
contains the library and *.site files so that they do not have to be 
moved each time that one upgrades R.  (The old versions of R still 
access the same library and *.site files as the new versions of R 
and over time its likely that they won't work any more with the old
versions of R as we start using the features of the newer R
but in this case we don't really care.)  The problem here is that
the defaults do not support this and one must set environment
variables which complicates setup.   I have some batch files
which will automatically set them although if R would automatically:
1. look into ...\R\library if it cannot find ...\R\rw...\library and 
2. look for ...\R\etc\*.site if it cannot find them in ...\R\rw...\etc\*.site
this could be streamlined substantially.  The only danger in
supporting this is that anyone who used this facility would
not be preserving the identity of different versions on his
system -- although that is already true if they use R_PROFILE,
etc. since that applies to all versions too.

2. one wants to upgrade R but wants to maintain the old versions
in working order.

In this case we need to snapshot the library and *.site files so
we might as well keep them in a version-specific area, viz.
...\R\rw...\library and ...\R\rw...\etc\*.site
and then copy them over to the new version of R when that
new version is installed (so that as they change over time
with the new version the old version of R still has its older
ones).

Thus I would suggest that we:

1. by default search for ..\R\library and \R\*.site if those are not
otherwise found

2. have an option to allow or disallow the installation program to
copy over *.site
and library files from the old version to the new version (or else provide 
registry information on what the old and new versions are so that one can 
write a program to do it oneself)




On 6/30/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 6/30/2005 8:10 AM, Gabor Grothendieck wrote:
> > When I install a new version of R (Windows XP) I have to:
> >
> > 1. copy my rw\etc\Rprofile.site file to the new installation
> >
> > 2. copy the rw\share\texmf files to the tex subfolder of the
> >miktex root directory and then refresh the miktex name database
> >(I have a batch file that does this for me which I run
> >whenever I install a new version of R.)
> >
> > 3. setup the shortcut key using 'properties' on my R desktop icon so
> >that ctrl-alt-R brings up the new rather than the old R.  (This one
> >really had me confused once since I did not realize I was still
> >using the old version of R after installing the new one.)
> >
> > 4. reinstall the packages I use or else setup etc\Renviron.site with
> >an R_LIBS to point to include the old library or perhaps one can
> >copy the libraries over being careful not to overwrite new versions
> >of the standard libraries.
> >
> > Many other windows program automatically transfer the settings when
> > you upgrade them.
> >
> > I wonder if the installation process could optionally transfer
> > such settings from an old installation to a new one to make it
> > easier to install R.
> 
> I think a couple of these could be handled by not applying so many
> modifications to the R installation, do more locally.  For example, #1
> needn't be copied, you can just use the R_ENVIRON environment variable
> to point to it and both versions will see it.
> 
> I'd call #2 a bug in MikTeX, but it's probably one we'll have to work
> around one of these days.  (The bug is dropping support for the
> environment variable specification of extra include directories.)
> 
> #3 might be something we could do, but I don't see how.  The installer
> could know what hotkey you used the last time you installed R, but if
> you changed it in the meantime, how would it know about that?  And how
> would it remove the hotkey from the old shortcut?  (A little
> experimentation suggests that XP is buggy in handling multiple shortcuts
> with the same hotkey.  I'd rather stay away from this.)
> 
> #4 is another case where you can put your libraries outside R_HOME.
> 
> Duncan Murdoch
>

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

Re: [Rd] (PR#7951) DispatchOrEval missing in do_isfinite and do_isinfinite

[lars]

Hi,

I ran into another internal function that is missing S4 dispatch. It is 
the binary operator ":". Looking at the code, I see that it is actually 
a common problem. Other candidates are operators like "~", "&&", "||" 
and functions like: "length<-", "row", "col", "unlist", "cbind", etc. It 
would for instance be nice to be able to write a matrix class that has 
the same operators and functions as the built-in class. In general, I 
think that all the operators and functions associates with built-in 
types like vectors, lists, matrices and data frames should have S4 dispatch.

Thanks,
Lars

lars wrote:

> Hi,
>
> OK, if you try to explicitly make them generic, you are told that they 
> are implicitly already generic:
>
> > setGeneric("is.finite", function(from, ...) 
> standardGeneric("is.finite"))
> Error in setGeneric("is.finite", function(from, ...) 
> standardGeneric("is.finite")) :
>"is.finite" is a primitive function;  methods can be defined, but 
> the generic function is implicit, and can't be changed.
>
> If you query about its genericness before you define you own generic, 
> you get:
>
> > isGeneric("is.finite")
> [1] FALSE
>
> But after you define you own generic, you get:
>
> > setMethod("is.finite", signature(x="TS"),
> +   function(x) {
> +  Data(x) = callNextMethod()
> +  x
> +   })
> [1] "is.finite"
>
> > isGeneric("is.finite")
> [1] TRUE
>
> This all makes some sense, but I am not familiar enough with he 
> internals to explain exactly why it is done this way. I think you will 
> fine that 'is.nan' behave exactly the same way.
>
> Thanks,
> Lars
>
>
> Prof Brian Ripley wrote:
>
>> These functions are not generic according to the help page.
>> The same page says explicitly that is.nan is generic.
>>
>> Where did you get the (false) idea that they were generic?
>>
>> On Thu, 16 Jun 2005 [EMAIL PROTECTED] wrote:
>>
>>> Full_Name: Lars Hansen
>>> Version: 2.1.0
>>> OS: SunOS 5.8
>>> Submission from: (NULL) (207.66.36.189)
>>>
>>>
>>> Hi,
>>>
>>> S4 method displacth does not work for the two generic functions 
>>> 'is.finite' and 'is.infinite'. It turns out that the C functions 
>>> 'do_isfinite' and 'do_isinfinite' in src/main/coerce.c are missing a 
>>> call to 'DispatchOrEval' (see do_isnan). Added in the call fixed the 
>>> problem. My functions no look like this:
>>>
>>> Form coerce.c:
>>>
>>> SEXP do_isfinite(SEXP call, SEXP op, SEXP args, SEXP rho)
>>> {
>>>SEXP ans, x, names, dims;
>>>int i, n;
>>>
>>>if (DispatchOrEval(call, op, "is.finite", args, rho, &ans, 1, 1))
>>>return(ans);
>>>
>>>checkArity(op, args);
>>>...
>>>
>>> SEXP do_isinfinite(SEXP call, SEXP op, SEXP args, SEXP rho)
>>> {
>>>SEXP ans, x, names, dims;
>>>double xr, xi;
>>>int i, n;
>>>
>>>if (DispatchOrEval(call, op, "is.infinite", args, rho, &ans, 1, 1))
>>>return(ans);
>>>
>>>checkArity(op, args);
>>>...
>>
>>
>>
>

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

Re: [Rd] Computer algebra in R - would that be an idea??

[Søren Højsgaard]

Perhaps, this is the wrong mailing list, but I've been thinking about calling 
e.g. maxima from R through some kind of wrapper. On windows, maxima can be 
invoked through a file called maxima.bat which opens a simple 'dos terminal' in 
which maxima is running. A simple way of interfacing R and maxima would be 
through a function which 'copies' a text string into such a dos terminal with 
maxima running and copies the output back into R. That particular task is 
something which one might want to be able to do with several other programs 
too... A way of doing this would be through the system() and/or shell() 
functions where input and output can be redirected to/from the program called, 
e.g. maxima. The problem is, that system()/shell() will start maxima, execute 
the submitted code and terminate maxima. As I understand it, RDCOMClient 
provides a way of getting a 'handle' on such a program provided that the 
program is written in a specific way - something to do with COM. However, I 
wonder if it would be possible to write a general R function, (e.g. called 
dynamicshell()) which would provide a handle on such an application and to 
which one could send commands and retrieve output without shutting the 
application down. That is, essentially, a programatic form of 'copy and paste' 
in two directions... Is there anything in the way R is constructed that 
prevents that such a function could be written, and if so can anyone explain to 
me why and/or point me to a reference explaining why. 
 
Best regards
Søren



Fra: Simon Blomberg [mailto:[EMAIL PROTECTED]
Sendt: on 13-07-2005 04:42
Til: Gabor Grothendieck; Søren Højsgaard
Cc: Duncan Murdoch; r-devel@stat.math.ethz.ch
Emne: Re: [Rd] Computer algebra in R - would that be an idea??



Another approach might be to construct a wrapper for Aldor code, along the
lines of .Fortran and .C. Aldor is the extension language for AXIOM
http://www.aldor.org/, and there is a symbolic algebra library available
for Aldor http://www-sop.inria.fr/cafe/Manuel.Bronstein/algebra, which
ships with the Aldor compiler. Of course, I am much better at thinking up
these ideas than implementing them myself. :-)

Simon.


At 11:36 AM 13/07/2005, Gabor Grothendieck wrote:
>I don't know which free system is best.  I have mainly used Yacas
>but my needs to date have been pretty minimal so I suspect
>any of them would have worked.
>
>Eric's COM solution, once I have it figured out, will likely get me
>to the next step on Windows.  I did some googling around and
>found this:
>
>http://www.koders.com/python/fidDCC1B0FBFABC770277A28835D5FFADC9D25FF54E.aspx
>
>which is a python interface to Yacas which may give some ideas
>on how to interface it to R.
>
>
>On 7/12/05, Søren Højsgaard <[EMAIL PROTECTED]> wrote:
> > Personally, I like Maxima better than Yacas, but in both cases the
> solution (at least a minimal one) should be doable: A small program which
> pipes R commands into a terminal running Maxima/Yacas and taking the
> output back into R. I am not much into the technical details, but isn't
> that what can be done with the COM automatation server on Windows?? (I
> don't know what the equivalent would be on unix?).
> > Best regards
> > Søren
> >
> > 
> >
> > Fra: Simon Blomberg [mailto:[EMAIL PROTECTED]
> > Sendt: on 13-07-2005 01:52
> > Til: Duncan Murdoch; Gabor Grothendieck
> > Cc: Søren Højsgaard; r-devel@stat.math.ethz.ch
> > Emne: Re: [Rd] Computer algebra in R - would that be an idea??
> >
> >
> >
> > I would use such a symbolic math package for R. I have dreamt of an
> > open-source solution with functionality similar to mathStatica.
> > http://www.mathstatica.com/ Is yacas the best system to consider? What
> > about  Maxima http://maxima.sourceforge.net/, which is also GPL, or maybe
> > Axiom http://savannah.nongnu.org/projects/axiom, which has a modified BSD
> > license?
> >
> > Cheers,
> >
> > Simon.
> >
> > At 01:25 AM 13/07/2005, Duncan Murdoch wrote:
> > >On 7/12/2005 10:57 AM, Gabor Grothendieck wrote:
> > > > On 7/12/05, Søren Højsgaard <[EMAIL PROTECTED]> wrote:
> > > >> >From time to time people request symbolic computations beyond what
> > > D() and deriv() etc can provide. A brief look at the internet shows that
> > > there are many more or less developed computer algebra packages freely
> > > available. Therefore, I wondered if it would be an idea to try to
> > > 'integrate' one of these packages in R, which I guess can be done in more
> > > or less elegant ways... I do not know any of the computer algebra people
> > > around the World, but perhaps some other people from the R-community do
> > > and would be able to/interested in establishing such a connection...
> > > >
> > > >
> > > > Coincidentally I asked the yacas developer about this just yesterday:
> > > >
> > >
> http://sourceforge.net/mailarchive/forum.php?thread_id=7711431&forum_id=2216
> > >
> > >It sounds like developing an R package to act as

[Rd] Other mailing lists about R

[Fernando Henrique Ferraz P. da Rosa]

   I'd like to suggest an addition to the 'Mailing Lists' page on
the R-project site: [1]. There could be a section 'Non-official mailing
lists', with links to other mailing lists about R, not maitained by the
R-core group, potentially including mailing lists in other languages. 

As a suggestion of a mailling list which could be added to this
new section is 'R_STAT' [2], a brazilian list on R and statistics,
in portuguese. I think there must be other such localized lists,
probably in other languages, and there would be the natural place to
look for them. Alternatively, they could be added to the
Documentation section, under the Other -> Non-english material
subsection.

I did a search for other lists but couldn't find any. This
naturally doesn't mean there aren't any others, so if anyone on the list
knows of such a list please send a reply to this message.


References
[1] http://www.r-project.org/mail.html 
[2] http://br.groups.yahoo.com/group/R_STAT/

--
Fernando Henrique Ferraz P. da Rosa
http://www.ime.usp.br/~feferraz

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

Re: [Rd] Computer algebra in R - would that be an idea??

[Rob J Goedman]

A really simple way to play with R & yacas is by using the examples  
in the subdir
'embed' of yacas-1.0.57.

After building yacas (on Mac OS in my case):

 > res<-system("~/Projects/yacas-1.0.57/embed/example2", intern=T)
 > res
[1] "Cos(x);"

or

 > res<-system("~/Projects/yacas-1.0.57/embed/example1 'D(x){{Sin 
(x),Cos(x)}, {Sin(2*x),-Cos(x)}}'", intern=T)
 > res
[1] "Input> D(x){{Sin(x),Cos(x)}, {Sin(2*x),-Cos(x)}}"
[2] "Output> {{Cos(x),-Sin(x)},{2*Cos(2*x),Sin(x)}};"

or

 > system("yacas -pc --execute '[Echo(D(x)Sin(x));Exit();]'")
Cos(x)

or

 > system("echo 'Example()' | yacas_client")
In> Example()
Current example : Integrate(x,a,b)Sin(x);

Integrate a function.

Out> Cos(a)-Cos(b)
In>
 > system("echo 'Type(%)' | yacas_client")
In> Type(%)
Out> "-"
In>

This last example does show the yacas server stays alive between  
calls from R. yacas_client is a script.
Maybe that approach also works for maxima?

I wonder how difficult it would be to translate expressions back and  
forth from R to yacas in either R
or C++. And maybe strip 'In>' and 'Out>' like parts.

Rob

On Jul 14, 2005, at 5:21 PM, Søren Højsgaard wrote:

> Perhaps, this is the wrong mailing list, but I've been thinking  
> about calling e.g. maxima from R through some kind of wrapper. On  
> windows, maxima can be invoked through a file called maxima.bat  
> which opens a simple 'dos terminal' in which maxima is running. A  
> simple way of interfacing R and maxima would be through a function  
> which 'copies' a text string into such a dos terminal with maxima  
> running and copies the output back into R. That particular task is  
> something which one might want to be able to do with several other  
> programs too... A way of doing this would be through the system()  
> and/or shell() functions where input and output can be redirected  
> to/from the program called, e.g. maxima. The problem is, that system 
> ()/shell() will start maxima, execute the submitted code and  
> terminate maxima. As I understand it, RDCOMClient provides a way of  
> getting a 'handle' on such a program provided that the program is  
> written in a specific way - something to do with COM. However, I  
> wonder if it would be possible to write a general R function, (e.g.  
> called dynamicshell()) which would provide a handle on such an  
> application and to which one could send commands and retrieve  
> output without shutting the application down. That is, essentially,  
> a programatic form of 'copy and paste' in two directions... Is  
> there anything in the way R is constructed that prevents that such  
> a function could be written, and if so can anyone explain to me why  
> and/or point me to a reference explaining why.
>
> Best regards
> Søren
>
> 
>
> Fra: Simon Blomberg [mailto:[EMAIL PROTECTED]
> Sendt: on 13-07-2005 04:42
> Til: Gabor Grothendieck; Søren Højsgaard
> Cc: Duncan Murdoch; r-devel@stat.math.ethz.ch
> Emne: Re: [Rd] Computer algebra in R - would that be an idea??
>
>
>
> Another approach might be to construct a wrapper for Aldor code,  
> along the
> lines of .Fortran and .C. Aldor is the extension language for AXIOM
> http://www.aldor.org/, and there is a symbolic algebra library  
> available
> for Aldor http://www-sop.inria.fr/cafe/Manuel.Bronstein/algebra, which
> ships with the Aldor compiler. Of course, I am much better at  
> thinking up
> these ideas than implementing them myself. :-)
>
> Simon.
>
>
> At 11:36 AM 13/07/2005, Gabor Grothendieck wrote:
>
>> I don't know which free system is best.  I have mainly used Yacas
>> but my needs to date have been pretty minimal so I suspect
>> any of them would have worked.
>>
>> Eric's COM solution, once I have it figured out, will likely get me
>> to the next step on Windows.  I did some googling around and
>> found this:
>>
>> http://www.koders.com/python/ 
>> fidDCC1B0FBFABC770277A28835D5FFADC9D25FF54E.aspx
>>
>> which is a python interface to Yacas which may give some ideas
>> on how to interface it to R.
>>
>>
>> On 7/12/05, Søren Højsgaard <[EMAIL PROTECTED]> wrote:
>>
>>> Personally, I like Maxima better than Yacas, but in both cases the
>>>
>> solution (at least a minimal one) should be doable: A small  
>> program which
>> pipes R commands into a terminal running Maxima/Yacas and taking the
>> output back into R. I am not much into the technical details, but  
>> isn't
>> that what can be done with the COM automatation server on  
>> Windows?? (I
>> don't know what the equivalent would be on unix?).
>>
>>> Best regards
>>> Søren
>>>
>>> 
>>>
>>> Fra: Simon Blomberg [mailto:[EMAIL PROTECTED]
>>> Sendt: on 13-07-2005 01:52
>>> Til: Duncan Murdoch; Gabor Grothendieck
>>> Cc: Søren Højsgaard; r-devel@stat.math.ethz.ch
>>> Emne: Re: [Rd] Computer algebra in R - would that be an idea??
>>>
>>>
>>>
>>> I would use such a symbolic math package for R. I have dreamt of an
>>> open-source solution with functionality similar

[Rd] Adjusted p-values with TukeyHSD (patch)

[Fernando Henrique Ferraz P. da Rosa]

Dear R-developeRs,

Attached follows a patch against svn 34959 that adds the
printing of p-values to the TukeyHSD.aov function in stats package. I
also updated the corresponding documentation file and added a 'see also'
reference to the simint function of the multcomp package.

As it was already brought up in a previous thread [1] in R-help,
one can obtain the adjusted p-values using the multcomp package and its
simint function. The problem is that currently the simint function
scales very badly for a large number of contrasts (> 15). While the output
of TukeyHSD is almost instantaneous, simint may take more than half an
hour to process 19 contrasts.

As a toy example, try:

y <- rnorm(500)
A <- gl(5,100)
system.time(h1 <- TukeyHSD((aov(y ~ A
system.time(h2 <- simint(y ~ A,type="Tukey"))

Here I got:
[1] 0.09 0.01 0.10 0.00 0.00
[1] 26.87  0.03 27.10  0.00  0.00

For a small number of contrasts they're equivalent, for example:

data(warpbreaks)
fm1 <- aov(breaks ~ wool + tension, data = warpbreaks)
tHSD <- TukeyHSD(fm1, "tension", ordered = FALSE)
print(tHSD)
mcHSD <- simint(breaks ~ wool + tension, data = warpbreaks,
 whichf="tension", type="Tukey")
summary(mcHSD)

I also attached the complete function (mTukeyHSD.R) to this
message, in case the patch is not accepted and someone else needs to do
the same thing. In any case, I think the reference to the multcomp
package in the TukeyHSD help page should be considered even if the patch
to the function is not accepted. 

   Thank you, 

References
[1] http://tolstoy.newcastle.edu.au/R/help/05/05/4599.html

--
Fernando Henrique Ferraz P. da Rosa
http://www.ime.usp.br/~feferraz
diff -ru r-devel/R/ r-local/R
diff -ru r-devel/R/src/library/stats/R/TukeyHSD.R 
r-local/R/src/library/stats/R/TukeyHSD.R
--- r-devel/R/src/library/stats/R/TukeyHSD.R2005-07-14 23:13:49.0 
-0300
+++ r-local/R/src/library/stats/R/TukeyHSD.R2005-07-15 02:43:25.055207448 
-0300
@@ -66,10 +66,12 @@
 center <- center[keep]
 width <- qtukey(conf.level, length(means), x$df.residual) *
 sqrt((MSE/2) * outer(1/n, 1/n, "+"))[keep]
-dnames <- list(NULL, c("diff", "lwr", "upr"))
+est <- center/(sqrt((MSE/2) * outer(1/n, 1/n, "+"))[keep])
+pvals <- ptukey(abs(est),length(means),x$df.residual,lower.tail=FALSE)
+dnames <- list(NULL, c("diff", "lwr", "upr","p adj"))
 if (!is.null(nms)) dnames[[1]] <- outer(nms, nms, paste, sep = 
"-")[keep]
-out[[nm]] <- array(c(center, center - width, center + width),
-   c(length(width), 3), dnames)
+out[[nm]] <- array(c(center, center - width, center + width,pvals),
+   c(length(width), 4), dnames)
 }
 class(out) <- c("multicomp", "TukeyHSD")
 attr(out, "orig.call") <- x$call
diff -ru r-devel/R/src/library/stats/man/TukeyHSD.Rd 
r-local/R/src/library/stats/man/TukeyHSD.Rd
--- r-devel/R/src/library/stats/man/TukeyHSD.Rd 2005-07-14 23:14:39.380653872 
-0300
+++ r-local/R/src/library/stats/man/TukeyHSD.Rd 2005-07-15 03:14:36.520277744 
-0300
@@ -55,7 +55,8 @@
   A list with one component for each term requested in \code{which}.
   Each component is a matrix with columns \code{diff} giving the
   difference in the observed means, \code{lwr} giving the lower
-  end point of the interval, and \code{upr} giving the upper end point.
+  end point of the interval, \code{upr} giving the upper end point
+  and \code{p adj} giving the p-value. 
 }
 \references{
   Miller, R. G. (1981)
@@ -69,7 +70,8 @@
   Douglas Bates
 }
 \seealso{
-  \code{\link{aov}}, \code{\link{qtukey}}, \code{\link{model.tables}}
+  \code{\link{aov}}, \code{\link{qtukey}}, \code{\link{model.tables}},
+  \code{\link[multcomp]{simint}}
 }
 \examples{
 summary(fm1 <- aov(breaks ~ wool + tension, data = warpbreaks))
###
###   Tukey multiple comparisons for R
###
### Copyright 2000-2001  Douglas M. Bates <[EMAIL PROTECTED]>
### Modified for base R 2002 B. D. Ripley
###
### This file is made available under the terms of the GNU General
### Public License, version 2, or at your option, any later version,
### incorporated herein by reference.
###
### This program is distributed in the hope that it will be
### useful, but WITHOUT ANY WARRANTY; without even the implied
### warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
### PURPOSE.  See the GNU General Public License for more
### details.
###
### You should have received a copy of the GNU General Public
### License along with this program; if not, write to the Free
### Software Foundation, Inc., 59 Temple Place - Suite 330, Boston,
### MA 02111-1307, USA

TukeyHSD <-
function(x, which, ordered = FALSE, conf.level = 0.95, ...)
UseMethod("TukeyHSD")

TukeyHSD.aov <-
function(x, which = seq(along = tabs),