Martyn Plummer <plummer@iarc.fr> writes:> 3) I have no idea what's going on here. > > > c(r=1,s=2) > s > 2 > > c(u=100,b=4) > b > 4 > > This seems to happen only for "r" and "u". Other single-letter > names are OK. This doesn't happen on my home PC which is still > running R-0.50-a1."r" is probably matching "recursive", but what about "u"? ("unlist"??) -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
This message is in MIME format --_=XFMail.1.1.p0.Linux:971128122615:3052=_ Content-Type: text/plain; charset=us-ascii I have rounded up three buglets in R-0.50-a4. Two of them I can fix and a patch is supplied below. I hope this is useful for the current source (if these haven't been fixed already :) 1) cov cov() fails when it's argument is a matrix with one column and with column names defined. It tries to apply dimnames to the output but the output is a vector of length 1.> x <- matrix(rnorm(100),ncol=1,dimnames=list(NULL,"foo")) > var(x)Error: dimnames applied to non-array 2) Subscripting one-dimensional arrays. These are treated as vectors when subscripting so subscripting by dimnames fails.> x <- c(0,0,0,1,1,1,1,3) > table(x)0 1 3 3 4 1> table(x)["3"]Error: subscript out of bounds 3) I have no idea what's going on here.> c(r=1,s=2)s 2> c(u=100,b=4)b 4 This seems to happen only for "r" and "u". Other single-letter names are OK. This doesn't happen on my home PC which is still running R-0.50-a1. Martyn --_=XFMail.1.1.p0.Linux:971128122615:3052=_ Content-Type: text/plain; charset=us-ascii; name=apatch; SizeOnDisk=1206 Content-Description: apatch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="apatch" diff -ur R-0.50-a4/src/main/cov.c R-0.50-a4.patched/src/main/cov.c --- R-0.50-a4/src/main/cov.c Sun Nov 24 23:43:05 1996 +++ R-0.50-a4.patched/src/main/cov.c Fri Nov 28 11:21:23 1997 @@ -390,7 +390,7 @@ } if(isNull(y)) { x = getAttrib(x, R_DimNamesSymbol); - if(!isNull(x) && !isNull(CADR(x))) { + if(ncx > 1 && !isNull(x) && !isNull(CADR(x))) { PROTECT(ind = allocList(2)); CAR(ind) = CADR(x); CADR(ind) = CADR(x); @@ -401,7 +401,7 @@ else { x = getAttrib(x, R_DimNamesSymbol); y = getAttrib(y, R_DimNamesSymbol); - if((!isNull(x) && !isNull(CADR(x))) || (!isNull(y) && !isNull(CADR(y)))) { + if((ncx > 1 && !isNull(x) && !isNull(CADR(x))) || ( ncy > 1 && !isNull(y) && !isNull(CADR(y)))) { PROTECT(ind = allocList(2)); CAR(ind) = CADR(x); CADR(ind) = CADR(y); diff -ur R-0.50-a4/src/main/subset.c R-0.50-a4.patched/src/main/subset.c --- R-0.50-a4/src/main/subset.c Mon Aug 11 04:59:12 1997 +++ R-0.50-a4.patched/src/main/subset.c Fri Nov 28 11:16:55 1997 @@ -608,7 +608,7 @@ PROTECT(dim = getAttrib(x, R_DimSymbol)); nsubs = length(subs); - if(nsubs == 1) { + if(nsubs == 1 && isNull(dim)) { ans = vectorSubset(x, CAR(subs), call); } else { --_=XFMail.1.1.p0.Linux:971128122615:3052=_-- End of MIME message -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On 28-Nov-97 p.dalgaard@biostat.ku.dk wrote:>Martyn Plummer <plummer@iarc.fr> writes: > >> 3) I have no idea what's going on here. >> >> > c(r=1,s=2) >> s >> 2 >> > c(u=100,b=4) >> b >> 4 >> >"r" is probably matching "recursive", but what about "u"? ("unlist"??)Aha! It's matching use.names (one of the arguments of unlist())> c(u=0,x=1,y=2)[1] 1 2> c(u=10,x=1,y=2)x y 1 2 Isn't it a bit dangerous to allow partial matching of arguments (especially undocumented arguments)? NB It doesn't consistently match the arguments either:> c(r=1,u=2)u 2> c(u=2,r=1)r 1 Martyn -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Martin Maechler
1997-Nov-28 14:11 UTC
R-alpha: "..." arg.matching [was 'Problems with dimnames and names']
>>>>> "Martyn" == Martyn Plummer <plummer@iarc.fr> writes:Martyn> I have rounded up three buglets in R-0.50-a4. Two of them I can Martyn> fix and a patch is supplied below. I hope this is useful for the Martyn> current source (if these haven't been fixed already :) Both of these bugs are already fixed in 0.60 Martyn> 1) cov Martyn> cov() fails when it's argument is a matrix with one column and with Martyn> column names defined. It tries to apply dimnames to the output but Martyn> the output is a vector of length 1. >> x <- matrix(rnorm(100),ncol=1,dimnames=list(NULL,"foo")) >> var(x) Martyn> Error: dimnames applied to non-array Martyn> 2) Subscripting one-dimensional arrays. Martyn> These are treated as vectors when subscripting Martyn> so subscripting by dimnames fails. >> x <- c(0,0,0,1,1,1,1,3) >> table(x) Martyn> 0 1 3 Martyn> 3 4 1 >> table(x)["3"] Martyn> Error: subscript out of bounds -- Now to the ``real'' one : -- Martyn> 3) I have no idea what's going on here. >> c(r=1,s=2) Martyn> s Martyn> 2 >> c(u=100,b=4) Martyn> b Martyn> 4 Martyn> This seems to happen only for "r" and "u". Other single-letter Martyn> names are OK. This doesn't happen on my home PC which is still Martyn> running R-0.50-a1. Well, we (i.e., Peter and Martyn) have found *why* it happens. However, this is a semantic change from older versions of R and from S which I consider serious [a bug ?!?] an we should discuss. The general accepted semantic for S is: <> <> If a function has a '...' argument, <> <> <> <> all the other argument names must be matched EXACTLY, <> <> (S) <> <> not only up to the unique string beginning. <> <> This behaviour (S) definitely IS a pain sometimes, because it forces you not abbreviate argument names for all these functions. For the ``function writer'', this leads to 1) you really should only use "..." arguments if you must. 2) if you have "..." argument(s), use relatively short argument names for the other arguments 3) if there are named arguments in "..." (which is the usual case), make sure [if you can, which is the case mostly, but not for 'c(.)'] that all the argument names are valid. Unfortunately, "3)" is not followed too often in S-plus, which leads to the ``famous'' situation, that glm(ni ~ x1 * x2, familiy = binomial) will fit a normal instead of a logistic regression, with no warning, just because of a 1 letter typo .. (misspelling of 'familiy' makes the whole argument be ignored, and family = gaussian , the default, be taken). -------- So, we now see why Ross(?) may have wanted to change the argument matching behavior in the "..." case. [[Rule: If S does things wierdly, R should do better ...]] I still think however that this must be carefully tought over, and I am not yet convinced if we shouldn't follow the S way after all. Where we could do better (in our `own' functions) is to folllow my rule "3)" above as strictly as possible. Martin Maechler <maechler@stat.math.ethz.ch> <>< Seminar fuer Statistik, SOL G1 ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND phone: x-41-1-632-3408 fax: ...-1086 http://www.stat.math.ethz.ch/~maechler/ -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._