Mark.Bravington@csiro.au
2002-Dec-10 06:29 UTC
[Rd] names<- bug, and incompatibility with c() (PR#2358)
When assigning names to particular elements of hitherto-unnamed vectors, there is inconsistent behaviour depending on whether the element being named is the last one: test> mm <- 1:3 test> names( mm)[1] <- 'y' Error in "names<-.default"(*tmp*, value = "y") : names attribute must be the same length as the vector test> names( mm)[2] <- 'y' Error in "names<-.default"(*tmp*, value = "y") : names attribute must be the same length as the vector test> names( mm)[3] <- 'y' test> mm <NA> <NA> y 1 2 3 As long as the last element of mm gets mentioned, R will allow the operation, filling in any blanks with NA-strings. But if the last element of mm isn't specified somewhere in the vector of things-to-be-named, R won't allow the operation. If mm already has names, there's no problem. The usage above is sometimes valuable, and it should be easy to fix it, by supplying default names in all other positions. But there is also some inconsistency with the use of "c": should default names be NA-strings, or empty strings? test> mm <- 1:2 test> names( mm)[2] <- 'y' test> mm <NA> y 1 2 test> mm <- c( mm, 3) test> mm NA y 1 2 3 test> names( mm)[1] [1] "NA" test> Note that "c" has supplied an empty string for the unspecified name, and has also taken the liberty of changing the special NA-string into a "NA" (i.e. a 2-character string, first letter N, second letter A)! An easy way to achieve consistency, would be to make unsupplied names should always default to an empty string, rather than a special NA-string. cheers Mark --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 1 minor = 6.1 year = 2002 month = 11 day = 01 language = R Windows 2000 Professional (build 2195) Service Pack 2.0 Search Path: .GlobalEnv, ROOT, package:handy, package:debug, mvb.session.info, package:mvbutils, package:tcltk, Autoloads, package:base
ripley@stats.ox.ac.uk
2002-Dec-10 12:41 UTC
[Rd] names<- bug, and incompatibility with c() (PR#2358)
This is S-compatible, though, and it I think it is quite legitimately an error. I will fix it in R-devel, but I am little concerned that advanced users may be surprised (but they probably would never do this).> there is inconsistent behaviour depending on whether the element being named > is the last one: > > test> mm <- 1:3 > test> names( mm)[1] <- 'y' > Error in "names<-.default"(*tmp*, value = "y") : > names attribute must be the same length as the vector > test> names( mm)[2] <- 'y' > Error in "names<-.default"(*tmp*, value = "y") : > names attribute must be the same length as the vector > test> names( mm)[3] <- 'y' > test> mm > <NA> <NA> y > 1 2 3 > > As long as the last element of mm gets mentioned, R will allow the > operation, filling in any blanks with NA-strings. But if the last element of > mm isn't specified somewhere in the vector of things-to-be-named, R won't > allow the operation. > > If mm already has names, there's no problem. > > The usage above is sometimes valuable, and it should be easy to fix it, by > supplying default names in all other positions. But there is also some > inconsistency with the use of "c": should default names be NA-strings, or > empty strings?They should now be NA-strings.> test> mm <- 1:2 > test> names( mm)[2] <- 'y' > test> mm > <NA> y > 1 2 > test> mm <- c( mm, 3) > test> mm > NA y > 1 2 3 > test> names( mm)[1] > [1] "NA" > test> > > Note that "c" has supplied an empty string for the unspecified name, and > has also taken the liberty of changing the special NA-string into a "NA" > (i.e. a 2-character string, first letter N, second letter A)!That's a bug.> An easy way to achieve consistency, would be to make unsupplied names should > always default to an empty string, rather than a special NA-string.But what's the point of having a special string then? -- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595
Mark.Bravington@csiro.au
2002-Dec-10 23:32 UTC
[Rd] names<- bug, and incompatibility with c() (PR#2358)
#> From: Mark.Bravington@csiro.au #> When assigning names to parts of an hitherto-unnamed vector, #> there is inconsistent behaviour depending on whether the #element being named #> is the last one: #> #> test> mm <- 1:3 #> test> names( mm)[1] <- 'y' #> Error in "names<-.default"(*tmp*, value = "y") : #> names attribute must be the same length as the vector #> test> names( mm)[2] <- 'y' #> Error in "names<-.default"(*tmp*, value = "y") : #> names attribute must be the same length as the vector #> test> names( mm)[3] <- 'y' #> test> mm #> <NA> <NA> y #> 1 2 3 #From: ripley@stats.ox.ac.uk [mailto:ripley@stats.ox.ac.uk] #Subject: Re: [Rd] names<- bug, and incompatibility with c() (PR#2358) # # #This is S-compatible, though, and it I think it is quite legitimately #an error. I will fix it in R-devel, but I am little concerned that #advanced users may be surprised (but they probably would never #do this). don't be so sure! The "names" attribute can be useful for many things besides the obvious-- "There are more things in heaven and earth, Horatio,..." ;) #> Note that "c" has supplied an empty string for the #unspecified name, and #> has also taken the liberty of changing the special NA-string #into a "NA" #> (i.e. a 2-character string, first letter N, second letter A)! # #That's a bug. If you use NA-strings for unsupplied names, then will you for consistency be making another change to c() so that> mm <- c( a=1, b=2) > mm <- c( mm, 5)now gives an NA-string for mm's 3rd name? # #> An easy way to achieve consistency, would be to make #unsupplied names should #> always default to an empty string, rather than a special NA-string. # #But what's the point of having a special string then? That's just what I was wondering (in the specific case of names attributes). I can see the logic of NA-string names, but I do wonder whether this will cause more practical problems than just using an empty string. It's not just back-compatibility, but also unexpected behaviour. For example, after setting up mm as above: test> mm <NA> <NA> y 1 2 3 test> names( mm)=='y' [1] NA NA TRUE test> mm[ names(mm)=='y'] <NA> <NA> y NA NA 3 the last line being a bit surprising to me, anyway. It's not a bug, but will it be helpful? Empty names instead of NA-names give a behaviour that seems to me more "natural". cheers Mark ******************************* Mark Bravington CSIRO (CMIS) PO Box 1538 Castray Esplanade Hobart TAS 7001 phone (61) 3 6232 5118 fax (61) 3 6232 5012