[R] Bug in "is" ?

[Wacek Kusnierczyk]

Rolf Turner wrote:
>
> On 26/09/2008, at 1:27 AM, Petr PIKAL wrote:
>
>> Hi
>>
>> Sorry but I can not agree. If you measure something and your values in a
>> vector are
>>
>> c(5.1, 5.4, 4.8, 5.0)
>>
>> do you think the first three numbers shall be double and the last one
>> integer? Why? It is just that the reading is not precise enough for the
>> last value to be let say 5.02.
>>
>> I understand that you can assume that with making an assignment x <-
>> 5 you
>> put an integer number to x but you just put a number to it. It is
>> integer
>> in respect that it does not have a fractional part (and it can be tested
>> on this feature) but it is not a class integer
>>
>> Computer minds has limits and I prefer calculation to produce results
>> instead of NA
>>
>> try
>>  x<-2*10^9
>> x
>> is.integer(x)
>> x.i<-as.integer(x)
>> is.integer(x.i)
>>
>> y<-x.i+x.i
>> Warning message:
>> In x.i + x.i : NAs produced by integer overflow
>>> y
>> [1] NA
>>> y<-x+x
>>> y
>> [1] 4e+09
>
> This is indeed a compelling and convincing example.  
the fact that r is not able to appropriately handle integer values such
as 2*10^9 + 2*10^9 is an argument for storing such numbers as
non-integers?  it is perhaps compelling and convincing if you already
have a rather negative opinion on the language.  integer overflow?  are
we programming in c?

try ruby: x = 2*10**9; Integer(x+x) == x+x
try python: x = 2*10**9; isinstance(x+x, int)
try perl, try octave, try mathematica, try ... (well, quite many
languages do what R does)

there are languages that handle this so that the user does not have to
think about how the computer cannot think.  "Computer minds has limits
and I prefer calculation to produce results
instead of NA" -- sure, so why not have R calculate instead of returning
the silly NA?


> However it is to some
> extent off the point.  The problem is that the vast majority of users
> would
> expect a function named is.integer() to reveal whether values are
> integers
> --- whole numbers --- in the usual sense, to within some numerical
> tolerance.
> They would not expect it to reveal some ever-so-slightly arcane
> information
> about the *storage mode* of the values.
>
> Admittedly the help page for is.integer() tells you this ``sort of''. 
> But only
> sort of.  Explicitly it says:
>
>      'is.integer' returns 'TRUE' or 'FALSE' depending on whether its
>      argument is of integer type or not, unless it is a factor when it
>      returns 'FALSE'.
>
> Now what on earth does ``integer type'' mean?  The concept ``type'' is
> not defined
> anywhere, and there is no help on ``type''.  There is no type()
> function.  One
> has to intuit, from the discussion of integer vectors existing so that
> they
> can be properly passed to .C() or .Fortran(), that type has something
> to do
> with storage mode.

indeed.  one more example that R man pages are often rather
uninformative, despite verbosity.

>
> It would have been better to have called the function now known as
> ``is.integer()''
> something like ``is.storedAsInteger()'' and have a function
> is.integer() which
> does what people expect.  E.g.
>
>     is.integer(c(5.1, 5.4, 4.8, 5.0))
>
> would return
>
>     [1] FALSE FALSE FALSE TRUE

>
> Despite what fortune(85) says, it is not unreasonable to expect
> functions to
> do what one would intuitively think that they should do.  E.g. sin(x)
> should not return
> 1/(1+x^2) even if the help page for sin() says clearly and explicitly
> that this
> is what it does.  (Aside:  help pages rarely if ever say *anything*
> clearly and
> explicitly, at least from the point of view of the person who does not
> already
> understand everything about the concepts being explained.)

indeed.  one more opinion that R man pages are often rather
uninformative, despite verbosity.


>
> Be that as it may, this all academic maundering.  The is.integer()
> function
> does what it does and THAT IS NOT GOING TO CHANGE.  We'll just have to
> deal
> with it.  Once one is *aware* that the results of is.integer are
> counter-intuitive,
> one can adjust one's expectations, and it's no big deal.
>
> I do think, however, that there ought to a WARNING section in the help on
> is.integer() saying something like:
>
>     NOTE: is.integer() DOES NOT DO what you expect it to do.

hehe.  this should be printed on the first page in every R tutorial: 
"NOTE: R DOES NOT DO what you expect it to do" (seems i'm in a bad mood,
sorry, R is just fine).

>
> In large friendly letters.
>
>     cheers,
>
>         Rolf Turner
>
> P. S.  Those who want a function that does what one would naturally
> expect
> is.integer() to do could define, e.g.
>
>     is.whole.number <- function(x) {
>         abs(x-round(x)) < sqrt(.Machine$double.eps)
>     }
>
> Then
>
>         is.whole.number(c(5.1, 5.4, 4.8, 5.0))
>
> returns
>
>     [1] FALSE FALSE FALSE TRUE
>
> just as one would want, hope, and expect.

if *this* is what one would want, hope, and expect from is.integer, why
can't we want, hope, and expect that it eventually happens?

vQ