Dear R-Devel,
I've run into an issue with a package (vcfR) that uses file.access to check
a file is readable before opening it. The issue is actually in base R
though. I've looked into the package code, and it calls file.access(path,
mode = 4). I've created a minimal working example of the code in
Hi,
The man page for base::unique.matrix() and base::unique.array() says
that MARGIN is expected to be a single integer. OTOH the code in charge
of checking the user supplied MARGIN is:
if (length(MARGIN) > ndim || any(MARGIN > ndim))
stop(gettextf("MARGIN = %d is invalid for dim = %
And for a starker example of this (documented) inconsistency,
arithmetic addition is not commutative:
> NA + NaN
[1] NA
> NaN + NA
[1] NaN
On Mon, Jul 2, 2018 at 5:32 PM, Duncan Murdoch wrote:
> On 02/07/2018 11:25 AM, Jan Gorecki wrote:
>> Hi,
>> base::mean is not consistent in terms of h
On 02/07/2018 11:25 AM, Jan Gorecki wrote:
Hi,
base::mean is not consistent in terms of handling NA/NaN.
Mean should not depend on order of its arguments while currently it is.
The result of mean() can depend on the order even with regular numbers.
For example,
> x <- rep(c(1, 10^(-15)), 100
On 02/07/2018 11:22 AM, Witold E Wolski wrote:
Hello,
Thank you for the questions as well as remaining me of the default
parameters in the yaml session.
Indeed this seems to be the solution.
But how would I assign package data as a default parameter?
So originally I thought to render the markd
The current behavior is as documented. See ?NA, which says
"Numerical computations using ‘NA’ will normally result in ‘NA’: a
possible exception is where ‘NaN’ is also involved, in which case
either might result"
--Ista
On Mon, Jul 2, 2018 at 11:25 AM, Jan Gorecki wrote:
> Hi,
> base:
Hi,
base::mean is not consistent in terms of handling NA/NaN.
Mean should not depend on order of its arguments while currently it is.
mean(c(NA, NaN))
#[1] NA
mean(c(NaN, NA))
#[1] NaN
I created issue so in case of no replies here status of it can be looked up
at:
https://bugs.r-p
On 02/07/2018 10:34 AM, Gabe Becker wrote:
Witold,
Vignettes, in the package sense, are and must be entirely self-contained as
far as I know. They are run automatically in completely clean R sessions.
I'm not sure a parameterized vignette makes a ton of sense within that
context.
The defaults
Hello,
Thank you for the questions as well as remaining me of the default
parameters in the yaml session.
Indeed this seems to be the solution.
But how would I assign package data as a default parameter?
So originally I thought to render the markdown with :
data(sample_analysis)
data(skylineco
On 02/07/2018 10:30 AM, Witold E Wolski wrote:
Hello,
I have a package which includes some parameterized r-markdown report
which I would also like to build as package vignettes.
Is there a way to run the parameterized vignette creation with the
package build or package check?
Doesn't the usu
Witold,
Vignettes, in the package sense, are and must be entirely self-contained as
far as I know. They are run automatically in completely clean R sessions.
I'm not sure a parameterized vignette makes a ton of sense within that
context.
Can you explain what you would want to have happen when the
Hello,
I have a package which includes some parameterized r-markdown report
which I would also like to build as package vignettes.
Is there a way to run the parameterized vignette creation with the
package build or package check?
Thank you
--
Witold Eryk Wolski
___
12 matches
Mail list logo
