# [R] NAs produced by integer overflow, but only some time ...

Jeff Newmiller jdnewm|| @end|ng |rom dcn@d@v|@@c@@u@
Thu May 10 01:34:48 CEST 2018

```When you have cooled down you may notice that the answer to your question was in items a-d, though Bill's use of str made it clearer. Also, there was in fact no call to yules.k1, much less one that includes sample data. You will find that the solution to problems in R are very often related to the details of the data you are working with that _you_ aren't noticing, which makes providing sample data a key step to obtaining a straightforward resolution to most problems. There are various discussions online about how to do this. [1][2]

---

[1] http://stackoverflow.com/questions/5963269/how-to-make-a-great-r-reproducible-example

On May 9, 2018 7:58:19 AM PDT, "Stefan Th. Gries" <stgries using gmail.com> wrote:
>Before responding to Jeff's posting, let me reiterate my question: Why
>does a function using m1*m1 produce an integer overflow, but m1^2 does
>not?
>
>As for Jeff's 'response':
>
>> a) Numeric values may be either integers (signed 32 bit) or double
>precision (53 bit mantissa).
>> b) Double precision constants are numeric with no decoration (e.g.
>61224). Integer constants have an L (e.g. 61224L).
>> c) 61224*61224 > 2^31-1 so that answer cannot fit into an integer.
>> d) Exponentiation is a floating point operation so the result of
>61224L^2L is a floating point answer that CAN fit into the 53bit
>mantissa of a double precision value, so no overflow occurs.
>Yes, that's all great and I knew that from
><https://stackoverflow.com/questions/8804779/what-is-integer-overflow-in-r-and-how-can-it-happen>.
>
>> e) Defining a function like yules.k1 and never showing how you called
>it does not constitute a reproducible example. To avoid such gaffes you
>can use the reprex package to confirm that the errors shown in your
>question are in fact reproducible.
>Responding to a post and never seeing that the provided code does
>actually show how I call the function does not constitute a useful
>confirm that the perceived lack of a function call is in fact such a
>lack. In addition, typing m1 <- 61224 makes the multiplication example
>that I shows in the bottom part of the posting reproducible ...
>
>> f) On this mailing list, the fact that you are using RStudio is at
>best irrelevant, and at worst off-topic. If you don't see problems
>running your reproducible example from R in the terminal then the
>question probably belongs in the RStudio support forum. This is another
>reason to use the reprex package to check your reproducibility (this
>works even if you invoke it from RStudio).
>I did provide the information for the sake of comprehensiveness and I
>did mention that the problem also showed up in the console; the whole
>second part of the post was on that.
>
>> g) Calling table on the result of table must be one of the more
>bizarre calculation sequences I have ever seen in R. I hope you are
>getting the answers you are expecting when you do use double precision
>numeric values. Also, using the prefix form of multiplication is
>unnecessarily obscure, and your use of the return function at the end
>On this mailing list, your assessment of calculation sequences and
>their comparison to others you have seen is at best irrelevant and at
>(you or anyone) to grade my code and there are reasons why "*" and
>return where used there as they are) but to answer the question why
>m1*m1 returned an error and m1^2 does not.

--
Sent from my phone. Please excuse my brevity.

```