Dear R Folks,
I'm a big fan of R, but there are a couple of things
that repeatedly annoy me, and I wondered if anyone
has neat ways to deal with them.
(a) When using "apply" row-wise to a matrix, it returns
the results column-wise, and to preserve the original
orientation, I've to do a transpose. E.g. I've to keep
doing a transpose, which I consider to be quite annoying.
transformed.mtx <- t(apply( mtx, 1, exp))
(b) When extracting 2 or more columns of a matrix,
R returns the result as a matrix, BUT when extracting
just one column, it returns a vector/array, rather than
a matrix, so I've to keep doing as.matrix, which is annoying.
sub.mtx <- as.matrix(mtx[,1])
Of course I could write a suitable function
cols <- function(mtx,range) as.matrix(mtx[, range])
but then I lose the syntactic sugar of being able to say "[,1]".
On Thu, 19 May 2005, Chalasani, Prasad wrote:> (b) When extracting 2 or more columns of a matrix, > R returns the result as a matrix, BUT when extracting > just one column, it returns a vector/array, rather than > a matrix, so I've to keep doing as.matrix, which is annoying. > > sub.mtx <- as.matrix(mtx[,1]) > > Of course I could write a suitable function > cols <- function(mtx,range) as.matrix(mtx[, range]) > but then I lose the syntactic sugar of being able to say "[,1]".This one is actually a FAQ, mtx[,1,drop=FALSE] -thomas
(a) If what you're trying to do is just apply exp, or any other element-wise
function, you can just say "exp(mtx)". You avoid both
"apply" and the
transpose, and save time in the bargain. If your actual function really
does depend on multiple elements, it may be a little more complicated. You
could conceivably write a "myapply" function to do the apply followed
by the
transpose, but then of course you still need to keep track of which way
you're going.
(b) You want to look into the "drop = FALSE" option:
Sub.mtx <- mtx[,1,drop = FALSE]
Hope this helps,
Matt Wiener
-----Original Message-----
From: r-help-bounces at stat.math.ethz.ch
[mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Chalasani, Prasad
Sent: Thursday, May 19, 2005 10:37 AM
To: r-help at stat.math.ethz.ch
Subject: [R] R annoyances
Dear R Folks,
I'm a big fan of R, but there are a couple of things
that repeatedly annoy me, and I wondered if anyone
has neat ways to deal with them.
(a) When using "apply" row-wise to a matrix, it returns
the results column-wise, and to preserve the original
orientation, I've to do a transpose. E.g. I've to keep
doing a transpose, which I consider to be quite annoying.
transformed.mtx <- t(apply( mtx, 1, exp))
(b) When extracting 2 or more columns of a matrix,
R returns the result as a matrix, BUT when extracting
just one column, it returns a vector/array, rather than
a matrix, so I've to keep doing as.matrix, which is annoying.
sub.mtx <- as.matrix(mtx[,1])
Of course I could write a suitable function
cols <- function(mtx,range) as.matrix(mtx[, range])
but then I lose the syntactic sugar of being able to say "[,1]".
______________________________________________
R-help at stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide!
http://www.R-project.org/posting-guide.html
Chalasani, Prasad wrote:> Dear R Folks, > I'm a big fan of R, but there are a couple of things > that repeatedly annoy me, and I wondered if anyone > has neat ways to deal with them. > > (a) When using "apply" row-wise to a matrix, it returns > the results column-wise, and to preserve the original > orientation, I've to do a transpose. E.g. I've to keep > doing a transpose, which I consider to be quite annoying. > > transformed.mtx <- t(apply( mtx, 1, exp))I'd rather type exp(mtx)> (b) When extracting 2 or more columns of a matrix, > R returns the result as a matrix, BUT when extracting > just one column, it returns a vector/array, rather than > a matrix, so I've to keep doing as.matrix, which is annoying. > > sub.mtx <- as.matrix(mtx[,1]) > > Of course I could write a suitable function > cols <- function(mtx,range) as.matrix(mtx[, range]) > but then I lose the syntactic sugar of being able to say "[,1]".The docs suggest: mtx[ , 1, drop = FALSE] Uwe Ligges> ______________________________________________ > R-help at stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Thanks all for pointing out that I can use mtx[,1,drop=F] -----Original Message----- From: Uwe Ligges [mailto:ligges at statistik.uni-dortmund.de] Sent: Thursday, May 19, 2005 10:49 AM To: Chalasani, Prasad Cc: r-help at stat.math.ethz.ch Subject: Re: [R] R annoyances Chalasani, Prasad wrote:> Dear R Folks, > I'm a big fan of R, but there are a couple of things > that repeatedly annoy me, and I wondered if anyone > has neat ways to deal with them. > > (a) When using "apply" row-wise to a matrix, it returns > the results column-wise, and to preserve the original > orientation, I've to do a transpose. E.g. I've to keep > doing a transpose, which I consider to be quite annoying. > > transformed.mtx <- t(apply( mtx, 1, exp))I'd rather type exp(mtx)> (b) When extracting 2 or more columns of a matrix, > R returns the result as a matrix, BUT when extracting > just one column, it returns a vector/array, rather than > a matrix, so I've to keep doing as.matrix, which is annoying. > > sub.mtx <- as.matrix(mtx[,1]) > > Of course I could write a suitable function > cols <- function(mtx,range) as.matrix(mtx[, range]) > but then I lose the syntactic sugar of being able to say "[,1]".The docs suggest: mtx[ , 1, drop = FALSE] Uwe Ligges> ______________________________________________ > R-help at stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! > http://www.R-project.org/posting-guide.html
I think the flaw in this reasoning is that programmers are not considered users. IMO, making a better language is beneficial for users. I am now watching how a new colleague of mine, a very good C++ programmer turning into a data miner, is struggling w/ many "irregularities" of R.> -----Original Message----- > From: r-help-bounces at stat.math.ethz.ch > [mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Thomas Lumley > Sent: Thursday, May 19, 2005 9:39 AM > To: Rod Montgomery > Cc: r-help at stat.math.ethz.ch > Subject: Re: [R] R annoyances > > On Thu, 19 May 2005, Rod Montgomery wrote: > > Thomas Lumley wrote: > >> This one is actually a FAQ, > >> mtx[,1,drop=FALSE] > >> > >> -thomas > >> > > I wonder whether there is, or should be, a way to set FALSE > as the default? > > > > There shouldn't be (apart from editing the code), because you > really don't want something this basic to be unpredictable. > > There have been discussions at several times about whether > drop=FALSE or drop=TRUE should be the default. The decision > has always been that programmers can cope either way, but > that users probably don't expect mtx[,1] to be a vector, and > that they definitely don't expect mtx[1,1] to be a matrix. > > -thomas > > ______________________________________________ > R-help at stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! > http://www.R-project.org/posting-guide.html >
I guess it depends on what kind of data analysis one does. R is designed and best suited for the analysis that starts with a data frame which fits in 1/10th of your computer RAM. R programming is then mostly limited to writing small convenience functions for better presentation, visualization, etc. Or alternatively one implements a new fitting procedure/algorithm and applies it to the data. Now things begin to look harder when you have 200G of data and 8G of RAM and still need to find "structure" in the data. You need to pre-process the data, recover from *unexpected* failures, store and retrieve intermediate data sets, etc. This requires qualities of a good general-purpose programming language. Note, we do not use R to program a system, we do data analysis so we should be considered R *users*. In my view, and the experience of the colleague of my confirms it, R has a long way to go to become a wrinkle-free general purpose language. To your specific question, why good (C++) programmers should not struggle with R? Because they have the skills to plan sizeable programs in any wrinkle-free language. Hope this makes my earier comments more clear, Vadim> -----Original Message----- > From: Berton Gunter [mailto:gunter.berton at gene.com] > Sent: Thursday, May 19, 2005 10:55 AM > To: Vadim Ogranovich; 'Thomas Lumley'; 'Rod Montgomery' > Cc: r-help at stat.math.ethz.ch > Subject: RE: [R] R annoyances > > Vadim et.al: > > I do not care to comment one way or the other about R's > "irregularities.' > But I am puzzled by your statement that a "good C++ > programmer is struggling with R." Why should they not > struggle?! R is primarily a language for data analysis, > statistics, and graphics. I do not understand why someone who is a > C++ programmer would be expected to have the knowledge and > experience to > C++ be > a "data miner" and would not therefore struggle to deal with > the statistical and data analysis issues that are > deliberately at the heart of many of R's programming conventions. > > Is there something here that I am missing, or is this yet > another example of Frank Harrell's "instant brain surgeon" commentary? > > -- Bert Gunter > Genentech Non-Clinical Statistics > South San Francisco, CA > > "The business of the statistician is to catalyze the > scientific learning process." - George E. P. Box > > > > > -----Original Message----- > > From: r-help-bounces at stat.math.ethz.ch > > [mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Vadim > > Ogranovich > > Sent: Thursday, May 19, 2005 10:40 AM > > To: Thomas Lumley; Rod Montgomery > > Cc: r-help at stat.math.ethz.ch > > Subject: RE: [R] R annoyances > > > > I think the flaw in this reasoning is that programmers are not > > considered users. IMO, making a better language is beneficial for > > users. > > > > I am now watching how a new colleague of mine, a very good C++ > > programmer turning into a data miner, is struggling w/ many > > "irregularities" of R. > > > > > -----Original Message----- > > > From: r-help-bounces at stat.math.ethz.ch > > > [mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of > Thomas Lumley > > > Sent: Thursday, May 19, 2005 9:39 AM > > > To: Rod Montgomery > > > Cc: r-help at stat.math.ethz.ch > > > Subject: Re: [R] R annoyances > > > > > > On Thu, 19 May 2005, Rod Montgomery wrote: > > > > Thomas Lumley wrote: > > > >> This one is actually a FAQ, > > > >> mtx[,1,drop=FALSE] > > > >> > > > >> -thomas > > > >> > > > > I wonder whether there is, or should be, a way to set FALSE > > > as the default? > > > > > > > > > > There shouldn't be (apart from editing the code), because > you really > > > don't want something this basic to be unpredictable. > > > > > > There have been discussions at several times about whether > > > drop=FALSE or drop=TRUE should be the default. The decision has > > > always been that programmers can cope either way, but that users > > > probably don't expect mtx[,1] to be a vector, and that they > > > definitely don't expect mtx[1,1] to be a matrix. > > > > > > -thomas > > > > > > ______________________________________________ > > > R-help at stat.math.ethz.ch mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-help > > > PLEASE do read the posting guide! > > > http://www.R-project.org/posting-guide.html > > > > > > > ______________________________________________ > > R-help at stat.math.ethz.ch mailing list > > https://stat.ethz.ch/mailman/listinfo/r-help > > PLEASE do read the posting guide! > > http://www.R-project.org/posting-guide.html > > > > >
Dear Jan, Since you can use variables named c, q, or t in any event, I don't see why the existence of functions with these names is much of an impediment. The problem that I see with T and F is that allowing them to be redefined sets a trap for people. If R wants to discourage use of T and F for TRUE and FALSE, then why provide standard global variables by these names? On the other hand, if providing T and F is considered desirable (e.g., for S-PLUS compatibility), then why not make them reserved names? Regards, John -------------------------------- John Fox Department of Sociology McMaster University Hamilton, Ontario Canada L8S 4M4 905-525-9140x23604 http://socserv.mcmaster.ca/jfox --------------------------------> -----Original Message----- > From: Jan T. Kim [mailto:jtk at cmp.uea.ac.uk] > Sent: Thursday, May 19, 2005 12:22 PM > To: John Fox > Subject: Re: [R] R annoyances > > On Thu, May 19, 2005 at 11:55:22AM -0400, John Fox wrote: > > Dear Uwe, > > > > I've often wondered why T and F aren't reserved words in R > as TRUE and > > FALSE are. Perhaps there's some use of T and F as > variables, but that > > seems ill-advised. > > Personally, I'd rather argue the other way around: Reserved > words should be words that should be more unique and > expressive than just a single letter. > > In fact, I've found it slightly irritating at times that c, q > and t are functions in the base package, as I'm somewhat > prone to use all of these as local variable names... > > Best regards, Jan > -- > +- Jan T. Kim > -------------------------------------------------------+ > | *NEW* email: jtk at cmp.uea.ac.uk > | > | *NEW* WWW: http://www.cmp.uea.ac.uk/people/jtk > | > *-----=< hierarchical systems are for files, not for humans > >=-----*
(a) There is 'stable.apply' in S Poetry that looks to me like it should work in R, but I haven't tested it. Patrick Burns Burns Statistics patrick at burns-stat.com +44 (0)20 8525 0696 http://www.burns-stat.com (home of S Poetry and "A Guide for the Unwilling S User") Chalasani, Prasad wrote:>Dear R Folks, >I'm a big fan of R, but there are a couple of things >that repeatedly annoy me, and I wondered if anyone >has neat ways to deal with them. > >(a) When using "apply" row-wise to a matrix, it returns > the results column-wise, and to preserve the original > orientation, I've to do a transpose. E.g. I've to keep > doing a transpose, which I consider to be quite annoying. > > transformed.mtx <- t(apply( mtx, 1, exp)) > >(b) When extracting 2 or more columns of a matrix, > R returns the result as a matrix, BUT when extracting > just one column, it returns a vector/array, rather than > a matrix, so I've to keep doing as.matrix, which is annoying. > > sub.mtx <- as.matrix(mtx[,1]) > > Of course I could write a suitable function > cols <- function(mtx,range) as.matrix(mtx[, range]) > but then I lose the syntactic sugar of being able to say "[,1]". > >______________________________________________ >R-help at stat.math.ethz.ch mailing list >https://stat.ethz.ch/mailman/listinfo/r-help >PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html > > > > >
> From: Vadim Ogranovich > > I guess it depends on what kind of data analysis one does. R > is designed > and best suited for the analysis that starts with a data frame which > fits in 1/10th of your computer RAM. R programming is then mostly > limited to writing small convenience functions for better > presentation, > visualization, etc. Or alternatively one implements a new fitting > procedure/algorithm and applies it to the data. > > Now things begin to look harder when you have 200G of data > and 8G of RAM > and still need to find "structure" in the data. You need to > pre-process > the data, recover from *unexpected* failures, store and retrieve > intermediate data sets, etc. This requires qualities of a good > general-purpose programming language. Note, we do not use R > to program a > system, we do data analysis so we should be considered R *users*. > In my view, and the experience of the colleague of my > confirms it, R has > a long way to go to become a wrinkle-free general purpose language. > > To your specific question, why good (C++) programmers should not > struggle with R? Because they have the skills to plan > sizeable programs > in any wrinkle-free language.Could you please define "wrinkle-free language", or give an (some?) example? Andy> Hope this makes my earier comments more clear, > Vadim > > > -----Original Message----- > > From: Berton Gunter [mailto:gunter.berton at gene.com] > > Sent: Thursday, May 19, 2005 10:55 AM > > To: Vadim Ogranovich; 'Thomas Lumley'; 'Rod Montgomery' > > Cc: r-help at stat.math.ethz.ch > > Subject: RE: [R] R annoyances > > > > Vadim et.al: > > > > I do not care to comment one way or the other about R's > > "irregularities.' > > But I am puzzled by your statement that a "good C++ > > programmer is struggling with R." Why should they not > > struggle?! R is primarily a language for data analysis, > > statistics, and graphics. I do not understand why someone who is a > > C++ programmer would be expected to have the knowledge and > > experience to > > C++ be > > a "data miner" and would not therefore struggle to deal with > > the statistical and data analysis issues that are > > deliberately at the heart of many of R's programming conventions. > > > > Is there something here that I am missing, or is this yet > > another example of Frank Harrell's "instant brain surgeon" > commentary? > > > > -- Bert Gunter > > Genentech Non-Clinical Statistics > > South San Francisco, CA > > > > "The business of the statistician is to catalyze the > > scientific learning process." - George E. P. Box > > > > > > > > > -----Original Message----- > > > From: r-help-bounces at stat.math.ethz.ch > > > [mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Vadim > > > Ogranovich > > > Sent: Thursday, May 19, 2005 10:40 AM > > > To: Thomas Lumley; Rod Montgomery > > > Cc: r-help at stat.math.ethz.ch > > > Subject: RE: [R] R annoyances > > > > > > I think the flaw in this reasoning is that programmers are not > > > considered users. IMO, making a better language is beneficial for > > > users. > > > > > > I am now watching how a new colleague of mine, a very good C++ > > > programmer turning into a data miner, is struggling w/ many > > > "irregularities" of R. > > > > > > > -----Original Message----- > > > > From: r-help-bounces at stat.math.ethz.ch > > > > [mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of > > Thomas Lumley > > > > Sent: Thursday, May 19, 2005 9:39 AM > > > > To: Rod Montgomery > > > > Cc: r-help at stat.math.ethz.ch > > > > Subject: Re: [R] R annoyances > > > > > > > > On Thu, 19 May 2005, Rod Montgomery wrote: > > > > > Thomas Lumley wrote: > > > > >> This one is actually a FAQ, > > > > >> mtx[,1,drop=FALSE] > > > > >> > > > > >> -thomas > > > > >> > > > > > I wonder whether there is, or should be, a way to set FALSE > > > > as the default? > > > > > > > > > > > > > There shouldn't be (apart from editing the code), because > > you really > > > > don't want something this basic to be unpredictable. > > > > > > > > There have been discussions at several times about whether > > > > drop=FALSE or drop=TRUE should be the default. The decision has > > > > always been that programmers can cope either way, but > that users > > > > probably don't expect mtx[,1] to be a vector, and that they > > > > definitely don't expect mtx[1,1] to be a matrix. > > > > > > > > -thomas > > > > > > > > ______________________________________________ > > > > R-help at stat.math.ethz.ch mailing list > > > > https://stat.ethz.ch/mailman/listinfo/r-help > > > > PLEASE do read the posting guide! > > > > http://www.R-project.org/posting-guide.html > > > > > > > > > > ______________________________________________ > > > R-help at stat.math.ethz.ch mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-help > > > PLEASE do read the posting guide! > > > http://www.R-project.org/posting-guide.html > > > > > > > > > > > ______________________________________________ > R-help at stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! > http://www.R-project.org/posting-guide.html > > >
> From: Robin Hankin > > On May 20, 2005, at 11:00 am, Jan T. Kim wrote: > > > On Thu, May 19, 2005 at 03:10:53PM -0400, John Fox wrote: > > > >> Since you can use variables named c, q, or t in any event, I don't > >> see why > >> the existence of functions with these names is much of an > impediment. > > > > True, particularly since I'm not too likely to use these > variables for > > (local) > > functions, and variables of other types don't prevent > functions from > > working. > > (I thought this was a problem... I must be spoilt by > recently having > > to read > > too much Matlab code, where parentheses are used to both enclose > > subscripts and > > parameter lists, thus rendering subscript expressions and function > > calls > > syntactically indistinguishable.) > > > Heh, I'm a recovering Matlab user too. This is sooooooooooo true! > > In Matlab: > > f(10) # function f() evaluated at 10 > f(10) # 10th element of vector f. confusing!! > > R uses round brackets in two unrelated ways: > > 4*(1+2) --- using "(" and ")" to signify grouping > f(8) function f() evaluated at 8. > > where there is no reason to use the same parenthesis symbol for both > tasks.The same is done in Fortran/C/C++/Java/Python and God knows how many others...> IMO, the only system with consistent parenthesis use is Mathematica; > > f[10] # function f[] evaluated at 10 > 8*(2+2) # parenthesis to override order of operations > f[[3]] # third element of list f > > {} are used for sets.Just out of curiosity, what's used for grouping expressions? Andy> > > -- > Robin Hankin > Uncertainty Analyst > National Oceanography Centre, Southampton > European Way, Southampton SO14 3ZH, UK > tel 023-8059-7743 > > ______________________________________________ > R-help at stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! > http://www.R-project.org/posting-guide.html > > >
On 20-May-05 Uwe Ligges wrote:> All possible changes to T/F (both removing the meaning of > TRUE/FALSE in a clean session and making them reserved words) > would break code of lots of users.Just wanted to point out that there's another (darker) side to this: code that produces bad results without the users even realizing it. Personally, I would clearly prefer lots of broken code to mistakes caused by T/TRUE and F/FALSE. Hypothetically, if whatever=T/F were forbidden and only whatever=TRUE/FALSE were allowed, all the code could be fixed with a simple sed script: for F in `ls *.r` do mv $F $F.$$ sed -e 's/=T,/=TRUE,/g' -e 's/=F,/=FALSE,/g' -e 's/=T)/=TRUE)/g' -e 's/=F)/=FALSE)/g' $F.$$ > $F rm $F.$$ done -----Original Message----- From: Uwe Ligges [mailto:ligges at statistik.uni-dortmund.de] Sent: Friday, May 20, 2005 2:39 AM To: John Fox Cc: r-help at stat.math.ethz.ch Subject: Re: [R] R annoyances Dear John, I have not expected to cause that many traffic and largish discussion. What I tried to point out is that: - a "programmer" should know that one has to use TRUE / FALSE in code in order to make it work generaly which is also checked by R CMD check. - a "user" simply typing some lines in order to look at the data can shortly write T or F instead. where "programmer" and "user" are not well defined and probably undistinguishable according to Chambers (1998). I'd call people using [..., drop=FALSE] "programmer" here, since the code is probably used inside functions. S-PLUS compatibility (T/F) has to be considered as well. All possible changes to T/F (both removing the meaning of TRUE/FALSE in a clean session and making them reserved words) would break code of lots of users. With a common amount of statistical uncertainty I think it might be too late for changes ... Best, Uwe John Fox wrote:> Dear Uwe, > > I've often wondered why T and F aren't reserved words in R as TRUE and FALSE > are. Perhaps there's some use of T and F as variables, but that seems > ill-advised. > > Regards, > John > > -------------------------------- > John Fox > Department of Sociology > McMaster University > Hamilton, Ontario > Canada L8S 4M4 > 905-525-9140x23604 > http://socserv.mcmaster.ca/jfox > -------------------------------- > > >>-----Original Message----- >>From: r-help-bounces at stat.math.ethz.ch >>[mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Uwe Ligges >>Sent: Thursday, May 19, 2005 10:08 AM >>To: Chalasani, Prasad >>Cc: r-help at stat.math.ethz.ch >>Subject: Re: [R] R annoyances >> >>Chalasani, Prasad wrote: >> >> >>>Thanks all for pointing out that I can use >>> mtx[,1,drop=F] >> >> >>Which, for example, won't work for >> F <- 10.25 >> >>---> drop=FALSE ! >> ^^^^^ >> >>Uwe Ligges >> >> >> >>
> From: Philippe Grosjean > > Hello, > Regarding use of parenthesis, it is true that R is much better with > f(10) != f[10] != f[[10]], where Matlab is a little > confusing. Also, in > Matlab, you can use some functions without (), further adding to the > confusion (the only example that comes to my mind in R is the > use of '?' > as shortcut for help()). > > However, there is still a double use of () in R: it is both used for > enclosing function arguments and for grouping operations. One > language > has a syntax that makes a totally unambiguous use of [], () and {} is > Mathematica: [] is for subscript, {} is for function > arguments and () is > for grouping... but Mathematica code is really a pain to > typeset and read. > > So, all in all, I really like the S langage syntax: it is > very readable > and reasonably rigid... > > Regarding T and F, I took the habit to *always* type them > TRUE or FALSE. > Again, very readable and not confusing at all. If T and F as > equivalent > to TRUE and FALSE would ever be deprecated and then defunct > in further > versions of R, well, I would not complain about it! > > The only aspect I don't like is a too loosely use of the dot in > functions: both in functions names, in object classes and in generic > functions / methods. Hence, we have for instance: 'data.frame', > 'help.search' and 'summary.matrix'... just guess which one is > an object > class, which one is an ordinary function and which one is a S3 method > (OK, S4 solves somehow the problem)? It would have been much > better to > *reserve* the use of a dot in a function name as a separator > between the > name of the generic function and the class to which it applies. Thus, > 'summary.matrix' would have been correct, but both 'data.frame' and > 'help.search' should have been spelled differently, perhaps > 'dataframe' > and 'helpSearch'. Just a dream... because 'data.frame' will of course > never be spelled differently!!!Don't give up to easily: If "_" can be done away as assignment operator, I'd guess anything is fair game... Andy> Best, > > Philippe Grosjean > > > Jan T. Kim wrote: > > On Fri, May 20, 2005 at 08:14:24AM -0400, Liaw, Andy wrote: > > > >>>From: Robin Hankin > >>> > >>>On May 20, 2005, at 11:00 am, Jan T. Kim wrote: > >>> > >>> > >>>>On Thu, May 19, 2005 at 03:10:53PM -0400, John Fox wrote: > >>>> > >>>> > >>>>>Since you can use variables named c, q, or t in any > event, I don't > >>>>>see why > >>>>>the existence of functions with these names is much of an > >>> > >>>impediment. > >>> > >>>>True, particularly since I'm not too likely to use these > >>> > >>>variables for > >>> > >>>>(local) > >>>>functions, and variables of other types don't prevent > >>> > >>>functions from > >>> > >>>>working. > >>>>(I thought this was a problem... I must be spoilt by > >>> > >>>recently having > >>> > >>>>to read > >>>>too much Matlab code, where parentheses are used to both enclose > >>>>subscripts and > >>>>parameter lists, thus rendering subscript expressions and > function > >>>>calls > >>>>syntactically indistinguishable.) > >>> > >>> > >>>Heh, I'm a recovering Matlab user too. This is sooooooooooo true! > >>> > >>>In Matlab: > >>> > >>>f(10) # function f() evaluated at 10 > >>>f(10) # 10th element of vector f. confusing!! > >>> > >>>R uses round brackets in two unrelated ways: > >>> > >>> 4*(1+2) --- using "(" and ")" to signify grouping > >>>f(8) function f() evaluated at 8. > >>> > >>>where there is no reason to use the same parenthesis > symbol for both > >>>tasks. > >> > >>The same is done in Fortran/C/C++/Java/Python and God knows how many > >>others... > > > > > > And this is different from the subscripting / function call > ambiguity, > > as these languages (to the extent I know them) are designed > such that > > parentheses for precedence control are syntactically distinguishable > > from those used for function parameter lists: If the > opening parenthesis > > is preceded by an identifier, that identifier is a function name and > > the parenthesis opens a parameter list. > > > > (Python is a somewhat messy case, though, because it uses > parentheses > > for tuples too.) > > > > Best regards, Jan > > >
On Friday, May 20, 2005 11:29 AM, Jari Oksanen wrote:> The most beautiful thing in old R (I started with 0.63) was > that it was > in the elegant unix tradition: all lower case and point (full stop, > period, whatever) in places where you needed it. It is > unfortunate that > other languages are creeping in and old neat constructions > are replaces > with C++ style uGliNess. There was a grace period when switching from > beautiful (fair) print.coefmat to ugLy printCoefmat, but some changes > were more abrupt (package.description). I have a feeling that the > recent trashing of names.dist (with a lot of code breakage > even in base > R) was caused by the same kind of political correctness. > > Please Mr R, keep it like it used to be...BecauseIt'sFridayI'llJoinIntoThisTiredOldDebate.TheUseOfMixedCase UglinessToDistinguishBetween"Words"InObjectNamesIsIndeedAn Abomination. It_is_much_easier,_and_demonstrably_so_I_would_say,_to_use some_kind_of_real_separator_between_"words." S.and.R.have.historically.encouraged.a.different.separator than.most.other.languages,.but.the.principle.is.the.same. And the double benefit is that it leaves case available for other good uses, such as indicating an object's scope: local.var Class.Data GLOBAL.SETTING --Todd -- Z. Todd Taylor Senior Development Engineer Pacific Northwest National Laboratory Why is it "after dark," not "after light"?
Bogdan Romocea <br44114 at gmail.com> wrote:> Hypothetically, if whatever=T/F were forbidden and only > whatever=TRUE/FALSE were allowed, all the code could be fixed with > a simple sed script: [deleted]As Bogdan is lobbying hard for disallowing T/F, I wanted to speak up for the other side. Please leave T/F as they are, simple and clean! C'mon people, just don't use T or F as variables, how hard is that??? -- David Brahm (brahm at alum.mit.edu)