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 that for, say, lambda>1e6, rpois should return rnorm(., >> lambda, sqrt(lambda)). > But need to implement carefully; rpois should always return a > non-negative integer, whereas rnorm always returns numeric... >????? Thanks for the reply. ????? However, I think it's not acceptable to get an NA from a number that cannot be expressed as an integer.? Whenever a randomly generated number would exceed .Machine$integer.max, the choice is between returning NA or a non-integer numeric.? Consider: > 2*.Machine$integer.max [1] 4294967294 > as.integer(2*.Machine$integer.max) [1] NA Warning message: NAs introduced by coercion to integer range ????? I'd rather have the non-integer numeric. ????? Spencer
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: > >> > >> > >> 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)). > > But need to implement carefully; rpois should always return a > > non-negative integer, whereas rnorm always returns numeric... > > > > Thanks for the reply. > > > However, I think it's not acceptable to get an NA from a number > that cannot be expressed as an integer. Whenever a randomly generated > number would exceed .Machine$integer.max, the choice is between > returning NA or a non-integer numeric. Consider: > > > > 2*.Machine$integer.max > [1] 4294967294 > > as.integer(2*.Machine$integer.max) > [1] NA > Warning message: > NAs introduced by coercion to integer range > > > I'd rather have the non-integer numeric. > > > Spencer > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Sent from Gmail Mobile [[alternative HTML version deleted]]
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 Sun, Jan 19, 2020 at 10:45 AM Spencer Graves > <spencer.graves at prodsyse.com <mailto:spencer.graves at prodsyse.com>> wrote: > > > > 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 that for, say, lambda>1e6, rpois should return > rnorm(., > >> lambda, sqrt(lambda)). > > But need to implement carefully; rpois should always return a > > non-negative integer, whereas rnorm always returns numeric... > > > > ?????? Thanks for the reply. > > > ?????? However, I think it's not acceptable to get an NA from a > number > that cannot be expressed as an integer.? Whenever a randomly > generated > number would exceed .Machine$integer.max, the choice is between > returning NA or a non-integer numeric.? Consider: > > > ?> 2*.Machine$integer.max > [1] 4294967294 > ?> as.integer(2*.Machine$integer.max) > [1] NA > Warning message: > NAs introduced by coercion to integer range > > > ?????? I'd rather have the non-integer numeric. > > > ?????? Spencer > > ______________________________________________ > R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > Sent from Gmail Mobile