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}}
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
