GIỎ HÀNG: Lựa chọn công cụ dự đoán tốt nhất để phân tách khi mức tăng trong tạp chất giảm bằng nhau?


8

Câu hỏi của tôi liên quan đến cây phân loại . Xem xét ví dụ sau từ bộ dữ liệu Iris:

nhập mô tả hình ảnh ở đây

Tôi muốn chọn thủ công dự đoán tốt nhất cho lần phân chia đầu tiên. Theo thuật toán GIỎI, tính năng tốt nhất để phân tách là tính năng tối đa hóa việc giảm tạp chất phân vùng, còn được gọi là Gini gain:

GTôinTôiGmộtTôin(N,X)= =GTôinTôi(N)-|N1||N|GTôinTôi(N1)-|N2||N|GTôinTôi(N1)

Trong trường hợp là một tính năng nhất định, N là nút mà chia tay là được thực hiện, và N 1N 2 là hai nút con được tạo ra bằng cách tách N . | . | là số phần tử trong một nút.XNN1N2N|.|

, nơi K là số chủng loại trong nútGTôinTôi(N)= =1-Σk= =1Kpk2K

Bây giờ, vì thực hiện phân chia dựa trên chiều rộng cánh hoa (trục số 1) và chiều dài cánh hoa (trục số 2) mang lại cùng một phân vùng (tất cả các hoa Setosa được phân tách từ không phải Setosa), điểm số GinGain sẽ giống hệt nhau cho mỗi người dự đoán. Vậy làm thế nào để thuật toán GIỎI quyết định cái nào là tốt nhất?

Theo trực giác, người ta có thể thấy rằng việc tách trên chiều dài cánh hoa (2) có liên quan đến "lề" lớn nhất, do đó nên chọn chiều dài cánh hoa (đó thực sự là điều xảy ra khi thực hiện rparttrong R), nhưng không có gì trong đo lường tỷ suất lợi nhuận, vì vậy quyết định phải dựa trên một cái gì đó khác.GTôinTôiGmộtTôin

Chủ đề liên quan nhưng không có câu trả lời cho câu hỏi của tôi.

Chủ đề liên quan mà không có câu trả lời.

Câu trả lời:


8

Tôi thú nhận là một thông dịch viên mã c tầm thường và mã cũ này không thân thiện với người dùng. Điều đó nói rằng tôi đã xem qua mã nguồn và thực hiện những quan sát này khiến tôi khá chắc chắn để nói: "rpart theo nghĩa đen chọn cột biến đầu tiên và tốt nhất". Vì cột 1 và 2 tạo ra các phân tách kém hơn, petal.length sẽ là biến phân tách đầu tiên vì cột này nằm trước petal. Thong trong data.frame / matrix. Cuối cùng, tôi chỉ ra điều này bằng cách đảo ngược thứ tự cột sao cho petal.with sẽ là biến phân tách đầu tiên.

Trong tệp nguồn c "bsplit.c" trong mã nguồn cho rpart tôi trích dẫn từ dòng 38:

 * test out the variables 1 at at time
me->primary = (pSplit) NULL;
for (i = 0; i < rp.nvar; i++) {

... do đó lặp đi lặp lại trong một vòng lặp for bắt đầu từ i = 1 đến rp.nvar, một hàm mất sẽ được gọi để quét tất cả các phân tách bởi một biến, bên trong gini.c cho dòng "phân chia không phân loại" 230 phân tách được tìm thấy tốt nhất là cập nhật nếu một phân chia mới là tốt hơn. (Đây cũng có thể là chức năng mất do người dùng xác định)

if (temp < best) {
        best = temp;
        where = i;
        direction = lmean < rmean ? LEFT : RIGHT;
}

và dòng cuối cùng 323, sự cải thiện để phân chia tốt nhất bởi một biến được tính toán ...

*improve = total_ss - best

... Quay lại bsplit.c, cải tiến được kiểm tra nếu lớn hơn những gì đã thấy trước đó và chỉ được cập nhật nếu lớn hơn.

if (improve > rp.iscale)
rp.iscale = improve;        /* largest seen so far */

Ấn tượng của tôi về điều này là đầu tiên và tốt nhất (trong số các mối quan hệ có thể sẽ được chọn), bởi vì chỉ khi điểm dừng mới có điểm tốt hơn thì nó mới được lưu. Điều này liên quan đến cả điểm phá vỡ tốt nhất đầu tiên được tìm thấy và biến tốt nhất đầu tiên được tìm thấy. Điểm phá vỡ dường như không được quét đơn giản từ trái sang phải trong gini.c, vì vậy điểm phá vỡ buộc đầu tiên được tìm thấy có thể khó dự đoán. Nhưng các biến được quét rất dễ đoán từ cột đầu tiên đến cột cuối cùng.

Hành vi này khác với triển khai RandomForest trong đó trong classTree.c giải pháp sau được sử dụng:

/* Break ties at random: */
if (crit == critmax) {
    if (unif_rand() < 1.0 / ntie) {
        *bestSplit = j;
        critmax = crit;
        *splitVar = mvar;
    }
    ntie++;
}

cuối cùng tôi xác nhận hành vi này bằng cách lật các cột của mống mắt, sao cho petal. thong được chọn trước

library(rpart)
data(iris)
iris = iris[,5:1]  #flip/flop", invert order of columns columns
obj = rpart(Species~.,data=iris)
print(obj) #now petal width is first split 


1) root 150 100 setosa (0.33333333 0.33333333 0.33333333)  
  2) Petal.Width< 0.8 50   0 setosa (1.00000000 0.00000000 0.00000000) *
  3) Petal.Width>=0.8 100  50 versicolor (0.00000000 0.50000000 0.50000000)  
    6) Petal.Width< 1.75 54   5 versicolor (0.00000000 0.90740741 0.09259259) *
    7) Petal.Width>=1.75 46   1 virginica (0.00000000 0.02173913 0.97826087) *

... và lật lại lần nữa

iris = iris[,5:1]  #flop/flip", revert order of columns columns
obj = rpart(Species~.,data=iris)
print(obj) #now petal length is first split 
1) root 150 100 setosa (0.33333333 0.33333333 0.33333333)  
  2) Petal.Length< 2.45 50   0 setosa (1.00000000 0.00000000 0.00000000) *
  3) Petal.Length>=2.45 100  50 versicolor (0.00000000 0.50000000 0.50000000)  
    6) Petal.Width< 1.75 54   5 versicolor (0.00000000 0.90740741 0.09259259) *
    7) Petal.Width>=1.75 46   1 virginica (0.00000000 0.02173913 0.97826087) *

Cảm ơn bạn rất nhiều vì câu trả lời của bạn. Vì vậy, khi có nhiều hơn một yếu tố dự đoán tương ứng với sự phân chia tối ưu, cái đầu tiên được chọn, điều này không liên quan gì đến lợi nhuận. Loại có ý nghĩa sau tất cả.
Antoine

Thật thú vị khi tìm hiểu :) Tôi đoán rằng các lề không được triển khai thực sự trong nhiều mô hình cây vì các phân chia nhị phân thực chất không phải là tham số
Soren Havelund Welling

Có thể hữu ích khi đề cập rằng mã nguồn cho rpart cũng có thể được lấy từ bảng điều khiển R thông qua untar(download.packages(pkgs = "rpart",destdir = ".",type = "source")[,2]), sau đó mở srcthư mục trong thư mục làm việc hiện tại (từ luồng SO này ). Sau đó, mã cho một chức năng cụ thể có thể được xem bằng Notepad ++ .
Antoine

Và thuật toán dừng lại khi chia tách không dẫn đến bất kỳ cải tiến nào nữa cho tất cả các nút, phải không?
Antoine

Vâng. trong phân vùng.c dòng 80 isch: "Điều này khá hiếm - nhưng tôi không thể tìm thấy một sự phân chia đáng làm" ... cho biết hàm đệ quy mạo danh. Sau đây, nút được niêm phong và thuật toán đệ quy trở lại nút trước đó đang gọi return (0).
Soren Havelund Welling
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.