similar to: Managed to confuse match.arg (PR#921)

Displaying 20 results from an estimated 20000 matches similar to: "Managed to confuse match.arg (PR#921)"

2002 Apr 09
0
match.arg confusion (PR#921)
>>>>> "PD" == p dalgaard <p.dalgaard@biostat.ku.dk> writes: PD> [sys.function fails sometimes (sorry, our mail system PD> decide to throw away the original mail)] PD> Yes, I bumped into something similar recently. The PD> problem is that we only actually store the call in the PD> context structure, not the function, so
2000 Oct 13
2
syntax confusion with function/non-function objects (PR#694)
I'm just back from a computer practical where we ran into > "f" <- function(x) 2(x^2) # for 2 * x^2 This definition was taken as legitimate, although using the function generated the error message > f(3) Error in f(3) : attempt to apply non-function Am I right in thinking that in prevous versions of R this definition would have been declared as a syntax error? Surely a
2000 Mar 22
3
segmentation fault with 1D array (PR#500)
Here's a nasty one. The following has caused a segmentation fault and possibly also a bus error. fred <- 1:6 dim(fred) <- 6 dimnames(fred) <- list(LETTERS[1:6]) mm <- matrix(1:12, 2, 6) mm %*% fred # segmentation fault here In the case without the dimnames assignment the result is OK. Cheers, Jonathan. --please do not edit the information below-- Version: platform =
2000 Mar 01
1
"is.qr" definition (PR#465)
Might it be possible to tighten the definition of "is.qr". I noticed that after I mistakenly typed example(lm) # make lm object named lm.D9 qr.Q(lm.D9) which exhausted the heap memory and produced two warning messages. As an object of class "lm" has a "qr" component, "is.qr" failed to detect that "lm.D9" was not a "qr" object. The
2001 Jan 09
3
Inconsistent behaviour in solve (PR#805)
I find this a bit puzzling ... > solve(matrix(c(5, 2, 3, 1), 2, 2), c(Inf, 3)) [1] NaN Inf > solve(matrix(c(5, 2, 3, 1), 2, 2)) %*% c(Inf, 3) [,1] [1,] -Inf [2,] Inf I would expect the answer to be c(-Inf, Inf), so why has the -Inf been replaced by NaN in solve? Cheers, Jonathan. --please do not edit the information below-- Version: platform = sparc-sun-solaris2.7 arch = sparc
2000 May 19
7
variance of a scalar (PR#546)
I was surprised to find that the variance of a scalar, using var(), is NA. Surely this should be zero? Cheers, Jonathan. --please do not edit the information below-- Version: platform = sparc-sun-solaris2.7 arch = sparc os = solaris2.7 system = sparc, solaris2.7 status = Patched major = 0 minor = 99.0 year = 2000 month = February day = 9 language = R Search Path: .GlobalEnv,
2000 Apr 06
2
Strange behaviour of image (PR#510)
The following commands z <- matrix(seq(0, 1, len=1000)) image(z, 1, z, zlim=c(0, 1), col=gray(1:10/10)) appear to violate the image functionality as described on the help page. As I understand it, by specifying a zlim of c(0, 1) and a colour vector of length 10, the colours should correspond to the intervals (0, 0.1), (0.1, 0.2), ..., (0.9, 1.0), this being 10 equally-spaced intervals on (0,
2000 Oct 13
2
Cautionary tale about c (PR#695)
This situation arose in a computer practical this morning. A student overwrote "c" with a function. This messes up lots of things, but it is difficult to remove the function "c" from the global environment because it is used as a function in both "rm" and "remove". [The solution was to reassign "c" as a number, and then remove it.] Would it be
2001 Apr 30
1
Segmentation fault linked to memory? (PR#929)
Hi Everyone, The following rather extreme claim on memory causes a segmentation fault on my installation: fred <- matrix(1:1200, 20, 60) littleOP <- function(x, y) { z <- as.vector(x) %*% t(as.vector(y)) dim(z) <- c(dim(x), dim(y)) z } littleOP(fred, fred) # this is OK littleOP(littleOP(fred, fred), fred) # whoops! Segmentation fault What's a bit strange
2001 Apr 10
1
Segmentation fault in subscripting array of lists (PR#904)
I get a segmentation fault as follows: > tmp <- array(list(), c(3, 4)) > tmp[[1, 2]] NULL # as expected > tmp[[1, 2]]$fred <- 1:10 > tmp # as expected [,1] [,2] [,3] [,4] [1,] "NULL" "List,1" "NULL" "NULL" [2,] "NULL" "NULL"
2000 Jun 20
1
exists() and the mode argument (PR#576)
The following seems to be odd behaviour: fred <- 1:10 mode(fred) # "numeric" exists("fred") # TRUE exists("fred", mode="numeric") # FALSE Unless I have misunderstood, the final evaluation should be TRUE, as an object called "fred" exists and its mode is "numeric". In the same category, I have just noticed that get("fred")
2000 Oct 16
2
print problem with data frames (PR#698)
Another one from the student computer practicals: it is possible to create a dataframe that cannot be printed. Thus > fred <- data.frame(happy=c(TRUE, FALSE, TRUE), sad=7:9) > tmp <- fred[c(FALSE, FALSE, TRUE, TRUE)] # no error message! > tmp Error in as.matrix.data.frame(x) : dim<- length of dims do not match the length of object > print.default(tmp) $"NA" NULL
2001 Apr 25
0
match.arg confusion (PR#921)
[sys.function fails sometimes (sorry, our mail system decide to throw away the original mail)] Yes, I bumped into something similar recently. The problem is that we only actually store the call in the context structure, not the function, so sys.function has to grab the call, take the 1st element, and reevaluate it in the parent frame. It is quite easy to think up examples where a second
1999 Dec 10
1
split nukes names() (PR#371)
> split(c(a=1,b=2),c(1,2)) $"1" [1] 1 $"2" [1] 2 The documentation does not *promise* that names will survive, but in Splus3.4, they do. This broke a function that worked under S+ that used the names attribute of elements in the components returned by split. Chuck Berry --please do not edit the information below-- Version: platform = sparc-sun-solaris2.7 arch = sparc
1999 Dec 18
1
strsplit does not conform to documentation (PR#379)
Description: Split the Strings in `x' into substrings according to the presence of substring `split' within them. -------------------- > strsplit("acbdefgSPLIThigkilmnSpPqrst","SPLIT") [[1]] [1] "acbdefg" "higkilmn" "p" "qrst" -------------------- Apparently, it will Split the Strings in `x' into
2001 Mar 23
1
eigen segfaults on 0-diml matrices (PR#882)
>From one of my students' simulations: m <- matrix(1, 0, 0) # 1 to force numeric not logical eigen(m) and segfault in TRED2 in src/appl/eigen.f Easy to fix, but I wonder what else might have been overlooked? (svd is protected). --please do not edit the information below-- Version: platform = sparc-sun-solaris2.7 arch = sparc os = solaris2.7 system = sparc, solaris2.7 status =
2001 Mar 23
0
cor(x,y) when is.null(y) (PR#883)
Problem: > names(my.dat) [1] "x" "y" > cor(my.dat$x,my.dat$y) # desired result [1] 0.8660254 > cor(my.dat$x,my.dat$y.NOT) # typo [1] 1 > I'd prefer a warning() or stop() in that case. Solution (??) : *** 1,5 **** --- 1,7 ---- cor <- function (x, y=NULL, use="all.obs") { + if (is.null(y) && !is.null( match.call()$y ) ) +
2000 Mar 13
1
plot(1:10,c(1)$nothing) yields index plot (PR#482)
<<insert bug report here>> IMHO, plot(x,c(1)$nothing) should fail or at least issue a warning. Instead it produces an index plot of the first argument, i.e. plot(x) Chuck Berry --please do not edit the information below-- Version: platform = sparc-sun-solaris2.7 arch = sparc os = solaris2.7 system = sparc, solaris2.7 status = Patched major = 1 minor = 0.0 year = 2000
2001 Jun 18
1
"[.data.frame" allows un-named 3rd subscript (PR#989)
Since the Extract page has usage as: x[i, j, ... , drop=TRUE] I would expect that 'drop=' would need to be given to the third 'subscript' > diag(4)[ , 4 , 4 ] # Forgot 'drop=' or added extra ',' Error in diag(4)[, 4, 4] : incorrect number of dimensions > > as.data.frame( diag(4) )[ , 4 , 4 ] # should return error, right? [1] 0 0 0 1 Also note:
2002 Jan 04
2
R CMD check (PR#1240)
SunOS fluke 5.8 Generic_108528-07 sun4u sparc SUNW,Ultra-Enterprise R-1.4.0 Running from the command line R CMD check chlib results in the log file 00check.log: * using log directory `/home/woodstock/hoffmann/R/Sources/chlib.Rcheck' * checking for file `chlib/DESCRIPTION' ... OK * checking package directory ... OK * checking for sufficient/correct file permissions ... WARNING *