[Rd] Table vs unique

[Therneau, Terry M., Ph.D.]

 Thanks to both Brian and Goran for the suggestions.  I've now added the following
to the code: 

    # Round the survival times just a little.  Otherwise unique() and
    #  table() can give a different list of unique times, and both are
    #  used in the subsequent routines.  A test case with times of
    #  sqrt(2)^2 and 2 revealed this issue.  Normally double.digits is
    #  53 in base 2, which leads to 15 decimal digits.
    digits <- floor((.Machine$double.digits -1) * 
                    logb(.Machine$double.base,10)) #base 10 digits
    Y[,1] <- signif(Y[,1], digits)
    if (ncol(Y)==3) Y[,2] <- signif(Y[,2],digits)

It will migrate to CRAN in due course.
   Terry T 

-----Original Message-----
From: Göran Broström [mailto:gb at stat.umu.se] 
Sent: Thursday, July 22, 2010 3:54 PM
To: Prof Brian Ripley
Cc: Therneau, Terry M., Ph.D.; r-devel at r-project.org
Subject: Re: [Rd] Table vs unique

On 07/21/2010 03:54 PM, Prof Brian Ripley wrote:
> I believe this is a misdiagnosis: the 'rounding' is done by
> as.character (as the help for argument 'levels' in ?factor does say)
> and ?as.character has a full explanation (and is linked from the
> relevant part of ?factor).
>
> as.numeric(as.character()) should do the trick.

Or

temp <- signif(temp, digits = 15)

which seems to be much faster.

Göran B.

>
> On Wed, 21 Jul 2010, Terry Therneau wrote:
>
>> A bug in the survival routines was reported to me today.  The root cause
>> is a difference between table, unique, and sort.
>>
>>> temp<- rep(c(1, sqrt(2)^2, 2), 1:3)
>>> unique(temp)
>> [1] 1 2 2
>>> table(temp)
>> temp
>> 1 2
>> 1 5
>>
>>   I'm using 2.10 on Linux, the user reported from 2.9 on Windows.
>>
>> 1. Minor issue: I think the root rounding occurs in factor.  I didn't
>> see any discussion of this in the help page, perhaps something should be
>> added.
>>
>> 2. The error popped up in summary.survfit but the root cause is an
>> inconsistent survfit object.  The survfit routine uses sort and unique
>> to create the unique survival times and most of the output, but table to
>> count them for another component.
>>   Lumping the two versions of "2.0000...." together is the preferable
>> output.  I think the best solution will be to preprocess the time
>> variable so that the three operators are consistent.
>>
>> 	as.numeric(as.character(as.factor(time))) ?
>>
>> Rather ugly.  But most importantly what is a guarranteed construct that
>> would ensure consistency?  Should we use a rounding level that is more
>> or less equivalent to all.equal()?
>>
>> The solution will have to be incorporated into survfit, coxph, ...
>> perhaps a dozen places in the survival suite so I'd like to get it right
>> the first time.
>>
>> Terry T
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>