[Rd] identical(0, -0)

[Petr Savicky]

On Sat, Aug 22, 2009 at 12:00:44AM +0200, Martin Maechler wrote:
> I have taken up the issue now,
> and after thinking, studying the source, trying to define a
> 'method = <string>' argument, came to the conclusion that both
> the implementation and documentation (and source code "self-explanation")
> are easiest to program, maintain, and understand,
> if I introduce explicit binary switches,
> so I now  propose the following R-level interface which keeps
> the current behavior the default:
> 
> >> Usage:
> >> 
> >>      identical(x, y, num.EQ = TRUE, one.NA = TRUE, attrib.asSet = TRUE)
> >> 
> >> Arguments:
> >> 
> >>     x, y: any R objects.
> >> 
> >>   num.EQ: logical indicating if ('double' and 'complex' non-'NA')
> >>           numbers should be compared using '==', or by bitwise
> >>           comparison.  The latter (non-default) differentiates between
> >>           '-0' and '+0'.
> >> 
> >>   one.NA: logical indicating if there is conceptually just one numeric
> >>           'NA' and one 'NaN';  'one.NA = FALSE' differentiates bit
> >>           patterns.
> >> 
> >> attrib.asSet: logical indicating if 'attributes' of 'x' and 'y' should
> >>           be treated as _unordered_ tagged pairlists ("sets"); this
> >>           currently also applies to 'slot's of S4 objects.  It may well
> >>           be too strict to set 'attrib.asSet = FALSE'. 

I appreciate having several binary switches. Besides the arguments above,
this is also useful for an interactive use of identical(), for example,
for debugging purposes. If there is a difference between objects, then
the switches allow to get more information concerning what is the type
of the difference.

> I'm open for better names of arguments, but will not accept "_"
> in the argument names {just my taste; no reason for argueing...}.

I would slightly prefere one.NaN instead of one.NA. In IEEE 754 terminology,
R's 'NA's are a subset of 'NaN's. So. NaN is a bit more general notion,
although in R, the sets of 'NA's an 'NaN's are disjoint. Moreover, the
name one.NaN specifies more clearly, that the issue is important only
for numeric types and not, for example, for integer.

Petr.