>>>>> Rui Barradas
>>>>> on Mon, 3 Sep 2018 09:58:34 +0100 writes:
> Hello, Watch out for operator precedence.
indeed! (but not only)
> all.equal(0.3, 0.1*3)
> #[1] TRUE
>
>
> `%~~%` <- function (e1, e2) all.equal(e1, e2)
>
> 0.3 %~~% 0.1*3
> #Error in 0.3 %~~% 0.1 * 3 : argumento n?o-num?rico para operador bin?rio
>
>
> 0.3 %~~% (0.1*3)
> #[1] TRUE
>
>
> Now with isTRUE. The problem changes a bit.
>
>
> isTRUE(all.equal(0.3, 0.1*3))
> #[1] TRUE
>
>
> `%~~%` <- function (e1, e2) isTRUE(all.equal(e1, e2))
>
> 0.3 %~~% 0.1*3
> #[1] 0
>
> 0.3 %~~% (0.1*3)
> #[1] TRUE
>
> Hope this helps,
> Rui Barradas
>
> ?s 08:20 de 03/09/2018, Juan Telleria Ruiz de Aguirre escreveu:
> > Maybe a new Operator could be defined for a fast and easy double
> > Comparison: `~~`
> >
> > `~~` <- function (e1, e2) all.equal(e1, e2)
> >
> > And document it properly.
> >
I would still quite strongly recommend against such a
definition:
If you ask for help(all.equal)
you do see that it is a generic with a all.equal.numeric()
method which has several extra arguments
(new ones even in R-devel) the most important one being the
numerical 'tolerance' with a default of
sqrt(.Machine$double.eps) { == 2^-26 == 1.490116e-08 on all current platforms}
Of course there is some arbitraryness in that choice
{{ but only *some*: the default is related to finding the minimum of
smooth function which hence is locally quadratic at a "decent"
minimum hence sqrt(.)
}}
but I find it important sometimes to increase the equality
strictness of that tolerance.
Hiding everything behind a new operator which does not allow to
take into account that there are quite a few versions of
near-equality --- only partly) mirrored by the existence of
extra arguments of all.equal() --- only encourages simplified
thinking about the underlying subtle issues which already too
many people don't care to know about.
(( e.g. all those people only caring for speed, but not for
accuracy and reliability ... ))
Martin Maechler
ETH Zurich and R Core