Based on the quote that Peter gave:
o New generic function xtfrm() as an auxiliary helper for
sort(), order() and rank(). This should return a numeric
vector that sorts in the same way as its input. The default
method supports any class with ==, > and is.na() methods but
specific methods can be much faster.
As a side-effect, rank() will now work better on classed
objects, although possibly rather slowly.
it seems that it was the intention to have rank(x) use x only via xtfrm(x)
but that is not, in fact, how it works as defining xtfrm.zoo still
results in the
discussed error.
On Thu, Oct 23, 2008 at 5:13 AM, Pfaff, Bernhard Dr.
<[EMAIL PROTECTED]> wrote:
> Dear Achim, Gabor, Jeff, Peter and remaining list-subscribers,
>
> first, please accept my apologies for having started this thread. Given the
> avalanche of responses (some off-list) and the associated time stamps, some
> of you have almost pulled an all-nighter about this topic. I might have not
> have started this thread in the first place, if I would have known this.
>
> I agree with Achim's view that a "not working for zoo objects" strategy is
> preferable compared to a "half-working for zoo objects" strategy. I do not
> have either a problem by employing coredata(z) when necessary. Now, Gabor,
> you pointed out nicely that the culprit, namely that order() resides on top
> of xtfrm whereas rank() does not (this was voiced by you in an email to Peter
> and R-Devel, hence I inlucde these recipients again in this thread and the
> reason for doing this is also motivated by the following proposition):
>
> You further pointed out that the problems wrt to rank and zoo-objects could
> be solved if rank() would, like order() does, reside on top of xtfrm. My
> question/proposal would then be to follow this approach, i.e. use xtfrm in
> rank. Now, I am not that deep into R nor an expert to judge whether this
> would cause problems/breaking existing R code in other instances; hence I
> appreciate feedback if this would be a feasible/desirable change in R-Devel.
>
>
> Best,
> Bernhard
>
>>-----Ursprüngliche Nachricht-----
>>Von: Gabor Grothendieck [mailto:[EMAIL PROTECTED]
>>Gesendet: Donnerstag, 23. Oktober 2008 02:36
>>An: Peter Dalgaard
>>Cc: Pfaff, Bernhard Dr.; [EMAIL PROTECTED]
>>Betreff: Re: [Rd] R 2.8.0 qqnorm produces error with object of
>>class zoo?
>>
>>I don't think its hopeless. order works ok provided the
>>underlying class
>>defines an xtfrm method. I think rank should follow that
>>route too. Its
>>arguably the inconsistency between rank and order (order but not the
>>rank uses xtfrm) that causes the inconsistent behavior between the two.
>>If rank were also built on top of xtfrm then it would work as
>>desired as
>>well.
>>
>>On Wed, Oct 22, 2008 at 5:03 PM, Peter Dalgaard
>><[EMAIL PROTECTED]> wrote:
>>> Gabor Grothendieck wrote:
>>>>
>>>> And one other point.
>>>>
>>>> z <- zoo(1:4)
>>>> .gt(z, 1, 2)
>>>>
>>>> fails because z[1] and z[2] are at different time points so
>>>>
>>>> z[1] == z[2]
>>>>
>>>> is logical(0) because when zoo compares objects it aligns them
>>>> first.
>>>
>>> Yes, that was the point that I was trying to make. Well,
>>arguably it doesn't
>>> "fail", it just does what it is supposed to do. Things would
>>"work" with [[
>>> or a preceding unclass(z), but that would break comparisons
>>involving, say,
>>> POSIXlt objects. So you're sort of stuck between a rock and
>>a hard place.
>>>
>>>>
>>>> On Wed, Oct 22, 2008 at 2:19 PM, Gabor Grothendieck
>>>> <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> Yes, I noticed that but rank is not generic. An xtfrm.zoo
>>>>> method has been added to zoo on R-Forge but rank still
>>>>> fails:
>>>>>
>>>>>> R.version.string
>>>>>
>>>>> [1] "R version 2.8.0 Patched (2008-10-21 r46766)"
>>>>>>
>>>>>> packageDescription("zoo")$Version
>>>>>
>>>>> [1] "1.5-3"
>>>>>>
>>>>>> library(zoo)
>>>>>> # next line adds xtfrm zoo method
>>>>>> xtfrm.zoo <- coredata
>>>>>> z <- zoo(1:4)
>>>>>> order(z) # ok
>>>>>
>>>>> [1] 1 2 3 4
>>>>>>
>>>>>> qqnorm(z) # ok
>>>>>> rank(z) # error
>>>>>
>>>>> Error in if (xi == xj) 0L else if (xi > xj) 1L else -1L :
>>>>> argument is of length zero
>>>>>
>>>>>
>>>>>>>> (If the MIME type is wrong, then that will happen.)
>>>>>>>>
>>>>>>>> Anyways, the root cause seems to be the new function
>>.gt() which is
>>>>>>>> related to
>>>>>>>>
>>>>>>>> o New generic function xtfrm() as an auxiliary helper for
>>>>>>>> sort(), order() and rank(). This should return a numeric
>>>>>>>> vector that sorts in the same way as its input.
>>The default
>>>>>>>> method supports any class with ==, > and is.na()
>>methods but
>>>>>>>> specific methods can be much faster.
>>>>>>>>
>>>>>>>> As a side-effect, rank() will now work better on classed
>>>>>>>> objects, although possibly rather slowly.
>>>>>>>>
>>>>>>>> Here, "better" may be in the eyes of the beholder, for
>>>>>>>>
>>>>>>>>
>>>>>>>>> dax[3]==dax[6]
>>>>>>>>>
>>>>>>>> Data:
>>>>>>>> logical(0)
>>>>>>>>
>>>>>>>> Index:
>>>>>>>> integer(0)
>>>>>>>>
>>>>>>>> and accordingly
>>>>>>>>
>>>>>>>>
>>>>>>>>> rank(dax)
>>>>>>>>>
>>>>>>>> Error in if (xi == xj) 0L else if (xi > xj) 1L else -1L :
>>>>>>>> argument is of length zero
>>>>>>>>
>>>>>>>> which is the error that you are seeing.
>>>>>>>>
>>>>>>>> What to do about it is a bit dubious. Obviously, we
>>don't want to
>>>>>>>> "fix"
>>>>>>>> .gt() so that it automatically unclasses objects, and I
>>assume that
>>>>>>>> zoo
>>>>>>>> has its reasons for not wanting to compare series with different
>>>>>>>> indices. So I suppose that either the user must
>>unclass, or zoo define
>>>>>>>> rank.zoo.
>>>>>>>>
>>>>>>> Actually qqnorm does not use rank but it does use order
>>and with the
>>>>>>> xtfrm.zoo method I mentioned qqnorm works with zoo;
>>however, I think
>>>>>>> rank needs to be fixed in R to make use of xtfrm as well
>>since I would
>>>>>>> have
>>>>>>> expected that supplying an xtfrm method for zoo would be
>>sufficient to
>>>>>>> get both order and rank to work without giving errors.
>>Also note that
>>>>>>> rank
>>>>>>> is not generic.
>>>>>>>
>>>>>> Notice that xtfrm.default() uses rank()....
>>>>>>
>>>>>> --
>>>>>> O__ ---- Peter Dalgaard Øster Farimagsgade 5, Entr.B
>>>>>> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
>>>>>> (*) \(*) -- University of Copenhagen Denmark Ph:
>>(+45) 35327918
>>>>>> ~~~~~~~~~~ - ([EMAIL PROTECTED]) FAX:
>>(+45) 35327907
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>> --
>>> O__ ---- Peter Dalgaard Øster Farimagsgade 5, Entr.B
>>> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
>>> (*) \(*) -- University of Copenhagen Denmark Ph:
>>(+45) 35327918
>>> ~~~~~~~~~~ - ([EMAIL PROTECTED]) FAX:
>>(+45) 35327907
>>>
>>
> *****************************************************************
> Confidentiality Note: The information contained in this message,
> and any attachments, may contain confidential and/or privileged
> material. It is intended solely for the person(s) or entity to
> which it is addressed. Any review, retransmission, dissemination,
> or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient(s) is
> prohibited. If you received this in error, please contact the
> sender and delete the material from any computer.
> *****************************************************************
>
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
