[R] Bug in "is" ?

[Wacek Kusnierczyk]

Peter Dalgaard wrote:
> Stefan Evert wrote:
>   
>>
>> ... am I the only one who thinks that the integer 7 is something  
>> entirely different from the real number 7.0? (The latter most likely  
>> being an equivalence class of sequences of rational numbers, but that  
>> depends on your axiomatisation of real numbers.) Integers can be  
>> embedded in the set of real numbers, but that doesn't make them the  
>> same mathematically.
>>   
>>     
> Several people have tried to make that point (or something very
> similar), but it doesn't seem to take.
>
> It might get clearer if taken one step up: is.double(-1+0i) is not true
> either, even though the real line is cleanly embedded in complex space,
> -1+0i is not the same as -1. For instance, you can take the square root
> of the former but not the latter.
>   

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.

> With integers it is less clear that there is a difference in R, but it
> has been mentioned that you can get overflows from adding and multipying
> integers which you dont get with reals. In other programming languages,
> division of integers is integer division and many a fledgling C
> programmer has found the hard way that (2/3)*x is different from 2*x/3.
>   

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.

>   
>> So the original complaint should really have said that is.integer()  
>> doesn't do what a naive user (i.e. someone without a background in  
>> computer science or maths) might expect it to do. :-)
>>     
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