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
*