sorry, for joining this thread so late. I've just upgraded to R2.8.0
and was hit with the same issue immediately in my fts package.
Has any consensus been reached about how to deal with this issue?
Do I understand correctly that the change to use:
[sort.c: 592]
PROTECT(call = lang4(install(".gt"), x, si, sj));
c = asInteger(eval(call, rho));
inside of "static int equal(int i, int j, SEXP x, Rboolean nalast,
SEXP rho)" was to promote class based object dispatching for
comparisons?
-Whit
On Thu, Oct 23, 2008 at 6:16 AM, Gabor Grothendieck
<ggrothendieck at gmail.com> wrote:
> 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.
> <Bernhard_Pfaff at fra.invesco.com> 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:ggrothendieck at gmail.com]
>>>Gesendet: Donnerstag, 23. Oktober 2008 02:36
>>>An: Peter Dalgaard
>>>Cc: Pfaff, Bernhard Dr.; r-devel at stat.math.ethz.ch
>>>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
>>><p.dalgaard at biostat.ku.dk> 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
>>>>> <ggrothendieck at gmail.com> 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
>>>>>>> ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) 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
>>>> ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>