Magrittr pipe in R関数

Question

（1）スピードと（2）効果的にデバッグするという観点から、R関数の中でmagrittrパイプを使用することは有利でない場合がありますか？

Answer 1

関数の内部でパイプを使用すると長所と短所があります。最大の利点は、コードを読むときに関数内で何が起こっているのかを見るのが簡単だということです。最大の欠点は、エラーメッセージが解釈しにくくなり、パイプがRの評価ルールのいくつかを壊すことです。

例を示します。 mtcarsデータセットに無意味な変換を加えたいとしましょう。ここでは、それが役に立つ何もしていないにもかかわらず、

library(tidyverse) 
tidy_function <- function() { 
    mtcars %>% 
    group_by(cyl) %>% 
    summarise(disp = sum(disp)) %>% 
    mutate(disp = (disp^4)/10000000000) 
} 

は、あなたはすべての段階で何が起こっているかはっきり見ることができます...パイプでそれを行うことができる方法です。今まで最も一般的な方法

​​

...それは私たちと同じ結果が得られるにもかかわらず、読み

base_function <- function() { 
    mutate(summarise(group_by(mtcars, cyl), disp = sum(disp)), disp = (disp^5)/10000000000) 
} 

がはるかに困難...のはDagwoodサンドイッチアプローチを使用して、タイムコードを見てみましょうパイプやDagwoodサンドイッチのいずれかを使用しないよう中間変数への各ステップの結果を保存することです...

intermediate_function <- function() { 
    x <- mtcars 
    x <- group_by(x, cyl) 
    x <- summarise(x, disp = sum(disp)) 
    mutate(x, disp = (disp^5)/10000000000) 
} 

最後の関数より

より読みやすく、Rはあなたにもう少し詳細なを与えるだろうエラーが発生したときの情報それは従来の評価基準に従います。ここでも、それは他の二つの機能と同じ結果を...与え

all.equal(tidy_function(), intermediate_function()) 
# [1] TRUE 

あなたが特にスピードについて尋ね、その者は、それらのそれぞれ1000倍を実行することにより、これらの3つの機能を比較してみましょう...

library(microbenchmark) 
timing <- 
    microbenchmark(tidy_function(), 
       intermediate_function(), 
       base_function(), 
       times = 1000L) 
timing 
#Unit: milliseconds 
        #expr  min  lq  mean median  uq  max neval cld 
     #tidy_function() 3.809009 4.403243 5.531429 4.800918 5.860111 23.37589 1000 a 
#intermediate_function() 3.560666 4.106216 5.154006 4.519938 5.538834 21.43292 1000 a 
     #base_function() 3.610992 4.136850 5.519869 4.583573 5.696737 203.66175 1000 a 

この簡単な例でも、パイプは他の2つのオプションよりも少し遅いです。

結論

が、それはあなたがコードを書くための最も快適な方法だ場合、あなたの関数でパイプを使用する自由を感じます。問題が発生し始めた場合や、人間が可能な限り速くなるようにコードを作成する必要がある場合は、別のパラダイムに切り替えます。