[R] Bug in "is" ?

[Rolf Turner]

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

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.)

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.

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.

		R. T.

######################################################################
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}