It's only documented to work for princomp.formula; other methods do not know
about na.action.
-pd
On 29 May 2014, at 22:10 , Ravi Varadhan wrote:
> Hi,
> It may be my misunderstanding, but it seems that the "na.action" in the
> princomp() function for principal components analysis does not wo
Thank you, Peter. Now I see that.
I still think the documentation of `na.action' can be made more explicit to
state that this option is only used for princomp.formula.
Best regards,
Ravi
-Original Message-
From: peter dalgaard [mailto:pda...@gmail.com]
Sent: Friday, May 30, 2014 5:1
Hi,
Unless someone is planning to change Stangle to include inline
expressions (which I am *not* advocating), I think that relying on
side-effects within an \Sexpr construction is a bad idea. So, my own
coding style is to restrict my use of \Sexpr to calls of the form
\Sexpr{show.the.value.of
> Even more important than choosing between whatever(...)
> or foo::whatever(...), you should import that function
> from the foo package by putting
>
> importFrom(foo, whatever)
>
> or
>
> import(foo)
>
> in your NAMESPACE file.
>
> The 1st form also kind of document what function comes from w
Ravi,
You mean something /more/ explicit than the Usage section, wherein
`na.action` only exists in the formula method?
I doubt we'd want RCore to go down the road of documenting all the
arguments that do/don't work with particular methods included in an Rd
file, beyond the Usage section.
G
On
Gavin,
I agree w.r.t. documenting all arguments. However, it is quite natural to
expect that something as basic as `na.actionâ would work for more generally
than with only one particular type of usage. Why should the behavior of
princomp(x, â¦), where x is a data matrix or dataframe be any
Really? I can't recall a single instance where such things worked outside
of formula methods for functions and I tend to equate its use with the
standard non-standard evaluation idiom.
It could easily remove the NAs, but you wanted na.exclude which means
remove them whilst computing but put them b
Hi Yihui,
I agree with you (and your comments in [knitr issue 784]) that it seems
wrong for R CMD check to be using tangle (purl, etc) as a way to check R
code in a vignette, when the standard and expected way to check the
vignette is already to knit / Sweave the vignette.
I also agree with the p
Hi Hadley,
On 05/30/2014 07:06 AM, Hadley Wickham wrote:
Even more important than choosing between whatever(...)
or foo::whatever(...), you should import that function
from the foo package by putting
importFrom(foo, whatever)
or
import(foo)
in your NAMESPACE file.
The 1st form also ki
> There is at least one subtle consequence to keep in mind when doing
> this. Of course, whatever choice you make, if the whatever() function
> moves to a different package, this breaks your package.
> However, if you explicitly import the function, your package will
> break at load-time (which is
I think there are several aspects to Yihue's post and some simple
workarounds/long solutions to the issues:
1. For the reasons argued, I would agree that 'R CMD check'
incorrectly assumes that tangled code script should be able to run
without errors. Instead I think it should only check the synta
Sorry, it should be Yihui and nothing else. /Henrik
On Fri, May 30, 2014 at 10:15 AM, Henrik Bengtsson
wrote:
> I think there are several aspects to Yihue's post and some simple
> workarounds/long solutions to the issues:
>
> 1. For the reasons argued, I would agree that 'R CMD check'
> incorrec
This isn't likely to make much difference in most cases, but calling a
function via :: can incur up to about twice the overhead on average
compared to calling an imported function
> fun1
function ()
file_ext("text.txt")
> fun2
function ()
tools::file_ext("text.txt")
> microbenchmark(fun1(), time
On Fri, May 30, 2014 at 6:55 PM, Hervé Pagès wrote:
[...]
> There is at least one subtle consequence to keep in mind when doing
> this. Of course, whatever choice you make, if the whatever() function
> moves to a different package, this breaks your package.
> However, if you explicitly import t
On 05/30/2014 10:00 AM, Hadley Wickham wrote:
There is at least one subtle consequence to keep in mind when doing
this. Of course, whatever choice you make, if the whatever() function
moves to a different package, this breaks your package.
However, if you explicitly import the function, your pack
> Finally, now that the use of a NAMESPACE became mandatory (well, this
> happened a few years ago), advocating systematic use of foo::whatever()
> without explicitly importing the function sounds a little bit like an
> heroic act of resistance ;-)
I don't think that's at all true - for most other
On Fri, May 30, 2014 at 9:08 PM, Hadley Wickham wrote:
> > Finally, now that the use of a NAMESPACE became mandatory (well, this
> > happened a few years ago), advocating systematic use of foo::whatever()
> > without explicitly importing the function sounds a little bit like an
> > heroic act of
On Fri, May 30, 2014 at 9:17 PM, Gábor Csárdi
wrote:
> On Fri, May 30, 2014 at 9:08 PM, Hadley Wickham
> wrote:
>
>> > Finally, now that the use of a NAMESPACE became mandatory (well, this
>> > happened a few years ago), advocating systematic use of foo::whatever()
>> > without explicitly impo
Hi Gabe,
On 05/30/2014 11:34 AM, Gabriel Becker wrote:
This isn't likely to make much difference in most cases, but calling a
function via :: can incur up to about twice the overhead on average
compared to calling an imported function
> fun1
function ()
file_ext("text.txt")
> fun2
function (
Using `::` does add some overhead - on the order of 5-10 microseconds
on my computer. Still, it would take 100,000 calls to add 0.5-1 second
of delay.
microbenchmark(
base::identity(1),
identity(1),
unit = "us"
)
# Unit: microseconds
# expr min lq median uqmax nev
Hi Kevin,
Personally I also avoid code that have side effects in the inline
expressions, but I think there are legitimate use cases in which
inline expressions have side effects. This discussion was motivated by
Carl's knitcitations package, as well as another question on
StackOverflow (http://sta
21 matches
Mail list logo
