Rで新しい環境をいつ設定しますか

r
Rで新しい環境をいつ設定しますか

Rプログラミングスタイルの議論ごとに、自分のすべてのカスタム関数を新しい環境に入れてアタッチするという人がいたことがあります。 また、R環境がハッシュテーブルとして使用される可能性があることも覚えています。 これはいいスタイルですか? データ/関数をいつ新しい環境に置きたいですか? または、the.GlobalEnvを使用しますか?

*編集*質問の2番目の部分を戻します:異なる環境で同じ名前の変数を検査する方法は?

  18  2


ベストアンサー

MartinMächlerは、 `.Rdata`ファイルを検索パスに添付するという文脈で提案したが、これは_attach_()を検討したいと思うかもしれない1回の時間であると示唆していますが、Qは本質的に同じです。

利点は、誤って上書きされる可能性のある関数でグローバル環境を乱雑にしないことです。 私はこの悪いスタイルを呼び出すことはしませんが、カスタム関数を独自のRパッケージに組み込む方が良いかもしれません。 はい、これはパッケージ構造をセットアップし、パッケージをインストールできるようにするためのドキュメントを提供するオーバーヘッドが少しかかりますが、長期的にはこれがより良いソリューションです。 roxygenのようなツールを使用すると、このプロセスは起動しやすくなります。

個人的には、Rを使用してから10年以上経っても環境をいじる必要はありません。データのロード、処理、分析を行う文書化されたスクリプトは、これまでずっとクリーンアップしてきました。

” ” ‘

質問の2番目の部分(現在削除されている)に対する別の提案は、 `with()`を使用することです(@Joshuaの例に続きます)。

> .myEnv <- new.env()
> .myEnv$a <- 2
> a <- 1
> str(a)
 num 1
> ls.str(.myEnv, a)
a :  num 2
> str(.myEnv$a)
 num 2
> with(.myEnv, a)
[1] 2
> a
[1] 1

11


データとコードのエコシステムが十分に大きくなり、環境内でそれを分離することを検討している場合は、パッケージを作成する方が良いでしょう。 パッケージを使用すると、次のことがさらにサポートされます。

  • 分離することで大きく複雑になっているプロジェクトを管理する
    コードとデータをファイルに保存することで、一度に掘り下げる必要が少なくなります。

  • パッケージを使用すると、作業を他の人に簡単に引き渡すことができます
    彼らはあなたのコードとデータを使用できます。

  • パッケージは、ドキュメントとレポートの追加サポートを提供します。

Rのパッケージのセットアップはとても簡単で、 `package.skeleton()`を呼び出すだけで、作業中のすべてのプロジェクトでコードとデータがパッケージに保存されます。

環境を使用するのは、副作用や変数名が私のコードと交差しないように、通常は他の誰かが作成したスクリプトなどのコードの実行を分離する必要があるときだけです。 これは、 `evalq(source( ‘someScript.R’、local = TRUE)、SomeEnvironment)`で行います。

6


2番目の質問(削除したこと)に答えるには、 ls.str`を使用するか、 $ `で環境内のオブジェクトにアクセスします。

.myEnv <- new.env()
.myEnv$a <- 2
a <- 1
str(a)
ls.str(.myEnv, a)
str(.myEnv$a)

4


タイトルとURLをコピーしました