Scikit-learn: Saran: Tambahkan dukungan untuk regresi logistik tanpa penalti

Anda harus memalsukannya dengan mengatur C di LogisticRegression ke sejumlah besar

Apa masalahnya dengan pendekatan itu?

Saya berasumsi bahwa itu tidak tepat dan lebih lambat daripada implementasi langsung dari regresi logistik yang tidak dihukum. Apakah aku salah?

Saya perhatikan bahwa pengaturan C terlalu tinggi, seperti berikut ini, akan menyebabkan LogisticRegression.fit hang. Tapi saya tidak tahu apakah ini bug atau hanya properti yang melekat pada algoritma dan implementasinya pada komputer 64-bit.

import numpy as np
from sklearn.linear_model import LogisticRegression

x = np.matrix([0, 0, 0, 0,  1, 1, 1, 1]).T
y =           [1, 0, 0, 0,  1, 1, 1, 0]

m = LogisticRegression(C = 1e200)
m.fit(x, y)
print m.intercept_, m.coef_

Saya perhatikan bahwa pengaturan C terlalu tinggi, seperti berikut ini, akan menyebabkan LogisticRegression.fit hang

Ya, inilah yang diharapkan karena masalahnya menjadi tidak wajar ketika C besar. Pemecah berulang lambat dengan masalah yang diajukan.

Dalam contoh Anda, algoritme membutuhkan waktu lama untuk mencapai toleransi yang diinginkan. Anda juga perlu meningkatkan tol atau hardcode max_iter .

@mblondel apakah ada alternatif untuk "pemecah berulang"?
Anda tidak akan mendapatkan opsi yang tidak diregulasi, bukan?

@Kodiologist mengapa Anda menginginkan ini?

Anda bertanya mengapa saya ingin melakukan regresi logistik tanpa regularisasi? Karena (1) kadang-kadang sampel cukup besar sebanding dengan jumlah fitur yang regularisasi tidak akan membeli apa pun dan (2) kadang-kadang koefisien yang paling cocok menarik, yang bertentangan dengan memaksimalkan akurasi prediktif.

Ya, itu adalah pertanyaan saya.

(1) tidak benar. Itu akan selalu membelikan Anda pemecah yang lebih cepat.

(2) lebih ke ranah analisis statistik, yang sebenarnya bukan fokus scikit-learn. Saya kira kita bisa menambahkan ini tetapi saya tidak tahu pemecah apa yang akan kita gunakan. Sebagai non-ahli statistik, saya bertanya-tanya apa bagusnya koefisien yang berubah dengan sedikit regularisasi.

Saya tidak bisa mengatakan banyak tentang (1) karena komputasi bukan keahlian saya. Untuk (2), saya seorang analis data dengan latar belakang statistik. Saya tahu bahwa scikit-learn berfokus pada pembelajaran mesin tradisional, tetapi menurut saya ini adalah paket Python terbaik untuk analisis data saat ini, dan saya pikir itu akan mendapat manfaat dari tidak membatasi dirinya sendiri _terlalu_ banyak. (Saya juga berpikir, mengikuti Larry Wasserman dan Andrew Gelman, bahwa statistik dan pembelajaran mesin akan saling diuntungkan dengan lebih banyak berbaur, tapi saya rasa itu adalah wormnya sendiri.) Semua koefisien akan berubah dengan regularisasi; itulah yang regularisasi tidak.

Saya tidak menentang menambahkan pemecah tanpa regularisasi. Kita dapat memeriksa apa yang akan baik, atau hanya jaminan dan menggunakan l-bfgs dan memeriksa sebelumnya jika tidak dikondisikan?

Ya, semua koefisien berubah dengan regularisasi. Sejujurnya aku penasaran apa yang ingin kamu lakukan dengan mereka setelah ini.

Hai,
Apa status topik ini? Saya akan sangat tertarik dengan Regresi Logistik yang tidak dihukum. Dengan cara ini nilai-p akan berarti sesuatu secara statistik. Kalau tidak, saya harus terus menggunakan R untuk kasus penggunaan seperti itu...
Terima kasih,
Alex

Atau model negara?

Pemecah apa yang Anda sarankan untuk diterapkan? Apa bedanya dengan pemecah yang sudah kita miliki dengan C -> infty ?

Pemecah apa yang Anda sarankan untuk diterapkan? Apa bedanya dengan pemecah yang sudah kita miliki dengan C -> infty ?

Anda dapat mencoba melihat R atau statsmodels untuk mendapatkan ide. Saya tidak terbiasa dengan metode mereka, tetapi mereka cukup cepat dan tidak menggunakan regularisasi sama sekali.

Ya statsmodels melakukan pekerjaan juga jika Anda menggunakan algoritma QR untuk inversi matriks. Kasus penggunaan saya adalah seputar interpretasi model. Untuk kinerja, saya pasti akan menggunakan regularisasi.

Saya tidak berpikir kita perlu menambahkan pemecah baru ... Regresi logistik tidak menikmati solusi bentuk tertutup, yang berarti bahwa statsmodel harus menggunakan pemecah berulang dari beberapa jenis juga (tebakan saya akan menjadi kuadrat terkecil yang diulang berulang, tetapi saya belum cek). Pengaturan C=np.inf (atau setara alpha=0 ) pada prinsipnya harus bekerja dengan pemecah kami saat ini. Rekomendasi saya adalah beralih ke pemecah L-BFGS atau Newton-CG, karena liblinear memang bisa sangat lambat dalam pengaturan ini. Mungkin kita dapat menambahkan opsi solver="auto" dan secara otomatis beralih ke salah satu opsi ini ketika C=np.inf atau setara penalty="none" ?

kami mengubah pemecah default menjadi lbfgs di #10001 fwiw

Untuk orang-orang yang benar-benar menginginkan regresi logistik yang tidak teratur (seperti saya). Saya harus puas menggunakan statsmodels dan membuat kelas pembungkus yang meniru SKLearn API.

Ada pembaruan tentang ini? Ini adalah penghalang besar atas kesediaan saya untuk merekomendasikan scikit-belajar kepada orang-orang. Juga sama sekali tidak jelas bagi orang-orang yang datang dari perpustakaan lain bahwa scikit-learn melakukan regularisasi secara default dan tidak ada cara untuk menonaktifkannya.

@shermstats saran bagaimana cara meningkatkan dokumentasi tentang itu? Saya setuju bahwa itu mungkin tidak terlalu jelas.
Apakah l-bfgs mengizinkan C=np.inf ?

Anda dapat menentukan C=np.inf , meskipun itu akan memberi Anda hasil yang sama dengan C=large value . Pada contoh yang saya coba, ini lebih cocok daripada statsmodel dan statsmodel gagal menyatu dengan sebagian besar seed acak lainnya:

from sklearn.datasets import make_classification
from sklearn.linear_model import LogisticRegression
import statsmodels.api as sm

X, y = make_classification(random_state=2)
lr = LogisticRegression(C=np.inf, solver='lbfgs').fit(X, y)


logit = sm.Logit(y, X)
res = logit.fit()

Optimization terminated successfully.
         Current function value: 0.167162
         Iterations 10

from sklearn.metrics import log_loss
log_loss(y, lr.predict_proba(X))
log_loss(y, res.predict(X))

0.16197793224715606
0.16716164149746823

Jadi saya berpendapat kita harus mendokumentasikan bahwa Anda bisa mendapatkan model yang tidak dihukum dengan menyetel C besar atau ke np.inf.

Saya sarankan menambahkan ke docstring dan panduan pengguna
"Model LogisticRegression dikenai sanksi secara default. Anda dapat memperoleh model yang tidak dihukum dengan menyetel C=np.inf dan solver='lbfgs'."

itu memberikan kecocokan yang lebih baik daripada statsmodel dan statsmodel gagal menyatu dengan sebagian besar benih acak lainnya

glm R's lebih matang dan dapat membuat perbandingan yang lebih baik.

Saya sarankan menambahkan ke docstring dan panduan pengguna
"Model LogisticRegression dikenai sanksi secara default. Anda dapat memperoleh model yang tidak dihukum dengan menyetel C=np.inf dan solver='lbfgs'."

Mengapa tidak menambahkan allow penalty = "none" a la SGDClassifier ?

@Kodiologist Saya tidak menentang menambahkan penalty="none" tetapi saya tidak yakin apa manfaatnya menambahkan opsi yang berlebihan.
Dan saya pikir kami akan menyambut perbandingan glm. Saya tidak terlalu akrab dengan glm jadi saya mungkin bukan orang yang baik untuk melakukan perbandingan. Namun, kami mengoptimalkan log-loss sehingga seharusnya tidak ada perbedaan. Mungkin mereka menerapkan pemecah yang berbeda sehingga memiliki patokan akan menyenangkan.

Saya tidak menentang menambahkan penalty="none" tetapi saya tidak yakin apa manfaatnya menambahkan opsi yang berlebihan.

1. Menjadi lebih jelas bagaimana mendapatkan model yang tidak dihukum.
2. Menjadi lebih jelas bagi pembaca kode apa yang coba dilakukan oleh model yang tidak dihukum.
3. Ini memungkinkan sklearn untuk mengubah implementasi model yang tidak diatur di masa depan tanpa melanggar kode orang.

Jika Anda merasa itu menambah kemampuan untuk ditemukan maka kami dapat menambahkannya, dan 3 adalah poin yang valid (meskipun kami sebenarnya tidak dapat benar-benar mengubahnya tanpa penghentian mungkin, lihat perubahan pemecah saat ini).
Apakah Anda ingin mengirim PR?

Saya tidak memiliki setelan bulat untuk itu; maaf.

@Kodiologist setidaknya Anda mengajari saya sebuah idiom yang tidak saya ketahui;)

Jadi terbuka untuk kontributor: tambahkan penalty='none' sebagai opsi. Juga mungkin periksa pemecah apa yang mendukung ini / efisien dengan ini (liblinear mungkin tidak) dan batasi untuk pemecah itu.

Saya sarankan menambahkan ke docstring dan panduan pengguna
"Model LogisticRegression dikenai sanksi secara default. Anda dapat memperoleh model yang tidak dihukum dengan menyetel C=np.inf dan solver='lbfgs'."

Ini terdengar masuk akal bagi saya. Saya juga menyarankan untuk menebalkan kalimat pertama karena itu benar-benar mengejutkan bagi orang-orang yang berasal dari pembelajaran mesin atau lingkungan analisis data lainnya.

@shermstats Jadi @Kodiologist menyarankan untuk menambahkan penalty="none" untuk membuatnya lebih eksplisit, yang hanya akan menjadi alias untuk C=np.inf . Masuk akal bagi saya untuk membuat ini lebih eksplisit dengan cara ini. Apakah Anda memiliki pemikiran tentang itu?
Maka itu akan menjadi apa yang ada di dokumentasi. Dan saya setuju bahwa berani mungkin ide yang bagus.
Saya pikir untuk seseorang dengan latar belakang ML ini (mungkin?) diharapkan, untuk seseorang dengan latar belakang statistik, ini tampaknya sangat mengejutkan.

Tepat! Saya memiliki latar belakang statistik dan telah bekerja dengan banyak orang statistik yang berasal dari R atau bahkan antarmuka tunjuk dan klik, dan perilaku ini sangat mengejutkan kami. Saya pikir untuk saat ini penalty=None (tidak yakin tentang "none" vs. None ) adalah solusi yang baik. Di masa depan, kita harus memiliki pemecah terpisah yang dipanggil secara otomatis untuk regresi logistik yang tidak dihukum untuk mencegah masalah yang dijelaskan @mblondel .

Maaf, masalah apa yang Anda maksud? Kami beralih ke l-bfgs secara default, dan kami juga dapat secara internal mengalihkan solver ke l-bfgs secara otomatis jika seseorang menentukan penalty='none' (seringkali None adalah token khusus yang kami gunakan untuk parameter usang, tetapi kami telah berhenti melakukan itu. Masih 'tidak ada' akan lebih konsisten dengan sisa perpustakaan).
Kami tetap membutuhkan solver="auto" jadi mengubah pemecah berdasarkan penalti seharusnya tidak menjadi masalah.

Masalah ini , yang mengacu pada algoritma berulang menjadi sangat lambat untuk C besar. Saya bukan ahli analisis numerik, tetapi jika l-bfgs mencegahnya melambat maka itu terdengar seperti solusi yang tepat. penalty='none' juga terdengar seperti cara yang tepat untuk menangani ini.

@shermstats ya, dengan l-bfgs ini sepertinya tidak menjadi masalah. Saya belum menjalankan tolok ukur yang luas, dan tidak akan punya waktu untuk melakukannya. Jika ada yang ingin menjalankan benchmark, itu akan sangat membantu.

Jika penalti='none' harus disertakan, saya sarankan untuk menambahkan peringatan yang sama ke panduan pengguna tentang colinear X seperti untuk OLS (khususnya untuk fitur one-hot encoded).