similar to: apologies (was RE: [R] ISOdate() and strptime())

Thanks for this clarification. I have learned in the meantime that it is necessary to be very careful when using all these POSIX things. As another example, here is something that made me scratch my head just yesterday: When I create a sequence of days that happens to start before and ends in daylight savings time, I seem to lose a day: > seq(from = strptime("20030329",

Dear R-people! I am using R 1.8.0, under Windows XP. While using ISOdate() and strptime(), I noticed the following behaviour when "wrong" arguments (e.g., months>12) are given to these functions: > ISOdate(year=2003,month=2,day=20) #ok [1] "2003-02-20 13:00:00 Westeurop?ische Normalzeit" > ISOdate(year=2003,month=2,day=30) #wrong day, but returns a value [1]

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

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

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,

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

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

Note this behaviour: > a<-"a" > a<-NA > mode(a) [1] "logical" > a<-"a" > is.na(a) <- T > mode(a) [1] "character" However after either way of assigning NA to a, is.na(a) is true, and it prints as NA, so I can't see it's ever likely to matter. [Why do I say these things? Expect usual flood of examples where it does

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 >

# 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

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

(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

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 \"

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

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 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

Dear all, I have found the following (for me) incomprehensible behaviour of ISOdate (POSIXct): > ISOdate(1900,6,16) [1] "1900-06-15 14:00:00 Westeurop?ische Sommerzeit" > ISOdate(1950,6,16) [1] "1950-06-16 14:00:00 Westeurop?ische Sommerzeit" Note that in the first case I get the 15th of June back, not the 16th as I would have expected! This happened under R-1.7.1 on