因素

factor 的物件是具有特定特徵集的向量。

  1. 它在內部儲存為 integer 向量。
  2. 它維護一個 levels 屬性,顯示值的字元表示。
  3. 它的類儲存為 factor

為了說明,讓我們從一組顏色生成 1,000 個觀測值的向量。

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:未經授權的傳記 )。即使在我們的 Color 物件中,也可以看到記憶體使用的差異。如你所見,將 Color 儲存為字元所需的記憶體大約是因子物件的 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:未經授權的傳記 )。請注意,當我們確定字元需要的儲存空間是因子的 1.7 倍時,這是在最新版本的 R 中計算的,這意味著在 2007 年之前,字元向量的記憶體使用更加沉重。

由於現代 R 中的雜湊方法和現代計算機中更大的儲存器資源,儲存字元值的儲存效率問題已經減少到非常小的問題。在大多數情況下,R 社群中的主流態度是對特徵向量的偏好。偏離因素的主要原因是

  1. 非結構化和/或鬆散控制的字元資料的增加
  2. 當使用者忘記她正在處理因素而不是角色時,因素趨勢不符合要求

在第一種情況下,將自由文字或開放響應欄位儲存為因子是沒有意義的,因為不太可能存在允許每個級別多於一個觀察的模式。或者,如果未仔細控制資料結構,則可以獲得對應於相同類別的多個級別(例如藍色藍色藍色)。在這種情況下,許多人更願意在轉換為因素之前將這些差異作為字元進行管理(如果完全轉換)。

在第二種情況下,如果使用者認為她正在使用角色向量,則某些方法可能無法按預期進行響應。在嘗試除錯指令碼和程式碼時,這種基本理解可能會導致混淆和挫折。嚴格來說,這可能被認為是使用者的錯誤,但大多數使用者都樂於避免使用因素並完全避免這些情況。