On Aug 10, 2009, at 5:47 , Duncan Murdoch wrote:
Petr Savicky wrote:
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.
I wouldn't mind a "strict" option. It would compare bit patterns,
so would distinguish +0 from -0, and different NaN values. But
having the value of identical(x-y, -(y-x)) depend on whether x and
y are equal or not would just lead to confusion.
... but so do other things routinely such as floating point
arithmetics so I don't think this is a strong argument here. IMHO
identical(0, -0) should return FALSE, because they are simply not the
same objects and that's what identical is supposed test for. If you
want to test equality of elements there are other means you should be
using that were mentioned in this thread.
Cheers,
Simon
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
