Thanks to Luke and Avi for their comments. I wrapped "round" around the
call to "rnorm" inside my "rpois.". For "lambda" really big, that
"round" won't do anything. However, it appears to give integers in
floating point representation that are larger than
.Machine$integer.max. That sounds
R uses the C 'int' type for its integer data and that is pretty much
universally 32 bit these days. In fact R wont' compile if it is not.
That means the range for integer data is the integers in [-2^31,
+2^31).
It would be good to allow for a larger integer range for R integer
objects, and
On my Mac:
str(.Machine)
...
$ integer.max : int 2147483647
$ sizeof.long : int 8
$ sizeof.longlong : int 8
$ sizeof.longdouble : int 16
$ sizeof.pointer : int 8
On a Windows 10 machine I have, $ sizeof.long : int 4; otherwise
the same as on my
Floor (maybe round) of non-negative numerics, though. Poisson should never
have anything after decimal.
Still think it’s worth allowing long long for R64 bit, just for purity
sake.
Avi
On Sun, Jan 19, 2020 at 4:38 PM Spencer Graves
wrote:
>
>
> On 2020-01-19 13:01, Avraham Adler wrote:
>
>
On 2020-01-19 13:01, Avraham Adler wrote:
> Crazy thought, but being that a sum of Poissons is Poisson in the sum,
> can you break your “big” simulation into the sum of a few smaller
> ones? Or is the order of magnitude difference just too great?
I don't perceive that as feasible.
Crazy thought, but being that a sum of Poissons is Poisson in the sum, can
you break your “big” simulation into the sum of a few smaller ones? Or is
the order of magnitude difference just too great?
On Sun, Jan 19, 2020 at 1:58 PM Spencer Graves
wrote:
> This issue arose for me in
This issue arose for me in simulations to estimate confidence,
prediction, and tolerance intervals from glm(., family=poisson) fits
embedded in a BMA::bic.glm fit using a simulate.bic.glm function I added
to the development version of Ecfun, available at
Technically, lambda can always be numeric. It is the observations which
must be integral.
Would hitting everything larger than maxint or maxlonglong with floor or
round fundamentally change the distribution? Well, yes, but enough that it
would matter over process risk?
Avi
On Sun, Jan 19, 2020
So imagine rpois is changed, such that the storage mode of its return
value is sometimes integer and sometimes numeric. Then imagine the case
where lambda is itself a realization of a random variable. Do we really
want the storage mode to inherit that randomness?
On 1/19/20 10:47 AM, Avraham
Maybe there should be code for 64 bit R to use long long or the like?
On Sun, Jan 19, 2020 at 10:45 AM Spencer Graves
wrote:
>
>
> On 2020-01-19 09:34, Benjamin Tyner wrote:
> >>
> >> Hello, All:
> >>
> >>
> >>
On 2020-01-19 09:34, Benjamin Tyner wrote:
Hello, All:
Consider:
Browse[2]> set.seed(1)
Browse[2]> rpois(9, 1e10)
NAs produced[1] NA NA NA NA NA NA NA NA NA
Should this happen?
I think
Hello, All:
Consider:
Browse[2]> set.seed(1)
Browse[2]> rpois(9, 1e10)
NAs produced[1] NA NA NA NA NA NA NA NA NA
Should this happen?
I think that for, say, lambda>1e6, rpois should return
Hello, All:
Consider:
Browse[2]> set.seed(1)
Browse[2]> rpois(9, 1e10)
NAs produced[1] NA NA NA NA NA NA NA NA NA
Should this happen?
I think that for, say, lambda>1e6, rpois should return rnorm(.,
lambda, sqrt(lambda)).
For my particular Monte Carlo, I have
13 matches
Mail list logo
