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