search for: 1e10

...ngs as errors anyway) but for the sake of other useRs who may get bitten, perhaps we should be more explicit that backwards-compatibility won't be preserved under certain use patterns, for example: # works (with warning) in R 3.6.2 but fails (with error) in R-devel: vapply(list(1e9, 1e10), ?????? function(lambda) { ????????? rpois(1L, lambda) ?????? }, ?????? FUN.VALUE = integer(1L) ?????? ) # in R-devel, a little extra work to achieve a warning as before: vapply(list(1e9, 1e10), ?????? function(lambda) { ????????? tmp <- rpois(1L, lam...

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 replaced my call to rpois with a call to the following: ?rpois. <- funct...

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

...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 nee...

...------------------------------------ > > >> 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&...

...------------------------------------------------------------------------ > >> 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(., > >>...

>>>>> Benjamin Tyner >>>>> on Mon, 20 Jan 2020 08:10:49 -0500 writes: > 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 >>

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

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

...gt; 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...

On 2020-01-22 02:54, Martin Maechler wrote: >>>>>> 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

..., weights = weights,..." Details : --------- E is a vector of survival times (or censored times), 1-F is a vector of '0's, and cov is a matrix of 1 column. There are altogether 75 observations. Tried : ------ P <- try(surv.cox <- coxph(Surv(E, 1-F) ~ cov, coxph.control(iter.max=1e10, eps = 1e-03))) Output (from above command) : ----------------------------- Call: coxph(formula = Surv(E, F) ~ cov, data = coxph.control(iter.max = 1e+10, eps = 0.001)) coef exp(coef) se(coef) z p cov -0.233 0.793 0.11 -2.11 0.035 Likelihood ratio test=4.51 on 1 df,...

...t; >>>> >? ? ?>> ? ????? 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? >>>> >? ? ?>&g...

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

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

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

...esult; } For "shorter" vectors, the result is as expected: > dyn.load("altrep_int_region.so") > .Call("integer_get_region", 1:1e9, 0L, 10L) [1] 1 2 3 4 5 6 7 8 9 10 But not for "longer" vectors: > .Call("integer_get_region", 1:1e10, 0L, 10L) [1] 0 1072693248 0 1073741824 0 1074266112 [7] 0 1074790400 0 1075052544 Am I doing something wrong or is this a bug? I am using > R.version.string [1] "R version 3.5.2 (2018-12-20)" Thanks Ralf -- Ralf Stubner Senior Softw...

Hi, > 1e10+5i [1] 1e+10+0e+00i > Im(1e10+5i) [1] 5 maybe little better... --- R-3.5.1.orig/src/main/complex.c 2018-03-26 07:02:25.000000000 +0900 +++ R-3.5.1/src/main/complex.c 2018-07-10 12:50:42.523874767 +0900 @@ -381,6 +381,7 @@ r->i = fround(pow10 * x->i, digits)/pow10; } else...

...the same precision? The imaginary part of 0 looks a bit odd when log10(real/imag) >=~ getOption("digits"), but I'm not sure it is awful. Some people might expect the same number of significant digits in the two parts. > 1e7+4i [1] 10000000+0i > 1e7+5i [1] 10000000+0i > 1e10 + 1000i [1] 1e+10+0e+00i > getOption("digits") [1] 7 > options(digits=4) > 1e4+4i [1] 10000+0i > 1e7+1000i [1] 10000000+0i > version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status...