構文
- 因子（x = character（）、レベル、ラベル=レベル、除外= NA、順序付け= is.ordered（x）、nmax = NA）
-
?factor実行する?factorオンラインでドキュメントを参照してください 。
備考
クラスfactor持つオブジェクトは、特定の特性セットを持つベクトルです。
- 内部的に
integerベクトルとして格納されます。 - これは、値の文字表現を示す
levels属性を保持します。 - そのクラスは
factorとして格納されます
説明するために、一連の色から1000個の観測ベクトルを生成しましょう。
set.seed(1)
Color <- sample(x = c("Red", "Blue", "Green", "Yellow"),
size = 1000,
replace = TRUE)
Color <- factor(Color)
上記のColor各特性を見ることができます：
#* 1. It is stored internally as an `integer` vector
typeof(Color)
[1] "integer"
#* 2. It maintains a `levels` attribute the shows the character representation of the values.
#* 3. Its class is stored as `factor`
attributes(Color)
$levels [1] "Blue" "Green" "Red" "Yellow" $class [1] "factor"
ファクタオブジェクトの主な利点は、データストレージの効率です。整数は文字よりも記憶に必要なメモリが少なくて済みます。このような効率性は、多くのコンピュータが現在のマシンよりもはるかに限られたリソースを持っていた場合に非常に望ましいものでした（要因の使用の背景にある動機の詳細な履歴については、 stringsAsFactors ：Unauthorized Biographyを参照してください）。メモリ使用の違いは、 Colorオブジェクトでも見ることができます。ご覧のように、 Colorを文字として保存するには、Factorオブジェクトの約1.7倍のメモリが必要です。
#* Amount of memory required to store Color as a factor.
object.size(Color)
4624 bytes
#* Amount of memory required to store Color as a character
object.size(as.character(Color))
8232 bytes
整数をレベルにマッピングする
ファクタの内部的な計算はオブジェクトを整数と見なしますが、人間が消費する表現は文字レベルです。例えば、
head(Color)
[1] Blue Blue Green Yellow Red Yellow Levels: Blue Green Red Yellow
人間の理解の方が簡単です
head(as.numeric(Color))
[1] 1 1 2 4 3 4
Rが文字表現を内部整数値にマッチさせる方法の概略図は次のとおりです。
head(levels(Color)[as.numeric(Color)])
[1] "Blue" "Blue" "Green" "Yellow" "Red" "Yellow"
これらの結果を
head(Color)
[1] Blue Blue Green Yellow Red Yellow Levels: Blue Green Red Yellow
近代的な要素の使用
2007年に、Rは、文字ベクトルのメモリ負担を軽減した文字のハッシング方法を紹介しました（ stringsAsFactors ：Unauthorized Biography ）。文字が因子より1.7倍多くの記憶スペースを必要とすると判断した場合、それはRの最近のバージョンで計算されたことに注意してください。これは、文字ベクトルのメモリ使用が2007年より前に課税されたことを意味します。
近代的なRのハッシュ方法や現代のコンピュータのはるかに大きなメモリリソースのおかげで、文字の値を格納する際のメモリ効率の問題は非常に小さな問題になりました。 Rコミュニティにおける一般的な態度は、ほとんどの状況での因子に対する文字ベクトルの選択です。要素からのシフトの主な原因は次のとおりです。
- 非構造化および/または緩やかに制御された文字データの増加
- ユーザーがキャラクターではなく因子を扱っていることを忘れてしまったときに、ファクターが望みどおりに行動しない傾向
最初のケースでは、フリーテキストやオープンレスポンスフィールドを要素として保存するのは意味がありません。レベルごとに複数の観察を可能にするパターンは存在しない可能性があります。あるいは、データ構造が注意深く制御されていない場合、同じカテゴリ（例えば、「青」、「青」、および「青」）に対応する複数のレベルを得ることが可能である。そのような場合、多くの人は、因子に変換する前に、これらの矛盾を文字として管理することを好む（変換がまったく行われない場合）。
2番目のケースでは、ユーザーが文字ベクトルを扱っていると思っている場合、特定のメソッドが予期したとおりに応答しないことがあります。この基本的な理解は、スクリプトとコードをデバッグする際に混乱と不満を招くことがあります。厳密に言えば、これはユーザーの過ちとみなすことができますが、ほとんどのユーザーは要因を使用しないでこれらの状況を完全に回避することができます。
