Mengapa ada nilai R ^ 2 (dan apa yang menentukannya) ketika lm tidak memiliki perbedaan dalam nilai prediksi?


10

Pertimbangkan kode R berikut:

example <- function(n) {
    X <- 1:n
    Y <- rep(1,n)
    return(lm(Y~X))
}
#(2.13.0, i386-pc-mingw32)
summary(example(7))    #R^2 = .1963
summary(example(62))   #R^2 = .4529
summary(example(4540)) #R^2 = .7832
summary(example(104))) #R^2 = 0
#I did a search for n 6:10000, the result for R^2 is NaN for
#n = 2, 4, 16, 64, 256, 1024, 2085 (not a typo), 4096, 6175 (not a typo), and 8340 (not a typo)

Melihat http://svn.r-project.org/R/trunk/src/appl/dqrls.f ) tidak membantu saya memahami apa yang sedang terjadi, karena saya tidak tahu Fortran. Dalam pertanyaan lain dijawab bahwa kesalahan toleransi mesin floating point yang harus disalahkan untuk koefisien untuk X yang dekat, tetapi tidak cukup 0.

lebih besar ketika nilailebih dekat ke 0. Tapi ...R2coef(example(n))["X"]

  1. Mengapa ada nilai sama sekali? R2
  2. Apa (secara spesifik) yang menentukannya?
  3. Mengapa perkembangan NaNhasil yang tampaknya tertib ?
  4. Mengapa pelanggaran perkembangan itu?
  5. Apa ini perilaku 'yang diharapkan'?

Catatan: 7's R ^ 2 harus 0,4542 untuk melihat sesuatu yang lebih konstruktif lihat jawaban saya. :-)

1
Nah, agar adil, pengguna seharusnya benar - benar tahu sesuatu tentang metode statistik sebelum menggunakan alat (tidak seperti, katakanlah, pengguna Excel (ok, maaf tentang suntikan murah)). Karena agak jelas bahwa R ^ 2 mendekati 1 sebagai kesalahan mendekati nol, kita tahu lebih baik daripada mengacaukan nilai NaN dengan batas fungsi. Sekarang, jika ada masalah dengan R ^ 2 yang menyimpang sebagai ynoise -> 0 (katakan, ganti pernyataan Y di atas dengan Y <- rep(1,n)+runif(n)*ynoise), itu akan menarik :-)
Carl Witthoft

@eznme: Saya pikir hasilnya spesifik mesin, atau setidaknya 32 atau 64 bit spesifik; Saya memiliki mesin 32-bit yang memberikan 0,1963 untuk 7, tetapi mesin 64-bit saya memberikan NaN. Menariknya, pada mesin 64-bit, R ^ 2 yang bukan NaN semuanya sangat dekat dengan 0,5. Masuk akal ketika saya memikirkannya, tetapi pada awalnya itu mengejutkan saya.
Aaron meninggalkan Stack Overflow

1
Anda sedang mempelajari kesalahan pembulatan presisi ganda. Lihatlah koefisien; misalnya apply(as.matrix(2:17), 1, function(n){example(n)$coefficients[-1]}),. (Hasil saya, pada Win 7 x64 Xeon, berkisar dari -8e-17 hingga + 3e-16; sekitar setengahnya adalah nol.) BTW, sumber Fortran tidak membantu: itu hanya pembungkus untuk dqrdc; itulah kode yang ingin Anda lihat.
whuber

1
R2

Jawaban:


6

Seperti yang dikatakan Ben Bolker, jawaban untuk pertanyaan ini dapat ditemukan dalam kode untuk summary.lm().

Inilah tajuknya:

function (object, correlation = FALSE, symbolic.cor = FALSE, 
    ...) 
{

Jadi, mari x <- 1:1000; y <- rep(1,1000); z <- lm(y ~ x)dan lihat ekstrak yang sedikit dimodifikasi ini:

    p <- z$rank
    rdf <- z$df.residual
    Qr <- stats:::qr.lm(z)
    n <- NROW(Qr$qr)
    r <- z$residuals
    f <- z$fitted.values
    w <- z$weights
    if (is.null(w)) {
        mss <- sum((f - mean(f))^2)
        rss <- sum(r^2)
    }
    ans <- z[c("call", "terms")]
    if (p != attr(z$terms, "intercept")) {
        df.int <- 1L
        ans$r.squared <- mss/(mss + rss)
        ans$adj.r.squared <- 1 - (1 - ans$r.squared) * ((n - 
            df.int)/rdf)
    }

0.4998923

Untuk menjawab pertanyaan dengan pertanyaan: apa yang kita dapat dari ini? :)

mssrssR2mssrss0/0NaN2^(1:k)


Pembaruan 1: Berikut ini adalah utas bagus dari R-help yang membahas beberapa alasan mengapa peringatan yang mengalir tidak dibahas dalam R.

Selain itu, T&J SO ini memiliki sejumlah pos menarik dan tautan bermanfaat mengenai underflow, aritmatika presisi lebih tinggi, dll.


8

Saya ingin tahu tentang motivasi Anda untuk mengajukan pertanyaan. Saya tidak dapat memikirkan alasan praktis mengapa perilaku ini penting; keingintahuan intelektual adalah alternatif (dan IMO jauh lebih masuk akal) alasan. Saya pikir Anda tidak perlu memahami FORTRAN untuk menjawab pertanyaan ini, tetapi saya pikir Anda perlu tahu tentang dekomposisi QR dan penggunaannya dalam regresi linier. Jika Anda memperlakukan dqrlssebagai kotak hitam yang menghitung dekomposisi QR dan mengembalikan berbagai informasi tentangnya, maka Anda mungkin dapat melacak langkah-langkah ... atau langsung saja summary.lmmenelusuri dan menelusuri untuk melihat bagaimana R ^ 2 dihitung. Khususnya:

mss <- if (attr(z$terms, "intercept")) 
          sum((f - mean(f))^2)
       else sum(f^2)
rss <- sum(r^2)
## ... stuff ...
ans$r.squared <- mss/(mss + rss)

Maka Anda harus kembali ke lm.fitdan melihat bahwa nilai-nilai yang dipasang dihitung sebagai r1 <- y - z$residuals(yaitu sebagai respons dikurangi residu). Sekarang Anda bisa mencari tahu apa yang menentukan nilai residu dan apakah nilai minus rata-ratanya adalah nol atau tidak, dan dari sana mencari tahu hasil komputasi ...


Keingintahuan intelektual adalah alasan utama pertanyaan saya. Seorang kolega melaporkan perilaku itu dan saya ingin melihat-lihat dan melihat apakah saya bisa mengetahuinya. Setelah saya menelusuri masalah di luar keahlian saya, saya memutuskan untuk mengajukan pertanyaan. Sebagai masalah praktis, terkadang analisis dilakukan secara batch, atau kesalahan lainnya terjadi, dan perilaku ini menurut saya 'aneh'.
russellpierce

1
mms dan rss adalah hasil dari z, yang merupakan nama dari objek lm di dalam summary.lm. Jadi, sebuah jawaban mungkin memerlukan penjelasan tentang dekomposisi QR, penggunaannya dalam regresi linier, dan secara khusus beberapa detail dekomposisi QR seperti yang dipakai dalam kode yang mendasari R untuk menjelaskan mengapa dekomposisi QR berakhir dengan perkiraan 0 daripada 0 itu sendiri. .
russellpierce

mssrssR2R2

R2

0

R2R2=1SSerrSStot


1
Bisakah Anda memberikan situasi praktis di mana perilaku ini penting?
Ben Bolker

3
@Brandon - Iterator memasukkan smiley ke sana dan Anda masih tersedu!
Carl Witthoft

2
@eznme Sementara kesalahan baik, cukup sulit untuk menangkap semua jenis tempat di mana masalah floating point muncul, terutama di dunia aritmatika IEEE-754. Pelajaran di sini adalah bahwa bahkan perhitungan roti dan mentega dengan R harus ditangani dengan hati-hati.
Iterator

2
Pertimbangan ini sangat penting karena dalam tulisannya, John Chambers (salah satu pencetus S dan karenanya "kakek" dari R) sangat menekankan penggunaan R untuk komputasi yang andal. Misalnya, lihat Chambers, Perangkat Lunak untuk Analisis Data: Pemrograman dengan R (Springer Verlag 2008): "perhitungan dan perangkat lunak untuk analisis data harus dapat dipercaya: mereka harus melakukan apa yang mereka klaim, dan terlihat melakukannya." [Di hlm. 3.]
whuber

2
Masalahnya adalah bahwa baik atau buruk, R-core tahan terhadap (seperti yang mereka lihat) memperindah kode dengan banyak, banyak pemeriksaan yang mencegat semua kasus sudut dan kemungkinan kesalahan pengguna yang aneh - mereka takut (saya pikir) bahwa itu akan (a) mengambil banyak waktu, (b) membuat basis kode lebih besar dan lebih sulit dibaca (karena ada ribuan kasus khusus ini), dan (c) memperlambat eksekusi dengan memaksa pemeriksaan semacam itu sepanjang waktu bahkan dalam situasi di mana perhitungan sedang diulang berkali-kali.
Ben Bolker
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.