[Rd] Re: [R] Unexpected behaviour of identical (PR#6799)

[Tony Plate]

AFAIK identical() first introduced by Chambers in "Programming with 
data"?  On p262 he writes:

identical: The two objects must be exactly equal in all respects; if not 
identical returns FALSE
all.equal: The two objects are expected to be identical up to small 
differences that might be considered irrelevant...

Taken literally, this would seem to argue against identical() treating 
attributes as a set (unless one were to tighten up the definition of 
attributes in Section 2.2 of the R Language Definition to explicitly state 
that attributes are to be treated as an unordered set).

However, given the primary use of identical() on complex objects is in 
software testing, and AFAIK no software depends on the order of attributes, 
I still think it would be reasonable for attributes to be treated as a set 
by identical().  (Unless anyone can show that it's important to recognize 
order of attributes in some code.)

I'm proposing a more general fix for this problem because I strongly 
suspect that factor subsetting is not the only thing that can change the 
order of attributes, and because I've wasted many hours tracking down 
problems that turned out to be caused by problems with data.dump() and 
identical() in S-plus.  Another possible fix might be for the attr() and 
attributes() replacement functions to store attributes as a sorted list.  I 
don't know if this would be easy or difficult to implement, or what 
consequences it might have in terms of existing tests that involve printed 
output of attributes.

-- Tony Plate

At Tuesday 09:13 AM 4/20/2004, Prof Brian Ripley wrote:
>I wondered that, but I think we need to hear from the author of
>identical().
>
>It is neater to have attributes printed in a consistent order, though.
>
>On Tue, 20 Apr 2004, Tony Plate wrote:
>
> > What about changing identical() to ignore the order of attributes?  Is
> > there any code anywhere that depends on the order of attributes, other 
> than
> > identical()?  I've only seen attributes treated as an unordered set, and
> > never as an ordered list.  There are some functions in S-plus that change
> > the order of attributes, and the only thing this affects is
> > identical().  (Which in S-plus also pays attention to the order of 
> attributes.)
> >
> > -- Tony Plate
> >
> > At Tuesday 05:42 AM 4/20/2004, p.dalgaard at biostat.ku.dk wrote:
> > >"Swinton, Jonathan" <Jonathan.Swinton at astrazeneca.com> writes:
> > >
> > > >  # works as expected
> > > > > ac <- c('A','B');
> > > > > identical(ac,ac[1:2])
> > > > [1] TRUE
> > > >
> > > >  #but
> > > > > af <- factor(ac)
> > > > > identical(af,af[1:2])
> > > > [1] FALSE
> > > >
> > > > Any opinions?
> > >
> > >Did a cross-check with Splus and it doesn't do that , so I think it
> > >qualifies as a bug. Shouldn't be too hard to fix (might lose a little
> > >efficiencty though).
> > >
> > >--
> > >    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-devel at stat.math.ethz.ch mailing list
> > >https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
> >
> > ______________________________________________
> > R-devel at stat.math.ethz.ch mailing list
> > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
> >
> >
>
>--
>Brian D. Ripley,                  ripley at 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 272866 (PA)
>Oxford OX1 3TG, UK                Fax:  +44 1865 272595