Hi Gabriel,
thanks for your detailed explanation, that definitely clarifies the design
choices that were made in setting up the ALTREP framework and I can see how
those choices make sure existing code won't break.
My specific use-case for wanting to check whether a vector is an ALTREP is
the foll
On 5/31/19 08:41, Toby Hocking wrote:...
> In my opinion install.packages should stop with an error (instead of a
> warning) if this happens.
Totally agree with that.
Best,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Cen
Hi Mark,
So depending pretty strongly on what you mean by "ALTREP aware", packages
aren't necessarily supposed to be ALTREP aware. What I mean by this is that
as of right now, ALTREP objects are designed to be interacted with by
non-ALTREP-implementing package code, *more-or-less *exactly as stand
thanks for clearing that up, so these methods are actually not meant to be
exported on Windows and OSX?
Some of the ALTREP methods that now use 'attribute_hidden' would be very
useful to packages that aim to be ALTREP aware, should the currently
(exported) API be considered final?
thanks for your
Hello,
A solution is to use package cubature, both unscaled and scaled versions
return the correct result, 3.575294.
But the performance penalty is BIG. This is because the number of
evaluations is much bigger.
library(cubature)
cubintegrate(f, -Inf, 0, method = "hcubature")
#$integral
#[1]
I think a more productive conversation could be: what additions to R
would allow for user-defined types / classes that behave just like the
built-in vector types? As a motivating example, one cannot currently
use the 64bit integer objects from bit64 to subset data frames:
> library(bit64); mtca
On Tue, 4 Jun 2019, Mark Klik wrote:
> Hello,
>
> I'm developing a package (lazyvec) that makes full use of the ALTREP
> framework (R >= 3.6.0).
> One application of the package is to wrap existing ALTREP vectors in a new
> ALTREP vector and pass all calls from R to the contained object. The
> pur
FWIW, innoextract extracts the contents of the installer just fine.
Iñaki
On Tue, 4 Jun 2019 at 17:40, Steven Penny wrote:
>
> On Mon, Jun 3, 2019 at 6:54 PM Marc Schwartz wrote:
> > I am on macOS primarily, albeit, I have run both Windows and Linux routinely
> > in years past.
>
> With all due
> Juan Telleria Ruiz de Aguirre
> on Mon, 3 Jun 2019 06:50:17 +0200 writes:
> Thank you Martin for giving to know and developing 'Rmpfr' library for
> unlimited size integers (GNU C GMP) and arbitrary precision floats (GNU C
> MPFR):
> https://cran.r-project.org/packa
> David Scott
> on Tue, 4 Jun 2019 12:32:03 +1200 writes:
> This must have been there for a while>
> In the datasets package, the help for airquality says:
> A data frame with 154 observations on 6 variables.
> But:
>> str(airquality)
> 'data.frame': 153
Hi all,
The call parallel::makeCluster(1L) hangs infinitely on my MacOS machine which
seems to be already reported by some people (e.g.,
https://stat.ethz.ch/pipermail/r-devel/2018-February/075565.html).
However, the solutions posted on SO, GH or R-devel do not work in my case.
So far, I unsucc
On Mon, Jun 3, 2019 at 8:04 PM Duncan Murdoch wrote:
> I don't recall anyone asking for the zip in the 17 years after that
> change, until now (though I haven't been paying attention lately, since
> I retired from building the binaries a couple of years ago).
>
> If you think it's worthwhile to do
On Mon, Jun 3, 2019 at 6:54 PM Marc Schwartz wrote:
> I am on macOS primarily, albeit, I have run both Windows and Linux routinely
> in years past.
With all due respect, then you have no business in this thread.
> That being said, these days, I do run Windows 10 under a Parallels VM on
> macOS, a
On Mon, Jun 3, 2019 at 4:11 PM Marc Schwartz wrote:
> I have not tried it, but if that is the case here, you may be able to use the
> normal R binary installer, but adjust the default install options when
> prompted, allowing you to customize the install location and other parameters,
> that may be
Hello,
In May 2018 there was some R-devel discussion about a bug in
foreign:::writeForeignSAS. See here:
https://stat.ethz.ch/pipermail/r-devel/2018-May/076220.html
and it resulted in a patch. See:
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17256
And I see the changes in Subversi
Dear Everyone,
The document of `tsdiag’ says
> These tests are sometimes applied to the residuals from an ARMA(p, q) fit, in
> which case the references suggest a better approximation to the
> null-hypothesis distribution is obtained by setting fitdf = p+q, provided of
> course that lag > fitd
Hello,
I'm developing a package (lazyvec) that makes full use of the ALTREP
framework (R >= 3.6.0).
One application of the package is to wrap existing ALTREP vectors in a new
ALTREP vector and pass all calls from R to the contained object. The
purpose of this is to provide a diagnostic framework f
On 03/06/2019 9:16 p.m., Steven Penny wrote:
On Mon, Jun 3, 2019 at 8:04 PM Duncan Murdoch wrote:
I don't recall anyone asking for the zip in the 17 years after that
change, until now (though I haven't been paying attention lately, since
I retired from building the binaries a couple of years ago
18 matches
Mail list logo
