[Rd] [External] Re: rpois(9, 1e10)

Martin Maechler m@ech|er @end|ng |rom @t@t@m@th@ethz@ch
Wed Jan 22 09:55:09 CET 2020


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

    > Last night, it came to my mind that we should do what we have
    > been doing in quite a few places in R, the last couple of years:

    > Return integer when possible, and switch to return double when
    > integers don't fit.

    > We've been doing so even for  1:N  (well, now with additional ALTREP wrapper),
    > seq(), and even the fundamental  length()  function.

    > So I sat down and implemented it .. and it seemed to work
    > perfectly:  Returning the same random numbers as now, but
    > switching to use double (instead of returning NAs) when the
    > values are too large.

    > I'll probably commit that to R-devel quite soonish.
    > Martin

Committed in svn rev 77690; this is really very advantageous, as
in some cases / applications or even just limit cases, you'd
easily get into overflow sitations.

The new R 4.0.0 behavior is IMO  "the best of" being memory
efficient (integer storage) in most cases (back compatible to R 3.x.x) and
returning desired random numbers in large cases (compatible to R <= 2.x.x).

Martin

    >> On 2020-01-20 12:33 p.m., Martin Maechler wrote:
    >>>>>>>> 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
    >>> >> "design bug" that  rpois() {and similar} must return return typeof() "integer".
    >>> >> 
    >>> >> More strongly, I'm actually pretty convinced they should return
    >>> >> (integer-valued) double instead of NA_integer_   and for that
    >>> >> reason should always return double:
    >>> >> Even if we have (hopefully) a native 64bit integer in R,
    >>> >> 2^64 is still teeny tiny compared .Machine$double.max
    >>> >> 
    >>> >> (and then maybe we'd have .Machine$longdouble.max  which would
    >>> >> be considerably larger than double.max unless on Windows, where
    >>> >> the wise men at Microsoft decided to keep their workload simple
    >>> >> by defining "long double := double" - as 'long double'
    >>> >> unfortunately is not well defined by C standards)
    >>> >> 
    >>> >> Martin
    >>> >> 
    >>> > Martin if you are in favor, then certainly no objection from me! ;-)
    >>> 
    >>> > So now what about other discrete distributions e.g. could a similar 
    >>> > enhancement apply here?
    >>> 
    >>> 
    >>> >> rgeom(10L, 1e-10)
    >>> >  [1]         NA 1503061294         NA         NA 1122447583         NA
    >>> >  [7]         NA         NA         NA         NA
    >>> > Warning message:
    >>> > In rgeom(10L, 1e-10) : NAs produced
    >>> 
    >>> yes, of course there are several such distributions.
    >>> 
    >>> 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.  This halves the storage requirements for large
    >>> simulations.
    >>> 
    >>> and what I've been suggesting is to revert this change
    >>> (svn rev r60225-6) which was purposefully and diligently done by
    >>> a fellow R core member, so indeed must be debatable. 
    >>> 
    >>> Martin
    >>> 
    >>> ______________________________________________
    >>> R-devel using r-project.org mailing list
    >>> https://stat.ethz.ch/mailman/listinfo/r-devel
    >>> 

    >> ______________________________________________
    >> R-devel using r-project.org mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel

    > ______________________________________________
    > R-devel using r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel



More information about the R-devel mailing list