[R] Bug in "is" ?

[Wacek Kusnierczyk]

Wacek Kusnierczyk wrote:
>
> you see, there seems to be a confusion of *numbers* and their
> *representations*.
> but of course the integer 7 is *the same* number as the real number 1.0,
> even if we refer to it using two different representations.
> the literal '7' might, in some system, cause the compiler/interpreter to
> use an integer representation of the number 7, and to use a floating
> point representation of the number 7 in some other system.
> these two representations differ, as do those for -1 and -1+0i; but just
> as the real number 7.0 happens to be an integer, so does the complex
> number -1+0i happen to be a real number.
>
> and, of course, you can take a square root of -1, that's what you do
> when you square-root -1+0i, only that the result is not a member of the
> set of real numbers.  the fact that you may not be able to apply, in a
> computer language, sqrt to -1, is a consequence of a particular
> implementation; there's no problem, in principle, in having a system
> where sqrt(-1) is allowable even if the literal '-1' corresponds to an
> integer or floating point representation rather than one for complex
> numbers.  just try it with systems such as octave, matlab, mathematica,
> sage, etc.  in the last one, for example sqrt(int(-1)) is perfectly
> legal, and returns what's expected.
>   
i also note that r *can* swallow the following (returning a non-integer
result):

sqrt(as.integer(2))

but it can't do the following (it returns NaN with a warning):

sqrt(as.integer(-1))
sqrt(as.double(-1))
sqrt(-1)

which is incoherent, in that there is an implicit type cast in the first
case, but not in the later ones.  and why not?
obviously, sage's gracefully computing sqrt(int(-1)) is a proof by
construction (for those who really need it) that r's design choice is
not the only possible (and, arguably, not the most intuitive and
practical, at this level of abstraction).

vQ