Re: [Rd] documentation bug as S-Plus catches up (PR#8933)
> "RMH" == Richard M Heiberger <[EMAIL PROTECTED]> > on Sat, 3 Jun 2006 01:31:48 +0200 (CEST) writes: RMH> # R for Windows will not send your bug report RMH> automatically. # Please copy the bug report (after RMH> finishing it) to # your favorite email program and send RMH> it to # # [EMAIL PROTECTED] # RMH> ## RMH> The R documentation for "is.R" says "## 'which()' only RMH> exists in R:" This is no longer true. In S-Plus 8.0 >> version RMH> Enterprise Developer Version 8.0.1 Beta 1 for Microsoft RMH> Windows : 2006 RMH> both "is.R" and "which" are defined in the splus RMH> directory. Thank you, Rich, for the update. Note however that this is a *beta* version of S-plus, that I'd guess 95--99.5% of S-plus users are *not* using currently. Here, ETH has been paying a site licence for S-plus for many years, but we haven't been able to even use S-plus 7.x, because of problems that seem to make it impossible that the ETH-central licence server can continued to be used for S+7 (given the current IT infrastructure & staff). RMH> Now that coordination with R, including use of the RMH> package system, is one of the Insightful goals, I hope RMH> someone in R-core will be monitoring these changes. [who were you hoping for ? ;-)] RMH> Let me know if you want me to post these types of RMH> things in the future. I won't unless specically RMH> requested. I'd say we are thankful if you continue to do so, to R-devel typically rather than R-bugs, particularly in border cases like the current one. Martin RMH> Rich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] plot.new, trellis and windows plot history (PR#8935)
Full_Name: Andrew Hooker Version: 2.3.1 OS: windows xp sp2 Submission from: (NULL) (83.253.8.162) Hi, I think there is a bug in the windows graph history procedure, here is what happens: 1. open R 2. 'library(lattice)' 3. 'xyplot(0~0)' 4. Turn on recording in the graphical window 5. Add plot to history 4. 'plot.new()' 5. 'xyplot(1~1)' Try to 'pageup' to the first plot. I can't get the first plot to appear, and if I turn off the graphics device using 'dev.off()' I get a warning message: 1: Display list redraw incomplete Any ideas how to fix this? Andrew Hooker Uppsala University Sweden __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] More on bug 7924
Hi,
Again, sorry for the length of this post. Once I get my new office I
will get a website set up on my work machine and will simply post a
link to the log since I doubt many people are truly interested in
these logs.
To further analyze what is happening, I added my own routine in
main.c called DEBUG_SET_NAMED and then redefined the SET_NAMED macro
to use it and then rebuilt R.
I then fired up R under a fresh environment and running under GDB
and set a breakpoint at my DEBUG_SET_NAMED and at compute_identical
> call1 <- Quote(f(arg[[1]], arg[[1]], arg[[1]]))
So running this statement shows that SET_NAMED was run on 5 objects
of type 13,16,10,3 and with the last one being a type 6.
In all cases, but the type 6 object, named was set to 2. For the
type 6 object, named was set to 1
Breakpoint 1, DEBUG_SET_NAMED (x=0x85cfd8, v=2)
at ../../../r-devel/r-devel/R/src/main/main.c:1444
1444 (x->sxpinfo.named) = v;
$1 = 0x85cfd8
$2 = {sxpinfo = {type = 13, obj = 0, named = 2, gp = 0, mark = 1,
debug = 0,
trace = 0, fin = 0, gcgen = 0, gccls = 1}, attrib = 0x508818,
gengc_next_node = 0x6db278, gengc_prev_node = 0x8442b8, u =
{primsxp = {
offset = 2}, symsxp = {pname = 0x2, value = 0x230002acc2,
internal = 0x2190}, listsxp = {carval = 0x2, cdrval =
0x230002acc2,
tagval = 0x2190}, envsxp = {frame = 0x2, enclos =
0x230002acc2,
hashtab = 0x2190}, closxp = {formals = 0x2, body =
0x230002acc2,
env = 0x2190}, promsxp = {value = 0x2, expr = 0x230002acc2,
env = 0x2190}}}
#0 DEBUG_SET_NAMED (x=0x85cfd8, v=2)at ../../../r-devel/r-devel/
R/src/main/main.c:1444
#1 0x2ab67b04 in Rf_eval (e=0x570348, rho=0x9eb5f0)
at ../../../r-devel/r-devel/R/src/main/eval.c:389
Breakpoint 1, DEBUG_SET_NAMED (x=0x87da18, v=2) at ../../../r-devel/
r-devel/R/src/main/main.c:1444
1444 (x->sxpinfo.named) = v;
$3 = 0x87da18
$4 = {sxpinfo = {type = 16, obj = 0, named = 2, gp = 0, mark = 1,
debug = 0,
trace = 0, fin = 0, gcgen = 0, gccls = 1}, attrib = 0x508818,
gengc_next_node = 0x8403f8, gengc_prev_node = 0x87d868, u =
{primsxp = {
offset = 1}, symsxp = {pname = 0x1, value = 0x1185c48,
internal = 0x200a}, listsxp = {carval = 0x1, cdrval =
0x1185c48,
tagval = 0x200a}, envsxp = {frame = 0x1, enclos = 0x1185c48,
hashtab = 0x200a}, closxp = {formals = 0x1, body = 0x1185c48,
env = 0x200a}, promsxp = {value = 0x1, expr = 0x1185c48,
env = 0x200a}}}
#0 DEBUG_SET_NAMED (x=0x87da18, v=2)at ../../../r-devel/r-devel/
R/src/main/main.c:1444
#1 0x2ab67b04 in Rf_eval (e=0x545ed0, rho=0x9eb5f0)
at ../../../r-devel/r-devel/R/src/main/eval.c:389
Breakpoint 1, DEBUG_SET_NAMED (x=0x822bf8, v=2)at ../../../r-
devel/r-devel/R/src/main/main.c:1444
1444 (x->sxpinfo.named) = v;
$5 = 0x822bf8
$6 = {sxpinfo = {type = 10, obj = 0, named = 2, gp = 0, mark = 1,
debug = 0,
trace = 0, fin = 0, gcgen = 0, gccls = 1}, attrib = 0x508818,
gengc_next_node = 0x661208, gengc_prev_node = 0x840428, u =
{primsxp = {
offset = 1}, symsxp = {pname = 0x1, value = 0x1, internal =
0x2090},
listsxp = {carval = 0x1, cdrval = 0x1, tagval = 0x2090},
envsxp = {
frame = 0x1, enclos = 0x1, hashtab = 0x2090}, closxp = {
formals = 0x1, body = 0x1, env = 0x2090}, promsxp = {value
= 0x1,
expr = 0x1, env = 0x2090}}}
#0 DEBUG_SET_NAMED (x=0x822bf8, v=2)
at ../../../r-devel/r-devel/R/src/main/main.c:1444
#1 0x2ab67b04 in Rf_eval (e=0x570230, rho=0x9eb5f0)
at ../../../r-devel/r-devel/R/src/main/eval.c:389
Breakpoint 1, DEBUG_SET_NAMED (x=0x5d02d0, v=2)
at ../../../r-devel/r-devel/R/src/main/main.c:1444
1444 (x->sxpinfo.named) = v;
$7 = 0x5d02d0
$8 = {sxpinfo = {type = 3, obj = 0, named = 2, gp = 0, mark = 1,
debug = 0,
trace = 0, fin = 0, gcgen = 0, gccls = 0}, attrib = 0x508818,
gengc_next_node = 0x5d0378, gengc_prev_node = 0xb843c0, u =
{primsxp = {
offset = 5711720}, symsxp = {pname = 0x572768, value = 0x5745c0,
internal = 0x648910}, listsxp = {carval = 0x572768, cdrval =
0x5745c0,
tagval = 0x648910}, envsxp = {frame = 0x572768, enclos =
0x5745c0,
hashtab = 0x648910}, closxp = {formals = 0x572768, body =
0x5745c0,
env = 0x648910}, promsxp = {value = 0x572768, expr = 0x5745c0,
env = 0x648910}}}
#0 DEBUG_SET_NAMED (x=0x5d02d0, v=2)
at ../../../r-devel/r-devel/R/src/main/main.c:1444
#1 0x2ab67b04 in Rf_eval (e=0x570188, rho=0x9eb5f0)
at ../../../r-devel/r-devel/R/src/main/eval.c:389
Breakpoint 1, DEBUG_SET_NAMED (x=0x9ebe58, v=1)at ../../../r-
devel/r-devel/R/src/main/main.c:1444
1444 (x->sxpinfo.named) = v;
$9 = 0x9ebe58
$10 = {sxpinfo = {type = 6, obj = 0, named = 0, gp = 0, mark = 0,
debug = 0,
trace = 0, fin = 0, gcgen = 0, gccls = 0}, attrib = 0x508818,
gengc_ne
[Rd] YOUR E-MAIL ADDRESS WON THE LOTTERY. (PR#8936)
--qzsoft_directmail_seperator Content-Type: text/plain; charset="DEFAULT" Content-Transfer-Encoding: base64 IAogCgpFdXJvbWlsbGlvbiBMb3RlcmlhIEVzcGHxb2wKUGFzZW8gRGUgTGEgQ2FzdGVsbGFuYSAx NS04OSwgMjgwMDggTWFkcmlkLiAKU3BhaW4uIEJyYW5jaCBPZmZpY2UuClJlZi4gTro6IEVTLzYw Ny8wNS80NC9NQUQuIApCYXRjaC4gTro6IEdIVC84ODA3LzMzMy8wNS4gCgpZT1VSIEUtTUFJTCBB RERSRVNTIFdPTiBUSEUgTE9UVEVSWS4gCldlIHdpc2ggdG8gY29uZ3JhdHVsYXRlIHlvdSBvdmVy IHlvdXIgZW1haWwgc3VjY2VzcyBpbgpvdXIgY29tcHV0ZXIgYmFsbG90aW5nIHN3ZWVwc3Rha2Ug aGVsZCBvbiAyNnRoIE1heSwKMjAwNi4gVGhpcyBpcyBhIG1pbGxlbm5pdW0gc2NpZW50aWZpYyBj b21wdXRlciBnYW1lIGluCndoaWNoIGVtYWlsIGFkZHJlc3NlcyB3ZXJlIHVzZWQuIEl0IGlzIGEg cHJvbW90aW9uYWwKcHJvZ3JhbSBhaW1lZCBhdCBlbmNvdXJhZ2luZyBpbnRlcm5ldCB1c2Vyczsg dGhlcmVmb3JlCnlvdSBkbyBub3QgbmVlZCB0byBidXkgdGlja2V0IHRvIGVudGVyIGZvciBpdC4g WW91cgplbWFpbCBhZGRyZXNzIGF0dGFjaGVkIHRvIHRpY2tldCBzdGFyIG51bWJlciAoMi0zKQpk cmV3IHRoZSBFVVJPTUlMTElPTiBsdWNreSBudW1iZXJzIDMtMTktNzMtMzMtMTAgd2hpY2gKY29u c2VxdWVudGx5IHdvbiB0aGUgZHJhdyBpbiB0aGUgU2Vjb25kIGNhdGVnb3J5LiAKWW91IGhhdmUg YmVlbiBhcHByb3ZlZCBmb3IgdGhlIHN0YXIgcHJpemUgb2YgRVVSCjkzMyw1ODEuNDQuIChOaW5l IEh1bmRyZWQgQW5kIFRoaXJ0eSBUaHJlZSBUaG91c2FuZCxGaXZlCkh1bmRyZWQgYW5kIEVpZ2h0 eSBPbmUgRXVyb3MsRm91cnR5IEZvdXIgQ2VudHMpLiAKQ09OR1JBVFVMQVRJT05TISEhIFlvdSBh cmUgYWR2aXNlZCB0byBrZWVwIHRoaXMKd2lubmluZyB2ZXJ5IGNvbmZpZGVudGlhbCB1bnRpbCB5 b3UgcmVjZWl2ZSB5b3VyIGx1bXAKcHJpemUgaW4geW91ciBhY2NvdW50IG9yIG9wdGlvbmFsIGNo ZXF1ZSBpc3N1YW5jZSB0bwp5b3UuIFRoaXMgaXMgYSBwcm90ZWN0aXZlIG1lYXN1cmUgdG8gYXZv aWQgZG91YmxlCmNsYWltaW5nIGJ5IHBlb3BsZSB5b3UgbWF5IHRlbGwgYXMgd2UgaGF2ZSBoYWQg Y2FzZXMKbGlrZSB0aGlzIGJlZm9yZSwgcGxlYXNlIHNlbmQgeW91ciBGdWxsIE5hbWUsIEhvbWUg YW5kCk9mZmljZSBUZWxlcGhvbmUgJiBGYXggTnVtYmVyLCBNb2JpbGUgVGVsIE51bWJlciBhbmQK eW91ciB3aW5uaW5nIHRpY2tldCBudW1iZXIsIHJlZmVyZW5jZSBudW1iZXJzIGFuZAphbW91bnQg d29uIGluZm9ybWF0aW9uIGZvciBwcm9jZXNzaW5nIG9mIHlvdXIgd2lubmluZwpmdW5kIHRvIG91 ciByZWdpc3RlcmVkIGNsYWltIGFnZW50IGluIHRoZSBhZGRyZXNzIGJlbG93LiAKTXIuUGVycnkg RG9uYXZhbi4KUm95YWwgQ29hc3RhIFNlY3VyaXR5IFMuTApBZGRyZXNzOk1hcmlvIENhYnJlIDIw NwpHYXRlZmUgQ2VudHJvLSBNYWRyaWQsIApTcGFpbi4gCkUtbWFpbDogaW5mb3dpbm5lcnNsb3Qx QG5ldHNjYXBlLm5ldApFbWFpbDogcGVycnlkb25hdmFuQG5ldHNjYXBlLm5ldCAKUmVtZW1iZXIs IGFsbCB3aW5uaW5nIG11c3QgYmUgY2xhaW1lZCBub3QgbGF0ZXIgdGhhbgoyNnRoIG9mIGp1bmUs IDIwMDYuIFBsZWFzZSBub3RlLCBpbiBvcmRlciB0byBhdm9pZAp1bm5lY2Vzc2FyeSBkZWxheXMg YW5kIGNvbXBsaWNhdGlvbnMsIHJlbWVtYmVyIHRvCnF1b3RlIHlvdXIgcmVmZXJlbmNlIG51bWJl ciBhbmQgYmF0Y2ggbnVtYmVyIGluIGFsbApjb3JyZXNwb25kZW5jZS4gRnVydGhlcm1vcmUsIHNo b3VsZCB0aGVyZSBiZSBhbnkKY2hhbmdlIG9mIGFkZHJlc3MgZG8gaW5mb3JtIG91ciBhZ2VudCBh cyBzb29uIGFzCnBvc3NpYmxlLiAKT25jZSBhZ2FpbiBjb25ncmF0dWxhdGlvbnMuIApNcnMuTWFy eSBGZXJkZW5hcmQuCkZvciBNci5QZXJyeSBEb25hdmFuLgpMb3R0ZXJ5IENvLW9yZGluYXRvci4g ClRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUKcGVy c29uIG9yIGVudGl0eSB0byB3aG9tIG9yIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4KVW5hdXRob3Jp c2VkIHVzZSwgZGlzY2xvc3VyZSBvciBjb3B5aW5nIGlzIHN0cmljdGx5CnByb2hpYml0ZWQuIFRo ZSBzZW5kZXIgYWNjZXB0cyBubyBsaWFiaWxpdHkgZm9yIHRoZQppbXByb3BlciB0cmFuc21pc3Np b24gb2YgdGhpcyBjb21tdW5pY2F0aW9uIG5vciBmb3IKYW55IGRlbGF5IGluIGl0cyByZWNlaXB0 LiA= --qzsoft_directmail_seperator-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot.new, trellis and windows plot history (PR#8935)
Andrew, Why are you calling plot.new()? Peter Ehlers [EMAIL PROTECTED] wrote: > Full_Name: Andrew Hooker > Version: 2.3.1 > OS: windows xp sp2 > Submission from: (NULL) (83.253.8.162) > > > Hi, > > I think there is a bug in the windows graph history procedure, here is what > happens: > > 1. open R > 2. 'library(lattice)' > 3. 'xyplot(0~0)' > 4. Turn on recording in the graphical window > 5. Add plot to history > 4. 'plot.new()' > 5. 'xyplot(1~1)' > > Try to 'pageup' to the first plot. I can't get the first plot to appear, and > if > I turn off the graphics device using 'dev.off()' I get a warning message: > > 1: Display list redraw incomplete > > Any ideas how to fix this? > > Andrew Hooker > Uppsala University > Sweden > > __ > 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] head() for tables
head() doesn't do anything particularly useful for tables ... For example: z <- sample(1:20,size=1000,replace=TRUE) z2 <- sample(1:20,size=1000,replace=TRUE) t1 <- table(z,z2) head(t1) as.matrix() doesn't help ... head(as.matrix(t1)) this does ... class(t1) <- "matrix" so does head.table <- utils:::head.matrix is it worth making this duplication in the code? Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] trivial typo in ?fisher.test
in the comments at the beginning of the first example, line 6: "and the women's guess" should be "and the woman's guess" Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] head() for tables
On 6/3/2006 8:52 PM, Ben Bolker wrote: >head() doesn't do anything particularly > useful for tables ... > >For example: > > z <- sample(1:20,size=1000,replace=TRUE) > z2 <- sample(1:20,size=1000,replace=TRUE) > t1 <- table(z,z2) > head(t1) > > as.matrix() doesn't help ... > head(as.matrix(t1)) > >this does ... > > class(t1) <- "matrix" > > so does > > head.table <- utils:::head.matrix > >is it worth making this duplication in the code? This seems to be a deeper problem. as.matrix(t1) still returns an object of class "table", so head(as.matrix(t1)) dispatches to head.default, rather than to head.matrix. You can force the latter by utils:::head.matrix(t1) and get reasonable output. Perhaps as.matrix(x) should strip off the class attribute, or add a "matrix" class attribute? Or perhaps head.default should check for is.matrix? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] trivial typo in ?fisher.test
>in the comments at the beginning of the first example, > line 6: "and the women's guess" should be "and the woman's guess" > >Ben Bolker sorry I forgot to say: this and the previous comment apply to 2.3.1 (on Windows, although that should be irrelevant) ... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] xy.coords(MATRIX) bug in code or documentation (PR#8937)
Hi, people. xy.coords() does not behave like its documentation says, when given some matrices. ?xy.coords says: If 'y' is 'NULL' and 'x' is a [...] formula [...] list [...] time series [...] matrix with two columns [...] In any other case, the 'x' argument is coerced to a vector and returned as *y* component [...] Now, consider this short transcript: ==> > as.vector(rbind(1, 2, 3)) [1] 1 2 3 > as.vector(cbind(1, 2, 3)) [1] 1 2 3 > xy.coords(rbind(1, 2, 3)) $x [1] 1 2 3 $y [1] 1 2 3 $xlab [1] "Index" $ylab NULL > xy.coords(cbind(1, 2, 3)) $x [1] 1 $y [1] 2 $xlab [1] "[,1]" $ylab [1] "[,2]" ==< A 3 x 1 matrix and a 1 x 3 matrix both fall in the "In any other case" category, but it seems that only the 3 x 1 is really "coerced to a vector". The R code for xy.coord() suggests that the documentation should read "matrix with at least two columns" instead of "matrix with two columns". As a user, I was really expecting the coercion to a vector to happen. What triggered me into exploring this problem is the fact that plot() showed a single point where I was expecting many. If you decide that the code is right and the documentation is wrong, then I would suggest that the code be a bit more friendly, by at least issuing some warning if more than two columns are given to a matrix. Another problem in the same area: the documentation lies about how the function acts when given a data.frame. From the code, a data.frame is processed as if it was a matrix. From the documentation, while the data.frame is not mentioned explicitely, it is implied in the paragraph explaining how a list is processed (because a data.frame is a list). Some reconciliation is needed here as well. --please do not edit the information below-- Version: platform = i686-pc-linux-gnu arch = i686 os = linux-gnu system = i686, linux-gnu status = Under development (unstable) major = 2 minor = 4.0 year = 2006 month = 06 day = 01 svn rev = 38258 language = R version.string = R version 2.4.0 Under development (unstable) (2006-06-01 r38258) Locale: LC_CTYPE=fr_CA.UTF-8;LC_NUMERIC=C;LC_TIME=fr_CA.UTF-8;LC_COLLATE=fr_CA.UTF-8;LC_MONETARY=fr_CA.UTF-8;LC_MESSAGES=fr_CA.UTF-8;LC_PAPER=fr_CA.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=fr_CA.UTF-8;LC_IDENTIFICATION=C Search Path: .GlobalEnv, package:methods, package:stats, package:utils, package:datasets, fp.etc, package:graphics, package:grDevices, Autoloads, package:base -- François Pinard http://pinard.progiciels-bpi.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
