similar to: nchar reporting wrong width when zero-space character is present?

This question is more out of curiosity than a complaint or suggestion, but I'm just wondering. The behavior of R on calculations that result in NaN seems a bit inconsistent. # this is expected: > 0/0 [1] NaN # but this gives a warning > sin(Inf) [1] NaN Warning message: In sin(Inf) : NaNs produced # and this again does not > exp(NaN) [1] NaN Conceptually, I like to think that R

Joris, the point is that 'z' is NOT used as a predictor in the model. Therefore it should not affect predictions. Also, I find it suspicious that the error only occurs when the response variable conitains missings and 'z' is unique (I have tested several other cases to confirm this). -Mark Op vr 16 mrt. 2018 om 13:03 schreef Joris Meys <jorismeys at gmail.com>: >

Technically it is used as a predictor in the model. The information is contained in terms : > terms(x ~ . - z, data = d) x ~ (y + z) - z attr(,"variables") list(x, y, z) attr(,"factors") y x 0 y 1 z 0 attr(,"term.labels") [1] "y" attr(,"order") [1] 1 attr(,"intercept") [1] 1 attr(,"response") [1] 1

Dear R-developers, In the 'lm' documentation, the '-' operator is only specified to be used with -1 (to remove the intercept from the model). However, the documentation also refers to the 'formula' help file, which indicates that it is possible to subtract any term. Indeed, the following works with no problems (the period '.' stands for 'all terms except the

R and the S language that it is based on has evolved as much as it has been designed, so there are often inconsistencies due similar functionality evolving from different paths. In some cases these inconsistencies are resolved, but generally only once someone notices and care enough to do something about it. In some other cases the inconsistencies are left for historical reasons and for back

It's not a bug per se. It's the effect of removing all observations linked to a certain level in your data frame. So the output of lm() doesn't contain a coefficient for level a of z, but your new data contains that level a. With a small addition, this works again: d <- data.frame(x=rnorm(12),y=rnorm(12),z=rep(letters[1:6],2)) d$x[1] <- NA m <- lm(x ~ . -z, data=d) p <-

As a side note, Splus makes sin(x) NA, with a warning, for abs(x)>1.6*2^48 (about 4.51e+14) because more than half the digits are incorrect in sin(x) for such x. E.g., in R we get: > options(digits=16) > library(Rmpfr) > sin(4.6e14) [1] -0.792253849684354 > sin(mpfr(4.6e14, precBits=500)) 1 'mpfr' number of precision 500 bits [1]

Dear Martin, Does the work on nchar mean that bugs #16090 and #16091 will be resolved [1,2]? Thanks, Mark [1] https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16090 [2] https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16091 On Sat, Apr 25, 2015 at 11:06 PM, James Cloos <cloos at jhcloos.com> wrote: > >>>>> "GC" == G?bor Cs?rdi <csardi.gabor at

Thanks, I can now reproduce and it is a bug that is easy to fix, I will do so shortly. Fyi it can be reproduced simply by running these two lines in Rgui: list() encodeString("apple") Best Tomas On 07/17/2018 05:16 PM, Kevin Ushey wrote: > Sorry, I should have been more clear -- if I write the contents of > that script to a file called 'encoding.R' and source that,

Fixed in R-devel and R-patched, Tomas On 07/18/2018 12:03 PM, Tomas Kalibera wrote: > Thanks, I can now reproduce and it is a bug that is easy to fix, I > will do so shortly. > > Fyi it can be reproduced simply by running these two lines in Rgui: > > list() > encodeString("apple") > > Best > Tomas > > On 07/17/2018 05:16 PM, Kevin Ushey wrote:

Setting enviroment variable R_DEFAULT_DEVICE causes an error. The patch below fixes this. I guess the same goes for R_INTERACTIVE_DEVICE. --- R-2.7.0/src/library/grDevices/R/zzz.R 2008-04-27 13:49:11.000000000 +0200 +++ R-2.7.0/src/library/grDevices/R/zzz.R.new 2008-04-27 13:59:37.000000000 +0200 @@ -22,7 +22,7 @@ extras <- if(.Platform$OS.type == "windows")

'make check' fails on d-p-q-r-tests: > ##-- non central Chi^2 : > xB <- c(2000,1e6,1e50,Inf) > for(df in c(0.1, 1, 10)) + for(ncp in c(0, 1, 10, 100)) stopifnot(pchisq(xB, df=df, ncp=ncp) == 1) Error: pchisq(xB, df = df, ncp = ncp) == 1 is not all TRUE Execution halted Here is some more testing: xB <- c(2000,1e6,1e50,Inf) for(df in c(0.1, 1, 10)) for(ncp in c(0, 1,

Sorry, I should have been more clear -- if I write the contents of that script to a file called 'encoding.R' and source that, then I see the reported behavior. Here's something standalone that you should hopefully be able to copy + paste into RGui to reproduce: code <- ' x <- 1 print(list()) save(x, file = tempfile()) output <- encodeString("apple")

Hi, I have the following input file. $ cat main.txt CEL_A CELL_B 1 4 2 5 2 6 Then I run read.table in R. > f=read.table('main.txt', header=T, check.names=F, sep='\t') > head(f) \ufeffCEL_A CELL_B 1 1 4 2 2 5 3 2 6 > f$CEL_A NULL I'm not sure where the special character \ufeff comes from. Could anybody let me know what is the problem?

What is the inverse of encodeString? For example, \u1 is some Unicode symbol. If I do s <- encodeString("\u1") then s will be the string "\001". But anything I do with s, will not return the Unicode that corresponds to \u1: cat(s, "\n") # prints \001 cat("\u1", "\n") # prints y with umlaut Alberto Monteiro

Although the problem can apparently be avoided in this case. readLines causing a segfault still seems unwanted behaviour to me. I can replicate this with the example below (sessionInfo is further down): # Generate an example file l <- paste0(sample(c(letters, LETTERS), 1E6, replace = TRUE), collapse="") con <- file("test.txt", "wt") for (i in

Hello, * I am setting up a backup on a Linux system with Windows XP workstations. The backup goes to three alternating usb drives, each of which is NTFS formatted. The disks should be virtually identical but they do not seem to be. First, my mount command is this (I edited a bit for brevity) mount -t ntfs-3g -o locale=nl_NL.iso-8859-1,silent /dev/disk/by-id/usb-DiskA \ /mnt/tmp || mount -t

Gert, On 16 December 2015 at 12:06, Gert van Valkenhoef wrote: | I recently upgraded to 3.2.3 and am getting mystifying errors with my | in-development code (available at | https://github.com/gertvv/gemtc/tree/feature/regression). Every few hundred | LPs that I solve using the rcdd package will result in a SEGFAULT in the | garbage collector (address 0x10, cause 'memory not mapped') or an

I'd like to write unicode strings using the "\u" escape syntax. According to the documentation, print.default or encodeString will escape unicode using the \u convention. In practice, I can't make it work. > b="Unicode character: \ufffd" > print.default(b) [1] "Unicode character: ?" > encodeString(b) [1] "Unicode character: ?" I want to

Remember that nchar() returns by default the number of *bytes* and not the number of characters. I've recently spotted many cases in which nchar() has been used with substr() which works in characters; this can lead to incorrect results. (This seems the commonest use of nchar() in packages.) There were two reasons why nchar() was left defaulting to bytes when we allowed MBCSs in R: