R devel - Aug 2009 - identical(0, -0)

I'll save space and not include previous messages.

My 2 cents: At the very least the documentation needs a fix. If it is 
easy to do, then Ted Harding's suggestion of a switch (default OFF) to 
check for sign difference would be sensible.

I would urge inclusion in the documentation of the +0, -0 example(s) if 
there is NOT a way in R to distinguish these. There are occasions where 
it is useful to be able to detect things like this (and NaN and Inf and 
-Inf etc.). They are usually not of interest to users, but sometimes are 
needed for developers to check edge effects. For those cases it may be 
time to consider a package FPIEEE754 or some similar name to allow 
testing and possibly setting of flags for some of the fancier features. 
Likely used by just a few of us in extreme situations.  Unfortunately, 
some of the nice exception handling that was suggested in the standard 
is apparently rarely implemented in compilers.

For info, I was actually a voting member of IEEE 754 because I found a 
nice "feature" in the IBM Fortran G arithmetic, though I never sat in
on
any of the meetings.

JN

On Sat, Aug 8, 2009 at 10:39 AM, Prof. John C Nash<nashjc at uottawa.ca>
wrote:
> I would urge inclusion in the documentation of the +0, -0 example(s) if
> there is NOT a way in R to distinguish these. There are occasions where it
For single numbers try this:

x <- +0
y <- -0
identical(x, y) && identical(1/x, 1/y) # FALSE

On Sat, Aug 08, 2009 at 10:39:04AM -0400, Prof. John C Nash
wrote:
> I'll save space and not include previous messages.
> 
> My 2 cents: At the very least the documentation needs a fix. If it is 
> easy to do, then Ted Harding's suggestion of a switch (default OFF) to 
> check for sign difference would be sensible.
> 
> I would urge inclusion in the documentation of the +0, -0 example(s) if 
> there is NOT a way in R to distinguish these.
It is possible to distinguish 0 and -0 in R, since 1/0 == Inf and
1/(-0) == -Inf.

I do not know, whether there are also other such situations. In particular
  (0)^(-1) == (-0)^(-1) # [1] TRUE
  log(0) == log(-0) # [1] TRUE
> There are occasions where 
> it is useful to be able to detect things like this (and NaN and Inf and 
> -Inf etc.). They are usually not of interest to users, but sometimes are 
> needed for developers to check edge effects. For those cases it may be 
> time to consider a package FPIEEE754 or some similar name to allow 
> testing and possibly setting of flags for some of the fancier features. 
> Likely used by just a few of us in extreme situations.
I think that distinguishing 0 and -0 may be useful even for nonexpert
users for debugging purposes. Mainly, because x == y does not imply
that x and y behave equally as demonstrated above or by
  x <- 0
  y <-  - 0
  x == y # [1] TRUE
  1/x == 1/y # [1] FALSE

I would like to recall the suggestion
  On Sat, Aug 08, 2009 at 03:04:07PM +0200, Martin Maechler wrote:
  > Maybe we should introduce a function that's basically
  > isTRUE(all.equal(..., tol=0))  {but faster},  or
  > do you want a 3rd argument to identical, say 'method'
  > with default  c("oneNaN", "use.==",
"strict")
  > 
  > oneNaN: my proposal of using  memcmp() on doubles as its used for
  >        other types already  (and hence distinguishing +0 and -0;
  >      otherwise keeping the feature that there's just one NaN
  >      which differs from 'NA' (and there's just one
'NA').
  > 
  > use.==: the previous R behaviour, using '==' on doubles 
  >   (and the "oneNaN" behavior)
  > 
  > strict: be even stricter than oneNaN:  Use  memcmp()
  >   unconditionally for doubles.  This would be the fastest
  >   version of all three.

In my opinion, for debugging purposes, the option
identical(x,y,method="strict"),
which implies that x and y behave equally, could be useful, if it is available
in R base, 

At the R interactive level, negative zero as the value of -0 could possibly
be avoided. However, negative zero may also occur in numerical calculations,
since it may be obtained as x * 0, where x is negative. So, i think, negative
zero cannot be eliminated from consideration as something too infrequent.

Petr.