similar to: var() with 0-length vector -- docs inconsistent with result

Dear sirs, One gets unexpected `residuals` if one is not aware of the meaning of weights when a weight is set to zero and the outcome is one in the `binomial` family in a call to `glm.fit`. The reason is the following line from `binomial()$initialize` > y[weights == 0] <- 0 Here is an example: pval <- seq(.05, .95, length.out = 25) X <- log(pval / (1 - pval)) - 2 Y <- c( FALSE,

For what it's worth the following patch fixes that particular problem on my system.? I have not checked very carefully to make sure this does not cause other problems, but at a high level it seems to make sense.? In this particular part of the code I believe `mode` is taken to be the highest type of "column" encountered by `ctype` and based on conditionals it can (I think) be up to

This may be a doc error or a coding bug. The help page for sample says: "Non-integer positive numerical values of n or x will be truncated to the next smallest integer, which has to be no larger than .Machine$integer.max." This is not true: > table(sample(2.5, 1000000, replace = TRUE)) 1 2 3 399933 399716 200351 We shouldn't have those 3's if

Hi there, using cbind with a numeric and raw argument produces an incorrect result. I've posted some details below, kind regards, Mike. e.g. > cbind(0, as.raw(0)) [,1] [,2] [1,] 0 6.950136e-310 A longer example shows that the result is not a rounding error, is not consistent, and repeated applications get different results. > cbind(0, as.raw(1:10))

Thanks Brodie, that's some nice detective work. If someone wanted to grant me access to Bugzilla, I'll be happy to post the bug and patch there (with your permission Brodie?) and help this bug get fixed. Mike. On Tue., 25 Sep. 2018, 10:53 pm brodie gaslam, <brodie.gaslam at yahoo.com> wrote: > > > For what it's worth the following patch fixes that particular problem

Dear list, Utils::modifyList() drops NULL components in its second argument, instead of adding them to the first argument. Compare: > modifyList(x=list(A=1), val=list(B=2, C=3)) $A [1] 1 $B [1] 2 $C [1] 3 > modifyList(x=list(A=1), val=list(B=NULL, C=3)) $A [1] 1 $C [1] 3 To me this seems inconsistent with the documentation ("Elements in 'val' which are missing from

I think this needs to be taken off the bug repository and continued here. By now it seems pretty clear that this is not an R bug, but a local problem on Spencer's machine, likely connected to font configurations. I poked around a bit on the three Macs that I can access, and found that fc-match does different things, including throwing warnings, hanging and even crashing my old MB Air... One

I believe the word "truncated" is causing the confusion. 3 is "the next smallest integer" following 2.5. But it is not the truncation done by trunc(). Rewording to "rounding the next smallest integer" would get rid of that confusion imho. Cheers Joris On Wed, Sep 19, 2018 at 7:57 PM Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > This may be a doc

Seems ok on my system. Axis label size changes when cex.axis does. ## tested in the middle of another long session, so many additional packages are attached, including some personal packages not available elsewhere > sessionInfo() R version 3.5.1 (2018-07-02) Platform: x86_64-apple-darwin15.6.0 (64-bit) Running under: macOS High Sierra 10.13.6 Matrix products: default BLAS:

On 06/09/2018 10:47, peter dalgaard wrote: > I think this needs to be taken off the bug repository and continued here. By now it seems pretty clear that this is not an R bug, but a local problem on Spencer's machine, likely connected to font configurations. Or even on R-sig-Mac. > I poked around a bit on the three Macs that I can access, and found that fc-match does different things,

[R 1.7.1 on Windows XP Pro] Since R allows missing values for character variables, why are NA's not propagated by character manipulation functions? For example: > temp <- c("a", NA) > temp [1] "a" NA > is.na(temp) [1] FALSE TRUE > paste(temp[1], temp[2]) [1] "a NA" > substr(temp, 1, 1) [1] "a" "N" >

????? Plots produced using svg in R 3.5.1 under macOS 10.13.6 ignores cex.axis=2.? Consider the following: > plot(1:2, cex.axis=2) > svg('svg_ignores_cex.axis.svg') > plot(1:2, cex.axis=2) > dev.off() > sessionInfo() R version 3.5.1 (2018-07-02) Platform: x86_64-apple-darwin15.6.0 (64-bit) Running under: macOS High Sierra 10.13.6 Matrix products: default BLAS:

Hello, I encountered some unexpected behavior of unzip when using info-zip's unzip instead of R's internal program. Specifically, unzip("file.zip", list=TRUE, unzip=/usr/bin/unzip) produces incorrect output if the zip archive has filenames with spaces, and results in an error if the zip archive includes an archive comment or file comments. Here is some code to reproduce along

R 1.6.1 on Windows NT4: The boxplot() function appears to draw its own tick marks and axis values even when called with add=TRUE. As a toy example, try x <- rnorm(100) f <- factor(rep(1:4, each=25)) plot(c(0,4), c(-3,3), type="n", xaxt="n", yaxt="n") boxplot(x ~ f, add=TRUE) My expectation is that a high-level plotting function will not mess with the axes

The following command, temp <- read.table("c:/rfr/r/test.txt") reads the text file "test.txt", which contains the following lines: 21437 21438 21419-2 21420-2 21421-2 21422-2 and produces the following result: > temp V1 1 21437+0i 2 21438+0i 3 0+0i 4 0+0i 5 0+0i 6 0+0i > These "numbers" are actually sample ID's, and I

I am using R 1.7.1 on Windows XP Pro. The 'overwrite=FALSE' argument appears to be ignored in file.copy(): > file.exists(c("file1.txt", "file2.txt")) [1] TRUE TRUE > file.copy(from="file2.txt", to="file1.txt", overwrite=FALSE) [1] TRUE > and sure enough, file1.txt has been overwritten. Rich Raubertas Biometrics Research, RY33-300 Merck

I am using the dotplot function from the lattice package to display a quantitative variable versus two factors, say 'a' and 'b'. The levels of 'a' are nested within levels of 'b'. The issue is that dotplot includes all the levels of 'a' in each panel (conditioning on 'b'), even though many are empty in any given panel. A toy example is dat

R 1.7.1 on Windows XP The "normal Q-Q plot" produced by plot.lm() mislabels points when the model is fitted using na.action=na.exclude. Example: x <- 1:50 y <- x + rnorm(50) y[c(5,10,15)] <- NA # insert some NA's y[40] <- 50 # add an outlier plot(lm(y ~ x, na.action=na.omit)) # outlier correctly labeled in all # four plots

Hello, All: I'm getting different answers from "lapply(ts(1:2), length)", depending on what is attached, with nothing obviously masked. 1. Am I correct that the answer to "lapply(ts(1:2), length)" should be a list of length 2 consisting of "int 1" twice? This is what I get from R 3.0.2 with nothing else attached. If I've attached

Hi Thanks for that, but I still cannot confirm on ... sudo docker run -v $(pwd):/home/work/ -w /home/work --rm -ti rocker/r-ver:3.5.1 Could you please read the comments within the "Cairo Fonts" section of the ?X11 help page, in case that offers some explanation. Paul On 29/08/18 02:15, Martin M?ller Skarbiniks Pedersen wrote: > On Fri, 24 Aug 2018 at 19:53, Edzer Pebesma >