R devel - Dec 2002 - 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

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

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