similar to: rpois(9, 1e10)

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? >>

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 Adler wrote: > Maybe there should be code for 64 bit R to use long long or the like? > > On

????? 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 "https://github.com/sbgraves237/Ecfun".? This is part of a vignette I'm developing, available at

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.? Once I found what was generating NAs, it was easy to code a function to return pseudo-random

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 Mac. ????? Am I correct that $ sizeof.long = 4 means 4 bytes = 32 bits? log2(.Machine$integer.max)

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 very much like what someone would want.?

On 1/20/20 12:33 PM, Martin Maechler wrote: > > It's really something that should be discussed (possibly not > here, .. but then I've started it here ...). > > The NEWS for R 3.0.0 contain (in NEW FEATURES) : > > * Functions rbinom(), rgeom(), rhyper(), rpois(), rnbinom(), > rsignrank() and rwilcox() now return integer (not double) > vectors.

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 <spencer.graves at prodsyse.com> wrote: > > > On 2020-01-19 13:01, Avraham Adler wrote: > > Crazy thought, but being that a sum of Poissons is

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 at 11:20 AM Benjamin Tyner <btyner at gmail.com> wrote: > So imagine rpois is changed, such

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 <spencer.graves at prodsyse.com> wrote: > This issue arose for me in simulations to estimate confidence, > prediction, and tolerance

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 <spencer.graves at prodsyse.com> wrote: > > > On 2020-01-19 09:34, Benjamin Tyner wrote: > >> ------------------------------------------------------------------------ > >> Hello, All: > >> > >> > >> Consider:

On 1/20/20 4:26 AM, Martin Maechler wrote: > Coming late here -- after enjoying a proper weekend ;-) -- > I have been agreeing (with Spencer, IIUC) on this for a long > time (~ 3 yrs, or more?), namely that I've come to see it as a > "design bug" that rpois() {and similar} must return return typeof() "integer". > > More strongly, I'm actually pretty

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 several of us are thinking about how me might get there. But it isn't easy to get right, so

>>>>> Spencer Graves >>>>> on Sun, 19 Jan 2020 21:35:04 -0600 writes: > 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

Ugh, sounds like competing priorities. * maintain type consistency * minimize storage (= current version, since 3.0.0) * maximize utility for large lambda (= proposed change) * keep user interface, and code, simple (e.g., it would be easy enough to add a switch that provided user control of int vs double return value) * backward compatibility On 2020-01-20 12:33 p.m., Martin Maechler

>>>>> Martin Maechler >>>>> on Tue, 21 Jan 2020 09:25:19 +0100 writes: >>>>> Ben Bolker >>>>> on Mon, 20 Jan 2020 12:54:52 -0500 writes: >> Ugh, sounds like competing priorities. > indeed. >> * maintain type consistency >> * minimize storage (= current version, since 3.0.0) >> *

There is a problem with `rpois'. It does seem to take care about the order of the arguments. This is an example: > rpois(n=1,lambda=2) [1] 3 > rpois(lambda=2,n=1) [1] 2 0 It obviously uses the first argument as the number of samples to be drawn, which is wrong. I used Version 0.49 Beta (April 23, 1997). Fredrik

There is a problem with `rpois'. It does seem to take care about the order of the arguments. This is an example: > rpois(n=1,lambda=2) [1] 3 > rpois(lambda=2,n=1) [1] 2 0 It obviously uses the first argument as the number of samples to be drawn, which is wrong. I used Version 0.49 Beta (April 23, 1997). Fredrik

Hi there, I need some helpo with one simulation. I have a matrix of 4x21 I want ro generate 100 random Chi2 distribution but inly from the first row of my matrix. This is what I try: Option (a): >lambda=1:100 >f=function(x)chisq(4,0,x) >lapply(lambda,f) It doesn't work! option(b): >m=mean(matrix[1,]) >x<-rpois(100,lambda=m) Works, but only generates a row of 25 values.

>>>>> Ben Bolker >>>>> on Mon, 20 Jan 2020 12:54:52 -0500 writes: > Ugh, sounds like competing priorities. indeed. > * maintain type consistency > * minimize storage (= current version, since 3.0.0) > * maximize utility for large lambda (= proposed change) > * keep user interface, and code, simple (e.g., it would be easy