Hi Andreas,
On 3/26/21 8:48 PM, Andreas Kersting wrote:
> Hi Dirk, > > Sure, let me try to explain: > > CRAN ran the tests of my
> package
using R which was configured > --with-valgrind-instrumentation > 0.
Valgrind reported many errors > related to the use of supposedly
uninitialized memory
Hi Tomas,
Thanks for sharing your view on this! I understand your point, but still I
think that the current situation is somewhat unfortunate:
I would argue that mmap() is a natural candidate to be used together with
allocVector3(); it is even mentioned explicitly here:
https://github.com/wch/
Hi all,
As always, thank you all for your incredible work maintaining and improving
R.
mdl <- lm(data = mtcars,
mpg ~ I(poly(disp, 2)))
predict(mdl, newdata = data.frame(disp = c(120, 120)))
#> Error in poly(disp, 2): 'degree' must be less than number of unique
points
predict(mdl, new
Any particular reason you're using I() around your poly()? That
looks weird to me ... and it works fine if you don't do that ... {AND,
I think your result is *incorrect* when you have 3 observations in your
response}.
Basically, you have managed to short-circuit the (admittedly) obscure
Hi Simon,
Yes, if this was acceptable on CRAN, I would agree that calling
VALGRIND_MAKE_MEM_DEFINED() in my code would be sufficient.
But since Tomas said, "So I think that your code using your custom allocator
needs to initialize allocated memory to be correct. If your allocator
initializes
While profiling some C code, I rolled my own nchar function which
appears to be much faster than base R's (25 times faster for a 10M
length vector). Obviously base::nchar provides significantly more
features than my barebones function (C snippet below); however, for
argument type = "bytes" it seem
