While I think total compatibility is not possible or even very important I have become aware recently of some fairly low level incompatibilities that have rather serious consequences for interchange between systems. Some of these are possibly well known, but I put them on on record here just in case. (I do not expect any action on these, of course, but people may want to note them, and correct me if I'm wrong.) 1. If you need to deal with non-printable characters in S you can use numeric escape sequences such as "\001" for "^A" (control-A) and when such characters occur in dumped objects they become these numeric escapes. R neither reads nor generates numeric escape sequences, (with the possible exception of the weirdo "\300" above, which it cannot read, of course). When an object containing non-printable character components is dumped in R those characters are dumped literally, except for \007 to \015, which have alpha escape sequences: R:> ascii[8:14][1] "\a" "\b" "\t" "\n" "\v" "\f" "\r" In S only some of these alpha escape sequences are recognised or generated: S:> ascii[8:14][1] "\007" "\b" "\t" "\n" "\013" "\014" "\r" Thus "\a" reads as \007 (bel) in R but as "a" in S. Also "\007" in a dump file reads as ^G (control-G) in S, but as "007" (a 3-character string) in R. I think S has the better convention since dump files are in printable ascii and so not so susceptable to email transmission problems. R dump files should be treated as binaries and alpha encoded. Curiously S can almost read R dump files but not conversely. The place where S fails is when R generates an "\a", "\v" or "\f"; literal control characters are readable by S as well as numeric escape sequences. 2. substring(...., first = 0, ...) is not the same. R: S:> n > n[1] "" "a" "b" "c" [1] "" "a" "b" "c"> nchar(n) > nchar(n)[1] 0 1 1 1 [1] 0 1 1 1> substring(n, 0, nchar(n)) > substring(n, 0, nchar(n))[1] "@" "" "" "" [1] "" "a" "b" "c"> substring(n, 1, nchar(n)) > substring(n, 1, nchar(n))[1] "" "a" "b" "c" [1] "" "a" "b" "c" 3. Language manipulation within R seems to be impossible. I realise this may be a design limitation that nobody can do anything about, but it may be worth noting. To be more specific, the R substitute() is much more limited than the S version and coercion to mode "{", "call" or "function" are unavailable, and function objects are not subsetable. as.call is useless and as.function only exists to issue a rather tetchy error message. For example, as far as I can see it is impossible to write a version of the S function deriv() for R, short of getting down to brass tacks and writing a new primitive into the base code, but even then you can't extend it, of course. 4. I miss find() and data.dump() in R very badly, and the curiously different argument sequence for objects() is disconcerting to someone who has to use both systems. Bill -- Bill Venables, Head, Dept of Statistics, Tel.: +61 8 8303 5418 University of Adelaide, Fax.: +61 8 8303 3696 South AUSTRALIA. 5005. Email: Bill.Venables at adelaide.edu.au -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
More for the record. structure() does not coerce on one but does on the other. Consider changing a character matrix to numeric, keeping all other attributes: R: S:> x <- matrix(paste(1:9), 3, 3) > x <- matrix(paste(1:9), 3, 3) > x > x[,1] [,2] [,3] [,1] [,2] [,3] [1,] "1" "4" "7" [1,] "1" "4" "7" [2,] "2" "5" "8" [2,] "2" "5" "8" [3,] "3" "6" "9" [3,] "3" "6" "9" The obvious way fails on both systems, destroying dim attributes (which may be a feature):> as.numeric(x) > as.numeric(x)[1] 1 2 3 4 5 6 7 8 9 [1] 1 2 3 4 5 6 7 8 9 Using "mode<-" works on both:> y <- x > y <- x > mode(y) <- "numeric" > mode(y) <- "numeric" > y > y[,1] [,2] [,3] [,1] [,2] [,3] [1,] 1 4 7 [1,] 1 4 7 [2,] 2 5 8 [2,] 2 5 8 [3,] 3 6 9 [3,] 3 6 9 Using structure() fails on R (in an odd way) but works on S:> structure(x, mode="numeric") > structure(x, mode="numeric")[,1] [,2] [,3] [,1] [,2] [,3] [1,] "1" "4" "7" [1,] 1 4 7 [2,] "2" "5" "8" [2,] 2 5 8 [3,] "3" "6" "9" [3,] 3 6 9 attr(,"mode") [1] "numeric" Finally note that assigning to the `open bracket' form does a coercion on both. (This is a standard way of hanging on to dim and dimnames attributes in assignments, but it keeps "mode" as well, so can't be used for this job.)> x[] <- 0:8 > x[] <- 0:8 > x > x[,1] [,2] [,3] [,1] [,2] [,3] [1,] "0" "3" "6" [1,] "0" "3" "6" [2,] "1" "4" "7" [2,] "1" "4" "7" [3,] "2" "5" "8" [3,] "2" "5" "8"> >Bill. -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On Sun, 12 Apr 1998, Bill Venables wrote:> > 3. Language manipulation within R seems to be impossible. I > realise this may be a design limitation that nobody can do > anything about, but it may be worth noting. > > To be more specific, the R substitute() is much more limited > than the S version and coercion to mode "{", "call" or > "function" are unavailable, and function objects are not > subsetable. as.call is useless and as.function only exists to > issue a rather tetchy error message. > > For example, as far as I can see it is impossible to write a > version of the S function deriv() for R, short of getting down > to brass tacks and writing a new primitive into the base code, > but even then you can't extend it, of course.While language manipulation is much more limited than in S, you probably could write a version of deriv() (if it didn't already exist) since expressions can be manipulated quite well. eg R> a expression(sin(cos(x + 1))) R> a[[1]] sin(cos(x + 1)) R> a[[1]][[1]] sin R> a[[1]][[2]] cos(x + 1) R> a[[1]][[2]][[2]] x + 1 R> a[[1]][[2]][[2]][[1]] + R> a[[1]][[2]][[2]][[2]] x R> a[[1]][[2]][[2]][[3]] [1] 1 R> a[[1]][[1]]<-as.name("cos") R> a expression(cos(cos(x + 1))) Thomas Lumley ------------------------ Biostatistics Uni of Washington Box 357232 Seattle WA 98195-7232 ------------------------ -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Bill Venables <wvenable at attunga.stats.adelaide.edu.au> writes:> While I think total compatibility is not possible or even very > important- or desirable... Part of the incentive for R was to try to avoid some of the design problems of S, so we don't want to go to the extremes of cloning everything! We try to be compatible in little things, though, even when S seems quirky.> I think S has the better convention since dump files are in > printable ascii and so not so susceptable to email > transmission problems. R dump files should be treated as > binaries and alpha encoded.Agreed. Note however, that complete dump/restore compatibility is probably not to be expected unless the internal representation of everything is the same.> 2. substring(...., first = 0, ...) is not the same. > > R: S: > > > n > n > [1] "" "a" "b" "c" [1] "" "a" "b" "c" > > nchar(n) > nchar(n) > [1] 0 1 1 1 [1] 0 1 1 1 > > substring(n, 0, nchar(n)) > substring(n, 0, nchar(n)) > [1] "@" "" "" "" [1] "" "a" "b" "c" > > substring(n, 1, nchar(n)) > substring(n, 1, nchar(n)) > [1] "" "a" "b" "c" [1] "" "a" "b" "c"Should get fixed - or R should protest about an invalid argument. If for nothing else, then because> substring(n, -2000, nchar(n))Segmentation fault (core dumped) (Current devel. snapshot, but most likely the same in the other versions.)> 3. Language manipulation within R seems to be impossible. I > realise this may be a design limitation that nobody can do > anything about, but it may be worth noting. > > To be more specific, the R substitute() is much more limited > than the S version and coercion to mode "{", "call" or > "function" are unavailable, and function objects are not > subsetable. as.call is useless and as.function only exists to > issue a rather tetchy error message.As Thomas already noted, you can in fact do a substantial amount of expression manipulation, but some things aren't quite the same as in S. It might be useful if you could provide some examples of things that (you think) can be done in S but not in R.> 4. I miss find() and data.dump() in R very badly, and the > curiously different argument sequence for objects() is > disconcerting to someone who has to use both systems.You're not alone there, certainly. Find() is probably fairly simple to write, either as an interpreted function or by copying code from .Internal(get(...)) which needs to search along the same path anyway. Data.dump() has been on several peoples wishlist for a while - as far as I can see, it's simply an efficient representation of the output of dput(), so again most likely fairly easy, once someone finds the time to sit down with a sample dump file and do the actual coding. Objects(), however, owes some of its differences from S to the different scoping rules, so I suspect that it can never have the same semantics. We *do* need to do a better writeup on how these things works (or should work ;) ) though, some of it is currently only poorly understood by members of the core group... -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._