Re: [Rd] Extending deriv3()
On Mon, 15 Oct 2007, Thomas Yee wrote: > Hello, > > I was wondering if the functions deriv3(), deriv() etc. could be extended > to handle psigamma() and its special cases (digamma(), trigamma() > etc.). From the error message it seems that 'psigamma' needs to be > added to the derivatives table. > This might be easy since psigamma() has a deriv argument. If you look at ?deriv you will see that it only knows about functions *of one argument* and operators. So it would be easy to add digamma(x) and psigamma(x) (and I will do so shortly), it would not be so easy to add psigamma(x, deriv). > Additionally, this error message is also obtained when requesting for > the Hessian of the gamma and lgamma functions: > > d3 = deriv(~ gamma(y), namev="y", hessian= TRUE) > d3 = deriv(~ lgamma(y), namev="y", hessian= TRUE) > > Another class of special functions worth adding are the Bessel functions. Well, you can always submit a patch Note that deriv() in R differs from that in S in being done in C and hence not being user-extensible. A long time ago that had an advantage: S's deriv could be very slow and take a lot of memory by the standards of the early 1990's. Rather than work on adding yet more special cases it would seem better to work on making it user-extensible. -- 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
[Rd] all zeroes in Mersenne Twister state may remain undetected
The function runif(n) contains a protection against a corrupted .Random.seed.
Besides other things, it tests whether at least one of the numbers
.Random.seed[3:626] is not zero. If all(.Random.seed[3:626]==0), then
the internal Mersenne Twister state is regenerated using current time,
since a zero state is a fixed point of the recurrence and, hence, produces
a constant sequence.
However, the condition any(.Random.seed[3:626]!=0) does not imply that
the internal Mersenne Twister state is indeed not zero, since only the
most significant bit of .Random.seed[3] belongs to the internal state.
Hence, the number of bits in the state of Mersenne Twister
is 624*32 - 31 = 19937, which explains the period 2^19937-1.
For example, if .Random.seed[3] == 1, we always have the condition
any(.Random.seed[3:626]!=0)
satisfied, but the internal state may still be effectively zero. An
example of such a situation is
RNGkind("default")
.Random.seed[3:626] <- as.integer(0)
.Random.seed[3] <- as.integer(1)
x <- runif(1)
all(x==x[1]) # TRUE
length(unique(x)) # 1
all(.Random.seed[3:626]==0) # TRUE
Here, the internal state was effectively zero, but this fact was not
detected, since some (unimportant) bits of .Random.seed[3] were not zero.
On the contrary, if also .Random.seed[3]==0, then the internal state
is regenerated and the output of runif() becomes non constant:
RNGkind("default")
.Random.seed[3:626] <- as.integer(0)
x <- runif(1)
all(x==x[1]) # FALSE
length(unique(x)) # 1
all(.Random.seed[3:626]==0) # FALSE
The following patch to FixupSeeds corrects the detection of zero state:
--- R-devel_2007-10-14-orig/src/main/RNG.c 2007-09-02 07:49:35.0
+0200
+++ R-devel_2007-10-14-FixupSeeds/src/main/RNG.c2007-10-15
04:33:52.988060624 +0200
@@ -181,7 +181,9 @@
/* No action unless user has corrupted .Random.seed */
if(I1 <= 0) I1 = 624;
/* check for all zeroes */
- for (j = 1; j <= 624; j++)
+ notallzero = ((RNG_Table[RNG_kind].i_seed[1] & 0x8000) != 0);
+ if(!notallzero)
+ for (j = 2; j <= 624; j++)
if(RNG_Table[RNG_kind].i_seed[j] != 0) {
notallzero = 1;
break;
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in Windows Vista, saving workspace...
I just did a standard installation of R in my computer. What I was trying here is to call attention that Windows Vista doesn't allow normal users to write on the R default installation directory. Instead, the information about configuration files ( and in this case .RDataTmp ) shouldn't they be stored in Username/AppData/Local ? Filipe Santos On Friday 12 October 2007 19:03:18 you wrote: > Do you have write permissions in the current working directory? I guess > not. > > Uwe Ligges > > Filipe Santos wrote: > > Dear all... > > > > I'm using R 2.6.0 in windows Vista. And I got the following error: > >> quit() > > > > Save workspace image? [y/n/c]: y > > Error in gzfile(file,"wb"): unable to open connection > > In addiction: Warning message: > > In gzfile(file, "wb") : cannot open compressed file '.RDataTmp' > > > > This happens in both in RGui and Rterm > > > > Thanks, > > Filipe Santos > > > > __ > > 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] boxplot() confuses x- and y-axes (PR#10345)
Full_Name: Bob O'Hara Version: 2.6.0 OS: Windows XP Submission from: (NULL) (88.112.20.250) Using horizontal=TRUE with boxplot() confuses it as to what is an x- or y-axis. At least, xlim= and ylim= are the wrong way round, log="x" (or "y") and xaxt= work as expected, I haven't looked at anything else. Some code to see if you can reproduce the bug (or discover it's in my head...): boxplot(count ~ spray, data = InsectSprays) # Try to change x-axis: boxplot(count ~ spray, data = InsectSprays, xlim=c(0,50)) # Plot horizontally: boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE) # Now try to change x-axis: boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, xlim=c(0,50)) # Changes y-axis! # Now try to change y-axis: boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, ylim=c(0,50)) # Changes x-axis! # Plot x-axis on log scale: boxplot(count+1 ~ spray, data = InsectSprays, horizontal=TRUE, log="x") # Does indeed change x-axis # Don't add ticks on x-axis: boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, xaxt="n") # Works as expected. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extending deriv3()
If you are modifying it it would also be nice to add
{ to the derivative table so one can write this:
f <- function(x) x*x
deriv(body(f), "x", func = TRUE)
Currently, one must do:
deriv(body(f)[[2]], "x", func = TRUE)
On 10/15/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> On Mon, 15 Oct 2007, Thomas Yee wrote:
>
> > Hello,
> >
> > I was wondering if the functions deriv3(), deriv() etc. could be extended
> > to handle psigamma() and its special cases (digamma(), trigamma()
> > etc.). From the error message it seems that 'psigamma' needs to be
> > added to the derivatives table.
> > This might be easy since psigamma() has a deriv argument.
>
> If you look at ?deriv you will see that it only knows about functions *of
> one argument* and operators. So it would be easy to add digamma(x) and
> psigamma(x) (and I will do so shortly), it would not be so easy to add
> psigamma(x, deriv).
>
> > Additionally, this error message is also obtained when requesting for
> > the Hessian of the gamma and lgamma functions:
> >
> > d3 = deriv(~ gamma(y), namev="y", hessian= TRUE)
> > d3 = deriv(~ lgamma(y), namev="y", hessian= TRUE)
> >
> > Another class of special functions worth adding are the Bessel functions.
>
> Well, you can always submit a patch
>
> Note that deriv() in R differs from that in S in being done in C and hence
> not being user-extensible. A long time ago that had an advantage: S's
> deriv could be very slow and take a lot of memory by the standards of the
> early 1990's. Rather than work on adding yet more special cases it would
> seem better to work on making it user-extensible.
>
> --
> 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
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot() confuses x- and y-axes (PR#10345)
On Mon, 2007-10-15 at 10:30 +0200, [EMAIL PROTECTED] wrote: > Full_Name: Bob O'Hara > Version: 2.6.0 > OS: Windows XP > Submission from: (NULL) (88.112.20.250) > > > Using horizontal=TRUE with boxplot() confuses it as to what is an x- or > y-axis. > At least, xlim= and ylim= are the wrong way round, log="x" (or "y") and xaxt= > work as expected, I haven't looked at anything else. > > Some code to see if you can reproduce the bug (or discover it's in my > head...): > > boxplot(count ~ spray, data = InsectSprays) > > # Try to change x-axis: > boxplot(count ~ spray, data = InsectSprays, xlim=c(0,50)) > > # Plot horizontally: > boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE) > > # Now try to change x-axis: > boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, xlim=c(0,50)) > # Changes y-axis! > > # Now try to change y-axis: > boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, ylim=c(0,50)) > # Changes x-axis! > > # Plot x-axis on log scale: > boxplot(count+1 ~ spray, data = InsectSprays, horizontal=TRUE, log="x") > # Does indeed change x-axis > > # Don't add ticks on x-axis: > boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, xaxt="n") > # Works as expected. Hi Bob, No, it's not in your head. This is documented in ?bxp, which is the function that actually does the plotting for boxplot(). See the description of 'pars' in ?bxp: "Currently, yaxs and ylim are used âalong the boxplotâ, i.e., vertically, when horizontal is false, and xlim horizontally." So essentially, the named 'x' and 'y' axes are rotated 90 degrees when you use 'horizontal = TRUE', rather than the vertical axis always being 'y' and the horizontal axis always being 'x'. This has been discussed on the lists previously. Regards, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in Windows Vista, saving workspace...
On Mon, 15 Oct 2007, Filipe Santos wrote: > I just did a standard installation of R in my computer. > > What I was trying here is to call attention that Windows Vista doesn't allow > normal users to write on the R default installation directory. Instead, the > information about configuration files ( and in this case .RDataTmp ) > shouldn't they be stored in Username/AppData/Local ? It does if the user installs R. Note the advice in the rw-FAQ to set up a shortcut with an appropriate working directory, which it seems you did not do. There is nothing new about Vista here: all NT-based versions of Windows did the same thing. > > Filipe Santos > > On Friday 12 October 2007 19:03:18 you wrote: >> Do you have write permissions in the current working directory? I guess >> not. >> >> Uwe Ligges >> >> Filipe Santos wrote: >>> Dear all... >>> >>> I'm using R 2.6.0 in windows Vista. And I got the following error: quit() >>> >>> Save workspace image? [y/n/c]: y >>> Error in gzfile(file,"wb"): unable to open connection >>> In addiction: Warning message: >>> In gzfile(file, "wb") : cannot open compressed file '.RDataTmp' >>> >>> This happens in both in RGui and Rterm >>> >>> Thanks, >>> Filipe Santos >>> >>> __ >>> 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 > -- 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
[Rd] Constants
Dear R developers I wrote a package whose computational 'engine' is programmed in Fortran 77. However, I used also C code, mainly for exploiting the Mathlib Standalone set of functions. I successfully compiled and used my package for months, under R-2.4.1 (and MINGW - GCC 3.4.2). Now, I switched to R-2.6.0 (and the 'Rtool.exe' set of Murdoch, installed EXACTLY as in its prescriptions) and I encountered problems during compilation. In a C function I use the DOUBLE_EPS constant (of course, I loaded the header). but the the 'R CMD check' say that " CFunctions1.c:333: error: `DBL_EPSILON' undeclared (first use in this function) ... " I suspect that the difference between my two compilation experiences lies in the different structure of the header between GCC 3.4.2 and GCC 3.4.5. I'm not a C expertise and hence the question: There is a clean way for using this kind of constants (DOUBLE_EPS and other similar) as my previous experience? Thanks a lot in advance Fabrizio P.S. I have a Pentium Centrino and Windows XP. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] package Geneland / Rgui under windows
Hi, I experienced a problem with the package Geneland under R 2.6.0 with windows XP professional. The commands below should simulate a dataset, then make an MCMC simulation stored in tempdir(). It works with R 2.5.1 (both GUI and command line) It works with the command line of R 2.6.0 but not with the R GUI of 2.6.0: no output file is created in tempdir() and R remains frozen. I reported it as a bug (PR#9964) but did not get any feed back. Thanks in advance for any help. Gilles set.seed(1) data <- simdata(nindiv=200, coord.lim=c(0,1,0,1) , number.nuclei=5 , allele.numbers=rep(10,20), IBD=FALSE, npop=2, give.tess.grid=FALSE) path.mcmc <- paste(tempdir(),"/",sep="") mcmcFmodel(coordinates= t(data$coord.indiv), genotypes=data$genotypes, path.mcmc=path.mcmc, rate.max=10, delta.coord=0, npopmin=1, npopinit=5, npopmax=5, nb.nuclei.max=50, nit=500, thinning=1, freq.model="Dirichlet", varnpop=FALSE, spatial=TRUE) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot() confuses x- and y-axes (PR#10345)
On Mon, 2007-10-15 at 15:25 +0200, [EMAIL PROTECTED] wrote: > > "ms" == marc schwartz <[EMAIL PROTECTED]> > > on Mon, 15 Oct 2007 14:20:16 +0200 (CEST) writes: > > ms> On Mon, 2007-10-15 at 10:30 +0200, [EMAIL PROTECTED] wrote: > >> Full_Name: Bob O'Hara > >> Version: 2.6.0 > >> OS: Windows XP > >> Submission from: (NULL) (88.112.20.250) > >> > >> > >> Using horizontal=TRUE with boxplot() confuses it as to what is an x- > or y-axis. > >> At least, xlim= and ylim= are the wrong way round, log="x" (or "y") > and xaxt= > >> work as expected, I haven't looked at anything else. > >> > >> Some code to see if you can reproduce the bug (or discover it's in my > head...): > >> > >> boxplot(count ~ spray, data = InsectSprays) > >> > >> # Try to change x-axis: > >> boxplot(count ~ spray, data = InsectSprays, xlim=c(0,50)) > >> > >> # Plot horizontally: > >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE) > >> > >> # Now try to change x-axis: > >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, > xlim=c(0,50)) > >> # Changes y-axis! > >> > >> # Now try to change y-axis: > >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, > ylim=c(0,50)) > >> # Changes x-axis! > >> > >> # Plot x-axis on log scale: > >> boxplot(count+1 ~ spray, data = InsectSprays, horizontal=TRUE, log="x") > >> # Does indeed change x-axis > >> > >> # Don't add ticks on x-axis: > >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, xaxt="n") > >> # Works as expected. > > ms> Hi Bob, > > ms> No, it's not in your head. This is documented in ?bxp, which is the > ms> function that actually does the plotting for boxplot(). See the > ms> description of 'pars' in ?bxp: > > ms> "Currently, yaxs and ylim are used ‘along the boxplot’, i.e., > ms> vertically, when horizontal is false, and xlim horizontally." > > ms> So essentially, the named 'x' and 'y' axes are rotated 90 degrees when > ms> you use 'horizontal = TRUE', rather than the vertical axis always > being > ms> 'y' and the horizontal axis always being 'x'. This has been discussed > on > ms> the lists previously. > > Yes; thank you, Marc. > > And the reason for this is very sensible I think: > > If you have a longish boxplot() or bxp() command, > and you just want to go from vertical to horizontal or vice > versa, it makes most sense just to have to change the > 'horizontal' flag and not having to see if there are other 'x*' > and or 'y*' arguments that all need to be changed as well. > Except that you must change xaxt/yaxt and log="x"/log="y" which do not follow the "along the box" logic, and behave differently than xlim/ylim. Nothing of this is fatal, but this probably needs more than one iteration to find which way each of the x* and y* arguments works. cheers, jari oksanen __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot() confuses x- and y-axes (PR#10345)
> "ms" == marc schwartz <[EMAIL PROTECTED]> > on Mon, 15 Oct 2007 14:20:16 +0200 (CEST) writes: ms> On Mon, 2007-10-15 at 10:30 +0200, [EMAIL PROTECTED] wrote: >> Full_Name: Bob O'Hara >> Version: 2.6.0 >> OS: Windows XP >> Submission from: (NULL) (88.112.20.250) >> >> >> Using horizontal=TRUE with boxplot() confuses it as to what is an x- or y-axis. >> At least, xlim= and ylim= are the wrong way round, log="x" (or "y") and xaxt= >> work as expected, I haven't looked at anything else. >> >> Some code to see if you can reproduce the bug (or discover it's in my head...): >> >> boxplot(count ~ spray, data = InsectSprays) >> >> # Try to change x-axis: >> boxplot(count ~ spray, data = InsectSprays, xlim=c(0,50)) >> >> # Plot horizontally: >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE) >> >> # Now try to change x-axis: >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, xlim=c(0,50)) >> # Changes y-axis! >> >> # Now try to change y-axis: >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, ylim=c(0,50)) >> # Changes x-axis! >> >> # Plot x-axis on log scale: >> boxplot(count+1 ~ spray, data = InsectSprays, horizontal=TRUE, log="x") >> # Does indeed change x-axis >> >> # Don't add ticks on x-axis: >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, xaxt="n") >> # Works as expected. ms> Hi Bob, ms> No, it's not in your head. This is documented in ?bxp, which is the ms> function that actually does the plotting for boxplot(). See the ms> description of 'pars' in ?bxp: ms> "Currently, yaxs and ylim are used âalong the boxplotâ, i.e., ms> vertically, when horizontal is false, and xlim horizontally." ms> So essentially, the named 'x' and 'y' axes are rotated 90 degrees when ms> you use 'horizontal = TRUE', rather than the vertical axis always being ms> 'y' and the horizontal axis always being 'x'. This has been discussed on ms> the lists previously. Yes; thank you, Marc. And the reason for this is very sensible I think: If you have a longish boxplot() or bxp() command, and you just want to go from vertical to horizontal or vice versa, it makes most sense just to have to change the 'horizontal' flag and not having to see if there are other 'x*' and or 'y*' arguments that all need to be changed as well. Regards, Martin Maechler __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package Geneland / Rgui under windows
Gilles GUILLOT wrote: > Hi, > I experienced a problem with the package Geneland under R 2.6.0 > with windows XP professional. > > The commands below should simulate a dataset, > then make an MCMC simulation stored in tempdir(). > > It works with R 2.5.1 (both GUI and command line) > It works with the command line of R 2.6.0 > but not with the R GUI of 2.6.0: no output file is created in tempdir() > and R remains frozen. > I reported it as a bug > (PR#9964) but did not get any feed back. I think the general rule-of-thumb is to contact the package author for problems with individual packages. Many package authors read this list, but there are probably some that do not. Sometimes problems with individual packages are actually bugs in R, but I would say that this is not usually the case. However, the package author is probably the best person to make this judgment. Sean __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package Geneland / Rgui under windows
I forgot to say that I was the package author. I suspected a bug of R as Geneland worked fine for two years and the problem popped up with the release of R 2.6.0 And I can't see any explanation. So, any clue would help. gilles > Gilles GUILLOT wrote: >> Hi, >> I experienced a problem with the package Geneland under R 2.6.0 >> with windows XP professional. >> >> The commands below should simulate a dataset, >> then make an MCMC simulation stored in tempdir(). >> >> It works with R 2.5.1 (both GUI and command line) >> It works with the command line of R 2.6.0 >> but not with the R GUI of 2.6.0: no output file is created in tempdir() >> and R remains frozen. >> I reported it as a bug >> (PR#9964) but did not get any feed back. > > I think the general rule-of-thumb is to contact the package author for > problems with individual packages. Many package authors read this list, > but there are probably some that do not. Sometimes problems with > individual packages are actually bugs in R, but I would say that this is > not usually the case. However, the package author is probably the best > person to make this judgment. > > Sean > _ Gilles GUILLOT INRA MIA Paris - FRANCE Now working from Matematisk Statistik Chalmers University of Technology, S-412 96 Göteborg, SWEDEN Rum: 3079 tel: +46 31 772 5338, Email: [EMAIL PROTECTED] http://www.inapg.inra.fr/ens_rech/mathinfo/personnel/guillot/welcome.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extending deriv3()
BTW, this has come up several times before, e.g. http://tolstoy.newcastle.edu.au/R/e2/help/07/08/22447.html is a call for patches. On Mon, 15 Oct 2007, Prof Brian Ripley wrote: > On Mon, 15 Oct 2007, Thomas Yee wrote: > >> Hello, >> >> I was wondering if the functions deriv3(), deriv() etc. could be extended >> to handle psigamma() and its special cases (digamma(), trigamma() >> etc.). From the error message it seems that 'psigamma' needs to be >> added to the derivatives table. >> This might be easy since psigamma() has a deriv argument. > > If you look at ?deriv you will see that it only knows about functions *of > one argument* and operators. So it would be easy to add digamma(x) and > psigamma(x) (and I will do so shortly), it would not be so easy to add > psigamma(x, deriv). I've now implemented that in R-devel, including the 'not so easy' case. >> Additionally, this error message is also obtained when requesting for >> the Hessian of the gamma and lgamma functions: >> >> d3 = deriv(~ gamma(y), namev="y", hessian= TRUE) >> d3 = deriv(~ lgamma(y), namev="y", hessian= TRUE) >> >> Another class of special functions worth adding are the Bessel functions. > > Well, you can always submit a patch > > Note that deriv() in R differs from that in S in being done in C and hence > not being user-extensible. A long time ago that had an advantage: S's > deriv could be very slow and take a lot of memory by the standards of the > early 1990's. Rather than work on adding yet more special cases it would > seem better to work on making it user-extensible. > > -- 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] boxplot() confuses x- and y-axes (PR#10345)
> "JO" == Jari Oksanen <[EMAIL PROTECTED]>
> on Mon, 15 Oct 2007 16:42:24 +0300 writes:
JO> On Mon, 2007-10-15 at 15:25 +0200, [EMAIL PROTECTED] wrote:
>> > "ms" == marc schwartz <[EMAIL PROTECTED]>
>> > on Mon, 15 Oct 2007 14:20:16 +0200 (CEST) writes:
>>
ms> On Mon, 2007-10-15 at 10:30 +0200, [EMAIL PROTECTED] wrote:
>> >> Full_Name: Bob O'Hara
>> >> Version: 2.6.0
>> >> OS: Windows XP
>> >> Submission from: (NULL) (88.112.20.250)
>> >>
>> >>
>> >> Using horizontal=TRUE with boxplot() confuses it as to what is an x-
or y-axis.
>> >> At least, xlim= and ylim= are the wrong way round, log="x" (or "y")
and xaxt=
>> >> work as expected, I haven't looked at anything else.
>> >>
>> >> Some code to see if you can reproduce the bug (or discover it's in my
head...):
>> >>
>> >> boxplot(count ~ spray, data = InsectSprays)
>> >>
>> >> # Try to change x-axis:
>> >> boxplot(count ~ spray, data = InsectSprays, xlim=c(0,50))
>> >>
>> >> # Plot horizontally:
>> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE)
>> >>
>> >> # Now try to change x-axis:
>> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE,
xlim=c(0,50))
>> >> # Changes y-axis!
>> >>
>> >> # Now try to change y-axis:
>> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE,
ylim=c(0,50))
>> >> # Changes x-axis!
>> >>
>> >> # Plot x-axis on log scale:
>> >> boxplot(count+1 ~ spray, data = InsectSprays, horizontal=TRUE,
log="x")
>> >> # Does indeed change x-axis
>> >>
>> >> # Don't add ticks on x-axis:
>> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, xaxt="n")
>> >> # Works as expected.
>>
ms> Hi Bob,
>>
ms> No, it's not in your head. This is documented in ?bxp, which is the
ms> function that actually does the plotting for boxplot(). See the
ms> description of 'pars' in ?bxp:
>>
ms> "Currently, yaxs and ylim are used ââ¬ËÂalong the boxplotââ¬â¢,
i.e.,
ms> vertically, when horizontal is false, and xlim horizontally."
>>
ms> So essentially, the named 'x' and 'y' axes are rotated 90 degrees when
ms> you use 'horizontal = TRUE', rather than the vertical axis always being
ms> 'y' and the horizontal axis always being 'x'. This has been discussed on
ms> the lists previously.
>>
>> Yes; thank you, Marc.
>>
>> And the reason for this is very sensible I think:
>>
>> If you have a longish boxplot() or bxp() command,
>> and you just want to go from vertical to horizontal or vice
>> versa, it makes most sense just to have to change the
>> 'horizontal' flag and not having to see if there are other 'x*'
>> and or 'y*' arguments that all need to be changed as well.
>>
JO> Except that you must change xaxt/yaxt and log="x"/log="y" which do not
JO> follow the "along the box" logic, and behave differently than
JO> xlim/ylim.
JO> Nothing of this is fatal, but this probably needs more than one
JO> iteration to find which way each of the x* and y* arguments works.
Oops!!Thank you Jari, for the note.
What you describe is then very unfortunate, and I hadn't been
aware of that.
``of course'', making any change to consistency
would break existing code that consciously works with the
current mis-"designed" behavior.
But now I understand why we have the word "currently"
in the description mentioned above.
So given the help file, we should consider dropping the whole
``along the boxplot'' idea?
{{well, yes, we should drop "traditional graphics" and work with
grid-based graphical objects ("grob"s) that can be drawn
vertically or horizontally,
e.g., in lattice or (most probably) ggplot2
}}
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package Geneland / Rgui under windows
I don't have 'genuine' windows, but I have been running win32 R under wine from time to time for a couple of years (among other reasons, for testing cross-compilation of our R package - snpMatrix in http://www-gene.cimr.cam.ac.uk/clayton/software/), and your package (fields_3.5.zip Geneland_2.0.8.zip RandomFields_1.3.30.zip) works fine with win32 R 2.6.0 Rgui under wine. However, I notice an anomaly - You are using printf() instead of Rprintf() - and these messages: * ***MCMC inference *** * 0.200 % ... 99.800 % 100.000 % ***End of MCMC inference *** get sent to the parent terminal controlling wine, rather than going into Rgui's console. (we made a similiar mistake in an early version of snpMatrix). Consider replacing printf() with Rprintf() . This is an FAQ in the R-windows FAQ web page. That might be why Rgui hangs in XP but Rterm works. Gilles GUILLOT wrote: > I forgot to say that I was the package author. > I suspected a bug of R as Geneland worked fine for two > years and the problem popped up > with the release of R 2.6.0 > And I can't see any explanation. > So, any clue would help. > > gilles > > >> Gilles GUILLOT wrote: >>> Hi, >>> I experienced a problem with the package Geneland under R 2.6.0 >>> with windows XP professional. >>> >>> The commands below should simulate a dataset, >>> then make an MCMC simulation stored in tempdir(). >>> >>> It works with R 2.5.1 (both GUI and command line) >>> It works with the command line of R 2.6.0 >>> but not with the R GUI of 2.6.0: no output file is created in tempdir() >>> and R remains frozen. >>> I reported it as a bug >>> (PR#9964) but did not get any feed back. >> I think the general rule-of-thumb is to contact the package author for >> problems with individual packages. Many package authors read this list, >> but there are probably some that do not. Sometimes problems with >> individual packages are actually bugs in R, but I would say that this is >> not usually the case. However, the package author is probably the best >> person to make this judgment. >> >> Sean >> > > > _ > Gilles GUILLOT > INRA MIA Paris - FRANCE > > Now working from Matematisk Statistik > Chalmers University of Technology, > S-412 96 Göteborg, SWEDEN > Rum: 3079 > tel: +46 31 772 5338, > Email: [EMAIL PROTECTED] > http://www.inapg.inra.fr/ens_rech/mathinfo/personnel/guillot/welcome.html > > __ > 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] namespace, S4 and import
Hi
I have been using a bit of namespaces in the past, but the following
alludes me.
I am dealing with the Bioconductor packages Biobase and affy. Biobase
has a namespace and affy does not. affy contains the S4 class
"AffyBatch" which extends the "eSet" class in Biobase.
I am extending the AffyBatch class myself. My code works fine as long
as I do not have any NAMESPACE file.
Now I am trying to add one. I am importing Biobase, but I cannot
import affy since it does not have a NAMESPACE. However, when I try R
CMD INSTALL it complains that it cannot find AffyBatch :
Error in setIs(Class, class2, classDef = classDef, where = where) :
Unable to find package environment for class "AffyBatch" to revise
subclass information
So how do I make the classes in affy available for my package when
affy does not have a NAMESPACE?
The relevant lines from my DESCRIPTION file is
Depends: R (>= 2.6), affy (>= 1.16), affxparser (>= 1.10),
Biobase, methods
LazyLoad: yes
and from my NAMESPACE file I have
exportPattern("^[^\\.]")
import(Biobase)
I have also tried (in desperation) to add a "require(affy)" in
both .onLoad and .onAttach, but to no help.
While I am at this: as I remember it, in the old days we needed
"require(methods)" in .onLoad to work with S4, is that still necessary?
I am using R-2.6.0 on OS X (PPC)
Thanks, Kasper
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot() confuses x- and y-axes (PR#10345)
--=-ZyOtZFb05MaZLi4/Ovwu
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On Mon, 2007-10-15 at 18:25 +0200, [EMAIL PROTECTED] wrote:
> > "JO" == Jari Oksanen <[EMAIL PROTECTED]>
> > on Mon, 15 Oct 2007 16:42:24 +0300 writes:
>
> JO> On Mon, 2007-10-15 at 15:25 +0200, [EMAIL PROTECTED] wrote:
> >> > "ms" == marc schwartz <[EMAIL PROTECTED]>
> >> > on Mon, 15 Oct 2007 14:20:16 +0200 (CEST) writes:
> >>
> ms> On Mon, 2007-10-15 at 10:30 +0200, [EMAIL PROTECTED] wrote:
> >> >> Full_Name: Bob O'Hara
> >> >> Version: 2.6.0
> >> >> OS: Windows XP
> >> >> Submission from: (NULL) (88.112.20.250)
> >> >>
> >> >>
> >> >> Using horizontal=TRUE with boxplot() confuses it as to what is an
> x- or y-axis.
> >> >> At least, xlim= and ylim= are the wrong way round, log="x" (or "y")
> and xaxt=
> >> >> work as expected, I haven't looked at anything else.
> >> >>
> >> >> Some code to see if you can reproduce the bug (or discover it's in
> my head...):
> >> >>
> >> >> boxplot(count ~ spray, data = InsectSprays)
> >> >>
> >> >> # Try to change x-axis:
> >> >> boxplot(count ~ spray, data = InsectSprays, xlim=c(0,50))
> >> >>
> >> >> # Plot horizontally:
> >> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE)
> >> >>
> >> >> # Now try to change x-axis:
> >> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE,
> xlim=c(0,50))
> >> >> # Changes y-axis!
> >> >>
> >> >> # Now try to change y-axis:
> >> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE,
> ylim=c(0,50))
> >> >> # Changes x-axis!
> >> >>
> >> >> # Plot x-axis on log scale:
> >> >> boxplot(count+1 ~ spray, data = InsectSprays, horizontal=TRUE,
> log="x")
> >> >> # Does indeed change x-axis
> >> >>
> >> >> # Don't add ticks on x-axis:
> >> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE,
> xaxt="n")
> >> >> # Works as expected.
> >>
> ms> Hi Bob,
> >>
> ms> No, it's not in your head. This is documented in ?bxp, which is the
> ms> function that actually does the plotting for boxplot(). See the
> ms> description of 'pars' in ?bxp:
> >>
> ms> "Currently, yaxs and ylim are used âââ¬ÃÃÅalong the
> boxplotâââ‰â¢, i.e.,
> ms> vertically, when horizontal is false, and xlim horizontally."
> >>
> ms> So essentially, the named 'x' and 'y' axes are rotated 90 degrees when
> ms> you use 'horizontal = TRUE', rather than the vertical axis always
> being
> ms> 'y' and the horizontal axis always being 'x'. This has been discussed
> on
> ms> the lists previously.
> >>
> >> Yes; thank you, Marc.
> >>
> >> And the reason for this is very sensible I think:
> >>
> >> If you have a longish boxplot() or bxp() command,
> >> and you just want to go from vertical to horizontal or vice
> >> versa, it makes most sense just to have to change the
> >> 'horizontal' flag and not having to see if there are other 'x*'
> >> and or 'y*' arguments that all need to be changed as well.
> >>
> JO> Except that you must change xaxt/yaxt and log="x"/log="y" which do not
> JO> follow the "along the box" logic, and behave differently than
> JO> xlim/ylim.
>
> JO> Nothing of this is fatal, but this probably needs more than one
> JO> iteration to find which way each of the x* and y* arguments works.
>
> Oops!!Thank you Jari, for the note.
>
> What you describe is then very unfortunate, and I hadn't been
> aware of that.
>
> ``of course'', making any change to consistency
> would break existing code that consciously works with the
> current mis-"designed" behavior.
>
> But now I understand why we have the word "currently"
> in the description mentioned above.
>
> So given the help file, we should consider dropping the whole
> ``along the boxplot'' idea?
>
> {{well, yes, we should drop "traditional graphics" and work with
> grid-based graphical objects ("grob"s) that can be drawn
> vertically or horizontally,
> e.g., in lattice or (most probably) ggplot2
> }}
>
> Martin
The key code in question, from boxplot.R, seems to be:
if (!add) {
plot.new()
## shall we switch log for horizontal with
## switch(log, x="y", y="x", log) ??
if (horizontal)
plot.window(ylim = xlim, xlim = ylim, log = log, xaxs = pars$yaxs)
else
plot.window(xlim = xlim, ylim = ylim, log = log, yaxs = pars$yaxs)
}
xlog <- (par("ylog") && horizontal) || (par("xlog") && !horizontal)
So it would appear that ylim/xlim and xaxs/yaxs are interchanged when
horizontal = TRUE. All? other axis specific pars remain as per normal.
I have attached a proposed patch against bxp.Rd (against the current svn
copy) for consideration. Hopefully
Re: [Rd] boxplot() confuses x- and y-axes (PR#10345)
> So given the help file, we should consider dropping the whole
> ``along the boxplot'' idea?
>
> {{well, yes, we should drop "traditional graphics" and work with
> grid-based graphical objects ("grob"s) that can be drawn
> vertically or horizontally,
> e.g., in lattice or (most probably) ggplot2
> }}
ggplot2 does this in a completely general way (i.e. for all types of
graphics) with the coord_flip coordinate system, which flips the
interpretation of the x and y scales. This includes producing
smoothers of x conditional on y, and so forth.
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Digest package - make digest generic?
On 10/15/07, Henrik Bengtsson <[EMAIL PROTECTED]> wrote:
> [As agreed, CC:ing r-devel since others might be interested in this as well.]
>
> Hi.
>
> On 10/15/07, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote:
> >
> > Hi Hadley,
> >
> > On 15 October 2007 at 09:51, hadley wickham wrote:
> > | Would you consider making digest a generic function? That way I could
> > | (e.g.) make a generic method for ggplot objects which didn't depend
> > | (so much) on their internal representation.
> >
> > Well, generally speaking, I always take patches :)
>
> I see know problems in doing this. The patch would be:
>
> digest <- function(...) UseMethod("digest");
> digest.default <- .
>
> I think that should do, and I don't think it has any surprising side
> effects so it could be added in the next release. Dirk, can you do
> that?
>
> >
> > I have to admit that I am fairly weak on these aspects of the S language.
> > One question is: how to the current users of digest (i.e. Henrik's and
> > Seth's caching mechanism, for example) use it on arbitrary objects _without_
> > it being generic?
>
> I basically put everything I want into a list() and pass that to
> digest::digest().
Yes, that's what I'm doing too.
> >
> > | The reason I ask is that I'm using digest as a way of coming up with a
> > | unique file name for each example graphic. I want to be able to
> > | easily compare the appearance of examples between versions, but
> > | currently the digest depends on internal details, so it's hard to
> > | match up graphics between versions.
>
> See loadCache(key) and saveCache(object, key) in R.cache, which
> basically loads and saves results from and to a file cache based on a
> key object - no need to specify paths or filenames. You can specify
> paths etc if you want to, but by default it is just transparent.
The problem is I need to refer to the image from the documentation, so
I do need to know it's path. I also want to be able to look at the
image, so if the digests are different I can see what the difference
is (I'm planning to automate this with the imagemagick compare command
line tool).
> However, I think Hadley is referring to a different problem.
> Basically, he got an object containing a lot of fields, but for his
> purposes it is only a subset of the fields that he wants to use to
> generate a consistent the hashcode. If he pass any other field, that
Yes, exactly.
> will break the consistency. In that case, the designer of the class
> has to identify the fields that makes uniquely identify the state of
> the object. I do that for many of my object and pass them down in a
> list() structure to digest(). I agree, by making digest() generic,
> one can make the code nicer. [If there is a need to dispatch on
> multiple arguments, we have to go for S4, but otherwise S3 gives the
> minimal modification].
>
> Side comment: This basically comes down to how for instance Java deals
> with hashCode() and equals() etc. By default the object as is used to
> generate the hashcode (and can be used by equals() compare objects).
Yes, that's the model I was thinking of too.
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Digest package - make digest generic?
On 10/15/07, hadley wickham <[EMAIL PROTECTED]> wrote:
> On 10/15/07, Henrik Bengtsson <[EMAIL PROTECTED]> wrote:
> > [As agreed, CC:ing r-devel since others might be interested in this as
> > well.]
> >
> > Hi.
> >
> > On 10/15/07, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi Hadley,
> > >
> > > On 15 October 2007 at 09:51, hadley wickham wrote:
> > > | Would you consider making digest a generic function? That way I could
> > > | (e.g.) make a generic method for ggplot objects which didn't depend
> > > | (so much) on their internal representation.
> > >
> > > Well, generally speaking, I always take patches :)
> >
> > I see know problems in doing this. The patch would be:
> >
> > digest <- function(...) UseMethod("digest");
> > digest.default <- .
> >
> > I think that should do, and I don't think it has any surprising side
> > effects so it could be added in the next release. Dirk, can you do
> > that?
> >
> > >
> > > I have to admit that I am fairly weak on these aspects of the S language.
> > > One question is: how to the current users of digest (i.e. Henrik's and
> > > Seth's caching mechanism, for example) use it on arbitrary objects
> > > _without_
> > > it being generic?
> >
> > I basically put everything I want into a list() and pass that to
> > digest::digest().
>
> Yes, that's what I'm doing too.
>
> > >
> > > | The reason I ask is that I'm using digest as a way of coming up with a
> > > | unique file name for each example graphic. I want to be able to
> > > | easily compare the appearance of examples between versions, but
> > > | currently the digest depends on internal details, so it's hard to
> > > | match up graphics between versions.
> >
> > See loadCache(key) and saveCache(object, key) in R.cache, which
> > basically loads and saves results from and to a file cache based on a
> > key object - no need to specify paths or filenames. You can specify
> > paths etc if you want to, but by default it is just transparent.
>
> The problem is I need to refer to the image from the documentation, so
> I do need to know it's path. I also want to be able to look at the
> image, so if the digests are different I can see what the difference
> is (I'm planning to automate this with the imagemagick compare command
> line tool).
See ?findCache. That will give you the pathname given a key. It is
on purpose that I do not list this function in the HTML help index - I
want to keep the "public" API to a minimum.
/Henrik
>
> > However, I think Hadley is referring to a different problem.
> > Basically, he got an object containing a lot of fields, but for his
> > purposes it is only a subset of the fields that he wants to use to
> > generate a consistent the hashcode. If he pass any other field, that
>
> Yes, exactly.
>
> > will break the consistency. In that case, the designer of the class
> > has to identify the fields that makes uniquely identify the state of
> > the object. I do that for many of my object and pass them down in a
> > list() structure to digest(). I agree, by making digest() generic,
> > one can make the code nicer. [If there is a need to dispatch on
> > multiple arguments, we have to go for S4, but otherwise S3 gives the
> > minimal modification].
> >
> > Side comment: This basically comes down to how for instance Java deals
> > with hashCode() and equals() etc. By default the object as is used to
> > generate the hashcode (and can be used by equals() compare objects).
>
> Yes, that's the model I was thinking of too.
>
> Hadley
>
> --
> http://had.co.nz/
>
> __
> 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
