From Kurt.Hornik@ci.tuwien.ac.at  Fri Oct  6 13:07:48 2000
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Fri, 6 Oct 2000 14:07:48 +0200 (CEST)
Subject: [Rd] all.equal.list() sometimes fails with unnamed and named
 components (PR#674)
In-Reply-To: <14810.53677.386845.624289@mithrandir.hornik.net>
References: <14810.52552.433477.593314@mithrandir.hornik.net>
 <Pine.GSO.4.05.10010040724190.16973-100000@auk.stats>
 <14810.53677.386845.624289@mithrandir.hornik.net>
Message-ID: <14813.49300.795765.338583@mithrandir.hornik.net>

>>>>> Kurt Hornik writes:

>>>>> Prof Brian D Ripley writes:
>> On Wed, 4 Oct 2000, Kurt Hornik wrote:
>>> > I think that both the names and components should match exactly (the
>>> > components recursively).  Unfortunately the named-component extraction

>>> > is partial matching (at least, sometimes) so the ordering of the names
>>> > always matters.  (There's an S/R difference here I keep forgetting to 
>>> > write down. I think it is 
>>> 
>>> > x <- list(aa=1, bb=2)
>>> > x["a"]
>>> 
>>> > which gives in S
>>> > $aa:
>>> > [1] 1
>>> > and in R
>>> > $"NA"
>>> > NULL
>>> > so S always partial matches, but R does not always.)
>>> 
>>> More precisely, we have
>>> 
R> x[["a"]]
>>> [1] 1
R> x["a"] 
>>> $"NA"
>>> NULL
>>> 
>>> Does this make sense at all?  Comparing it to
>>> 
R> x <- list(aa=1, bb=2, "NA"=3)
R> x["NA"]
>>> $"NA"
>>> [1] 3
>>> 
>>> I would think that the x["a"] incorrectly indicates that the list has a
>>> named component "NA" with value NULL ...

>> Yes, so would I. I think it is a bug in R.

> Agreed.  Should not be too hard to spot ...

>>> What should we do about all.equal.list()?  Should we deal with the named
>>> components first and strip them off, or always go the positional route?
>>> Your comment that lists are generic vectors would indicate that the
>>> second approach is more appropriate ...

>> See the first two lines I've left here. I think it should be
>> positional matching *and* the names should match too. That is,
>> all.equal.list would fail if one list had names and other did not.

> Well should it really FAIL?

> What would be the precendence of the comparisons?  E.g.,

> * compare the lenghts.  If different, only retain the components from 1
> to the smaller lenght.

> * Go through these.  If they have names, compare the names.  Then
> compare the values.

> [If both components have the same name but differ in value, the output
> would display the name and not the position, right?  I mean something
> like
>   msg <- c(msg, paste("Component ", nc[i], ": ", mi, sep=""))
> rather than
>   msg <- c(msg, paste("Component ", i, ": ", mi, sep=""))
> ???]

The more I think about it, the less I am sure about what we really want.

In discussions with Fritz yesterday we noticed that quite often lists
are in fact used as hash tables; typically this is what is meant if all
components of the list have names.  Fritz suggested an option
	hash.order = FALSE
to all.equal.list() through which one could control the interpretation.
This option could also be passed on recursively.

I am not sure about this.  There is a difference between `typically' and
always.  Maybe we should have hash tables which can be implemented as
lists with class "hashtable".  This would be clean, but a substantial
change (e.g., most modelling functions in fact return hash tables in the
above sense) and I am not sure whether this is worth the effort.

We can fix the problems in the bug report by deleting the code in
all.equal.list() which compares the components.  That has the effect
that named components are referred to as positional even if their names
agree, and we should decide whether we want this or not.

-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel 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-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


[Rd] all.equal.list() sometimes fails with unnamed and named components (PR#674)
Kurt Hornik