Bug in "is" ?
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