Re: [Rd] [External] Re: rpois(9, 1e10)
> 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
> 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@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as-cran issue ==> set _R_CHECK_LENGTH_1_* settings!
> Abby Spurdle > on Tue, 21 Jan 2020 09:15:39 +1300 writes: >> I do want to entice people to have a long look beyond closed >> source OS into the world of Free Software where not only R is >> FOSS (Free and Open Source Software) but (all / almost) all the >> tools you use are of that same spirit. >> >> Best, >> Martin > I've reconsidered. > You're 100% correct. Thank you. > I'm planning to try ReactOS. > (Hope it works...) > Thanks Martin, great advice... Well, to choose ReactOS () instead of a version of Linux (there have some Linux distributions that have aimed for being close to Windows in their "look and feel") is much braver and more risky, but then, your learning experience, including possibly being the first one to run R there (?) ((possibly even learning how to *build* R there from the sources ??)), will feel more frontier-like and self determined than just following the Linux crowd ;-) ;-) :-) Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] class() |--> c("matrix", "arrary") -- and S3 dispatch
Dear Martin,
What's the ETA for _R_CLASS_MATRIX_ARRAY_=TRUE to become the new
unconditional behavior in R devel? Thanks!
H.
On 11/21/19 08:57, Martin Maechler wrote:
>
> TLDR: This is quite technical, still somewhat important:
> 1) R 4.0.0 will become a bit more coherent: a matrix is an array
> 2) Your package (or one you use) may be affected.
>
>
>> Martin Maechler
>> on Fri, 15 Nov 2019 17:31:15 +0100 writes:
>
>> Pages, Herve
>> on Thu, 14 Nov 2019 19:13:47 + writes:
>
> >> On 11/14/19 05:47, Hadley Wickham wrote:
> >>> On Sun, Nov 10, 2019 at 2:37 AM Martin Maechler ... wrote:
>
> []
>
> > Note again that both "matrix" and "array" are special [see ?class]
> as
> > being of __implicit class__ and I am considering that this
> > implicit class behavior for these two should be slightly
> > changed
> >
> > And indeed I think you are right on spot and this would mean
> > that indeed the implicit class
> > "matrix" should rather become c("matrix", "array").
>
> I've made up my mind (and not been contradicted by my fellow R
> corers) to try go there for R 4.0.0 next April.
>
> >>> I can't seem to find the previous thread, so would you mind being a
> >>> bit more explicit here? Do you mean adding "array" to the implicit
> >>> class?
>
> >> It's late in Europe ;-)
>
> >> That's my understanding. I think the plan is to have class(matrix())
> >> return c("matrix", "array"). No class attributes added to matrix or
> >> array objects.
>
> >> It's all what is needed to have inherits(matrix(), "array") return
> TRUE
> >> (instead of FALSE at the moment) and S3 dispatch pick up the foo.array
> >> method when foo(matrix()) is called and there is no foo.matrix method.
>
> > Thank you, Hervé! That's exactly the plan.
>
> BUT it's wrong what I (and Peter and Hervé and ) had assumed:
>
> If I just change the class
> (as I already did a few days ago, but you must activate the change
>via environment variable, see below),
>
> S3 dispatch does *NOT* at all pick it up:
> "matrix" (and "array") are even more special here (see below),
> and from Hadley's questions, in hindsight I now see that he's been aware
> of that and I hereby apologize to Hadley for not having thought
> and looked more, when he asked ..
>
> Half an hour ago, I've done another source code commit (svn r77446),
> to "R-devel" only, of course, and the R-devel NEWS now starts as
>
>
>
> CHANGES IN R-devel:
>
>USER-VISIBLE CHANGES:
>
> • intention that the next non-patch release should be 4.0.0.
>
> • R now builds by default against a PCRE2 library
>...
>...
>
> • For now only active when environment variable
>_R_CLASS_MATRIX_ARRAY_ is set to non-empty, but planned to be the
>new unconditional behavior when R 4.0.0 is released:
>
>Newly, matrix objects also inherit from class "array", namely,
>e.g., class(diag(1)) is c("matrix", "array") which invalidates
>code (wrongly) assuming that length(class(obj)) == 1, a wrong
>assumption that is less frequently fulfilled now. (Currently
>only after setting _R_CLASS_MATRIX_ARRAY_ to non-empty.)
>
>S3 methods for "array", i.e., .array(), are now also
>dispatched for matrix objects.
>
>
> (where only the very last 1.5 lines paragraph is new.)
>
> Note the following
> (if you use a version of R-devel, with svn rev >= 77446; which
> you may get as a binary for Windows in about one day; everyone
> else needs to compile for the sources .. or wait a bit, maybe
> also not much longer than one day, for a docker image) :
>
>
>> Sys.unsetenv("_R_CLASS_MATRIX_ARRAY_") # ==> current R behavior
>> class(m <- diag(1))
> [1] "matrix"
>> Sys.setenv("_R_CLASS_MATRIX_ARRAY_" = "BOOH !") # ==> future R behavior
>> class(m)
> [1] "matrix" "array"
>>
>> foo <- function(x) UseMethod("foo")
>> foo.array <- function(x) "made in foo.array()"
>> foo(m)
> [1] "made in foo.array()"
>> Sys.unsetenv("_R_CLASS_MATRIX_ARRAY_")# ==> current R behavior
>> foo(m)
> Error in UseMethod("foo") :
>no applicable method for 'foo' applied to an object of class "c('matrix',
> 'double', 'numeric')"
>
>> Sys.setenv("_R_CLASS_MATRIX_ARRAY_" = TRUE) # ==> future R behavior
>> foo(m)
> [1] "made in foo.array()"
>> foo.A <- foo.array ; rm(foo.array)
>> foo(m)
> Error in UseMethod("foo") :
>no applicable method for 'foo' applied to an object of class "c('matrix',
> 'array', 'double', 'numeric')"
>>
>
> So, with my commit 77446, the _R_CLASS_MATRIX_ARRAY_
> environment variable also changes
