similar to: is.na(v)<-b (was: Re: Beginner's query - segmentation fault)

Well, that's a convincing argument, but maybe it's the name that's worrying some of us. Maybe it would be more intuitive if called set.na (sorry, I mean setNA). Also "is.na<-" cannot be used to create a new variable of NAs, so is not a universal method, which is a shame for its advocates. I note also that for a vector you can assign a new NA using either TRUE or

> -----Original Message----- > From: Richard A. O'Keefe [mailto:ok at cs.otago.ac.nz] <snip> > The very existence of an "is.na<-" which accepts a logical > vector containing FALSE as well as TRUE ... And don't forget this is not the only usage of is.na<-. In fact it is designed to take any valid indexing value. For example: > a<-1:10 >

I think the thread ended up with several people (not only me) feeling certain they didn't like `is.na<-` but with the developers defending it and me not really understanding why. Uwe Ligges was going to come up with an example of `<- NA` going wrong (sorry Brian R, I mean behaving unexpectedly), but never did, and I think the problem has been fixed. It was apparently a problem with

Try the following function (the name is supposed to be a joke, by the way), which will also do the right thing with NAs and characters. Use it as if(equal.enough(x,y)) rather than if(x==y), e.g. > equal.enough(0.1+0.2, 0.3) [1] TRUE My default of 15 significant figures may be overkill in many applications; be prepared to reduce this. Simon Fear "equal.enough" <- function(x, y,

I've searched on CRAN for axes, axis, and other terms I've already forgotten, without (re)discovering the reason for S using "non-joining" axes by default, instead of box("l"). MASS points me towards Cleveland (1993) but I don't have ready access to this any more. Could someone give me a one-liner to justify this choice to a sceptic? It's something to do

bug.report() tells me to email to r-bugs@r-project.org, whereas the Web site http://www.r-project.org/ points me to r-bugs@biostat.ku.dk. Which should I believe? Simon Fear Senior Statistician Syne qua non Ltd Tel: +44 (0) 1379 644449 Fax: +44 (0) 1379 644445 email: Simon.Fear@synequanon.com web: http://www.synequanon.com Number of attachments included with this message: 0 This

# Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # r-bugs@r-project.org # ###################################################### scan() (and so also of course read.table, read.csv etc) crashes right out of R (GUI) if it

Prompted by Peter Dalgard's recent elegant "intbin" function, I have been playing with the extension to converting reals to binary representation. The decimal part can be done like this: decbase <- function(x, n=52, base=2) { if(n) { x <- x*base paste(trunc(x), decbase(x%%1, n-1, base), sep="") } } n=52 default because that's the number of bits in

(If this only happens in Win 98, I'm sure I could live with it. Just may be helpful to report it, I hope.) Start up R GUI, then > plot(1:4,1:4) # then close manually by clicking X > plot(1:4,1:4) # ditto > methods(plot) sometimes produces normal output and even the following prompt, but then crashes immediately, or more often, crashes immediately with no output. I can do any

Dear Brian and other R-developers, I have to say that I don't understand why what I wrote should have caused any offence. A smile was what I was hoping for. You know I devote more time than I am supposed to, to support R and its users, in partial repayment of my immeasurable debt to all the Developers. It's not much, it's sometimes misguided (I later discover), and my resources

Thanks for the insight. > -----Original Message----- > From: Prof Brian Ripley [mailto:ripley at stats.ox.ac.uk] <snip> > dots <- list(...) > haveYlim <- "ylim" %in% names(dots) > > is the sort of thing we still understand 5 years later. > I didn't say "understand", I said "easily follow". Obviously how "easily" is

Tony, I don't understand what you mean. Could you give an example? > -----Original Message----- > From: Tony Plate [mailto:tplate at blackmesacapital.com] > > ... I'm not saying "never write functions that use ...", > >I'm just saying "never write functions that depend on a particular > >argument being passed via ...". > > Several

The following code works, to gsub single quotes to double quotes: line <- gsub("'", '"', line) (that's a single quote within doubles then a double within singles if your viewer's font is not good). But The R Language Manual tells me that Quotes and other special characters within strings are specified using escape sequences: \' single quote \"

How can I best achieve the following (works in Splus): filenames <- dos("dir *.sasb7dat /b") What I am asking, more generically, is: how can I capture the output of a DOS command in R? I have tried using system("COMMAND.COM /c dir /b", intern=T, show.output.on.console=T) where intern: a logical, indicates whether to make the output of the command an R

I tried to define a function like: fnx <- function(x, by.vars=Month) print(by(x, by.vars, summary)) But this doesn't work (does not find x$Month; unlike other functions, such as subset(), the INDICES argument to "by" does not look for variables in dataset x. Is fully documented, but I forget every time). So I tried using "with": fnxx <- function(x, by.vars=Month)

There have been various elegant solutions to test for the presence of a particular named parameter within a ... argument, such as if (!is.null(list(...)$ylim)) if ("ylim" %in% names(list(...))) I think I'd have to comment these lines pretty clearly if I wanted to easily follow the code in 6 months time. But I'm still not convinced it is ever a good idea to use this technique

I think one needs an LU decomposition rather than QR. However, I couldn't find anything off the shelf to do an LU, other than learning that determinant() now uses LU instead of QR or SVD, so the code to do it must be in there for those that want it. You'll probably need to divide rows of U by the first entry if you insist on the unique reduced REF. However, I can't see any reason

Concerning x[i] <- NA vs is.na(x[i]) <- TRUE Brian Ripley wrote: I don't think it can ever `go wrong', but it can do things other than the user intends. If the user writes x[i] <- NA, the user has clearly indicated his intention that the i element(s) of x should become NA. There isn't any clearer way to say that. The only way it could ever do something "other

I am puzzled by the advice to use is.na(x) <- TRUE instead of x <- NA. ?NA says Function `is.na<-' may provide a safer way to set missingness. It behaves differently for factors, for example. However, "MAY provide" is a bit scary, and it doesn't say WHAT the difference in behaviour is. I must say that "is.na(x) <- ..." is rather repugnant,

For reasons which I'll spare you, I'm writing a program to analyse R source code. This has led me to probe some of the darker corners of R syntax to find out what is supposed to happen. Now, from reading the R documentation (and the New S book &c) I know perfectly well that f(a, b, etc) <- x is supposed to turn into a <- "f<-"(a, b, etc, value=x) Except,