Skip to content
Prev 157488 / 398506 Next

Bug in "is" ?

Peter Dalgaard 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.

*you* can't you take square root of the *integer* 2, can you?

"is.double(-1+0i) is not true either, even though the real line is
cleanly embedded in complex space,"
apparently, but it's an *implementation* choice, not a property of the
(both real and complex) number -1+0i.  the r function is.double returns
false for -1+0i, but it's not because the number -1+0i is not real, but
because the literal '-1+0i' makes r represent the number using a
specific representation scheme.  if you try to prove that r must work
the way it does by showing how it works, it's painfully circular, and void.

the problem was, and is, that is.integer refers to the *representation*,
not the *value* (which should, arguably, be clear from the man page),
and this seems to be counterintuitive to some of the users.
and this, again, is an *implementation* matter, not a property of numbers.
again, in languages that allow the user to think mathematics rather than
registers and processors, (2/3)*x == 2*x/3 would rather evaluate to
true, even though these are *computer* languages used to specify
*computations*.

all this trolling, again, to argue that it's far from obvious that
is.integer(7) evaluates to FALSE, even if this might be a reasonable
choice from some point of view.
well, 'naive' should mean 'not familiar with r' rather than 'not
understanding the nature of computation'.  you can have good background
in maths and cs, and still expect that a language like r behaves
differently.
there's really no point in offending people that get confused by r's
details.

vQ