[R] Bug in "is" ?

[Douglas Bates]

On Wed, Sep 24, 2008 at 4:30 PM, Wacek Kusnierczyk
<Waclaw.Marcin.Kusnierczyk at idi.ntnu.no> wrote:
> Douglas Bates wrote:
>> On Wed, Sep 24, 2008 at 11:08 AM,  <ctu at bigred.unl.edu> wrote:
>>
>>> Thank you for all of you. Intuitively, 7 is an integer for people who live
>>> in this planet. It is just very difficult for me to believe that R does not
>>> think 7 is an integer but 7L is.
>>>
>>>> is.integer(7)  # R 2.7.2
>>>>
>>> [1] FALSE
>>> Thus, based on Martin's comments, I try it again on the S-PLUS 8.0 and it
>>> shows
>>>
>>>> is.integer(7)   # S-PLUS 8.0
>>>>
>>> [1] T
>>>
>>> Hopefully, someday and someone will fix it therefore, R users don't need to
>>> use as.integer(7) to tell R that 7 is an integer.
>>>
>>
>> My father taught me at an early age not to criticize the way that
>> someone else does something until after you have shown that you can do
>> it better.  The fact that you don't agree with a design decision
>> doesn't mean that it is wrong and should be "fixed".
>>
>> We look forward to using the system for computing with data that you
>> will develop and make freely available and in which 7 will be stored
>> as an integer.  In the meantime, if you want to use R then you will
>> just need to grit your teeth and accept that literal constants like
>> '7' are stored as floating point values and literal constant like '7L'
>> are stored as integers.
>>
>>
>>
>
> good god.  my father taught me that if i want to do business, or if i
> just want to do favours, i should listen to the customers.  'shut up and
> accept our design if you want to use our product', esp. if there are
> design issues which apparently cause *unnecessary* confusion, is kinda
> arogant.

> you don't need to be an emperor to be able to see that an emperor is
> naked;  you'd better listen to -- and encourage -- folks that give you
> feedback, rather than trash them.

I was not trying to indicate that we do not appreciate feedback on the
design of R.  Martin had responded earlier in the thread pointing out
why is(7, "integer") returns FALSE and also that, for the most part,
that should not be a problem.  If you want to find out if a vector can
be used in a numeric operation then the appropriate check would be
is.numeric(7) or  is(7, "numeric"), both of which return TRUE.

The fact that is.integer(7) surprisingly returns FALSE (as does is(7,
"integer")) is due to the nature of the function is.integer.  This
function checks if the numeric value associated with the literal
constant 7 ends up being stored as an integer and it isn't.  The
parser  converts tokens that it recognizes as being numeric values to
double precision numeric values.  If you really want to create the
integer representation of the number 7 you can achieve that as '7L' or
as.integer(7).  But, most of the time (in fact, I would say all the
time except when you are planning on passing the value to compiled
code through .C or .Call or .Fortran interface, but I could be wrong
about that) you don't need to know if a particular numeric value is
stored as an integer or as a floating point number.  In fact, the
"Details" section of the help page accessible as ?is.integer (hands up
all the participants in this thread who have actually read the help
page for is.integer) states

"Integer vectors exist so that data can be passed to C or Fortran code
which expects them, and so that small integer data can be represented
exactly and compactly."

Having the parser convert literal numeric strings to floating point
values was part of the original S and S-PLUS and R implementations.
In later versions of S-PLUS the parser's behavior was changed to look
for a decimal point and use an integer representation if there was no
decimal point.  We adopted another approach in R which is the one
described above.  If you really need an integer value from a literal
string you can force that by appending 'L' but first you should decide
if it is important to you that the value be stored as an integer.  In
the vast majority of cases you don't need to know how a numeric value
is stored.

The problem stems from a misunderstanding of what the function
is.integer checks. It is not a check of "does this numeric value
happen to be an integer?".  It is checking if the numeric value
happens to be stored as an integer.  Martin, in his usual patient
manner, pointed this out.  I was responding to the response to
Martin's explanation stating, effectively, "this is broken and should
be fixed".   I don't consider the behavior to be an error.  I think
the problem is misunderstanding the purpose of is.integer and I would
point out that the behavior is as documented.

The topic of checking what the documentation says before declaring the
behavior wrong has come up before.  If you have the fortunes package
installed you can try

library(fortunes)
fortune("Perl")


> of course, it is not an objective truth that letting integer(7) evaluate
> to FALSE is wrong;

I think you mean "is.integer(7)" and, as I said above, you should
check what the semantics of the is.integer function are before
proclaiming a result to be wrong.
in Oz, for example, you can't add an integer to a
> float, and in Perl you can add whatever number to whatever string.
> these designs have their merits, and the 'how it is stored' story about
> 7 is not unreasonable -- but it does seem to be a wrong decision for a
> language focused mostly with statistical computations and not computer
> science concerned with how to represent an integer.  you can always
> design a language where 7 is stored as a string by default, but it
> should be fine to listen to your users what they think about it.
>
> sorry for the reaction, but i thought you've missed something you
> shouldn't have.
> vQ
>