Pytanie:
W jaki sposób Poisson GLM może pracować z danymi nieliczbowymi (dane dotyczące szybkości)?
William Chiu
2015-08-20 05:54:35 UTC
view on stackexchange narkive permalink

Moje pytanie jest powiązane, ale nie takie samo jak następujące: Dopasowanie GLM Poissona w R - problemy ze stawkami a licznikami

Oto kilka fałszywych danych: 

  ### niektóre fałszywe danex = c (1:14) y = c (0, 1, 2, 3, 1, 4, 9, 18, 23, 31, 20, 25, 37, 45) y_rate <- y / 1000

Użyję GLM Poisson z linkiem do dziennika, aby przewidzieć y_rate : 

  ### modelpois_mdl <- glm (y_rate ~ x, family = poisson (link = "log")) podsumowanie (pois_mdl)

Wykreśl dopasowanie: 

  ### plotplot (x, y_rate) lines (x, pois_mdl $itted.values)

Dziwię się, że Poisson glm () dopuszcza wartości niecałkowite w zmiennej zależnej. Rysunki z rozkładu Poissona są zawsze liczbami całkowitymi (niezależnie od wartości parametru średniej). Dlaczego glm () nie wysadza?

http://stats.stackexchange.com/questions/70054/ wydaje się zduplikowane
Dwa odpowiedzi:
gung - Reinstate Monica
2015-08-20 06:52:34 UTC
view on stackexchange narkive permalink

Nie wiem, dlaczego glm () nie wybucha. Aby to zrozumieć, musisz rozpakować cały kod źródłowy. (Ponadto, jeśli twoje jedyne pytanie dotyczy tego, jak działa kod R, to pytanie jest tutaj nie na temat.)

Mogę powiedzieć, że nie modelujesz poprawnie stawek. Jeśli chcesz modelować stawki zamiast zliczeń, musisz uwzględnić przesunięcie w formule modelu. (W CV jest ładna dyskusja na temat tego, czym jest przesunięcie: Kiedy używać przesunięcia w regresji Poissona?) Na przykładzie kodu wyglądałoby następująco: 

  pois_mdl2 <- glm (y ~ x + offset (log (rep (1000,14))), family = poisson (link = "log"))

Zauważ, że chociaż oszacowania współczynników są takie same, błędy standardowe są zupełnie inne: 

  podsumowanie (pois_mdl2) $ współczynniki # Estimate Std. Wartość błędu z Pr (> | z |) # (Intercept) -6,5681214 0,25118701 -26,14833 1,029521e-150 # x 0,2565236 0,02203911 11,63947 2,596237e-31summary (pois_mdl) $ współczynniki # Estimate Std. Wartość błędu z Pr (> | z |) # (Intercept) -6,5681214 7,9431516 -0,8268911 0,4082988 # x 0,2565236 0,6969324 0,3680753 0,7128171
Matthew Drury
2015-08-20 07:49:39 UTC
view on stackexchange narkive permalink

Chociaż nie polecam zaglądania do kodu źródłowego glm dla tych, którzy chcą zachować swoje zdrowie psychiczne, przyjrzałem się kodowi źródłowemu glm . Powodem, dla którego R nie wysadza, wydaje się być to, że po prostu nie zawraca sobie głowy wykonywaniem testów obronnych, które prawdopodobnie powinien.

Główna iteracyjnie ponownie ważona pętla najmniejszych kwadratów działa przy użyciu metod dołączone do obiektu family odpowiedniego typu. W tym przypadku jest to poisson:

  > poi <- poisson () > class (poi) [1] „family”

Ten obiekt rodziny ma wszystko, czego potrzebuje glm, aby dopasować go do modelu, na przykład: 

  > poi $ linkfun (1) [1] 0> poi $ linkinv (1) [1] 2.718282

Kolejna, oto pochodna odwrotnego łącza: 

  > poi $ mu.eta (1) [1] 2.718282

Dane y pojawiają się w linii 258: 

  dev <-sum (dev.resids (y, mu, weights))

Niestety dev.resids w ogóle nie obchodziło, czy y jest dodatnią liczbą całkowitą: 

  > poi $ dev.resid (1.5, 1, 1) [1] 0.2163953

Więc myślę, że R nie wysadza, ponieważ nie pomyślał by wysadzić.

+1, lol.Był powód, dla którego sam nie zajrzałem do kodu źródłowego ;-).
Sprawdzenie, gdyby istniało, najprawdopodobniej wystąpiłoby w `poisson () $ initialize`, który sprawdza tylko, czy argumenty` y` są nieujemne. Porównaj to z funkcją „binomial () $ initialize”, która wraz z obsługą możliwej jedno- lub dwukolumnowej specyfikacji argumentu „y” sprawdza również, czy są one wartościami całkowitymi.
Niezłe @Mark, Brakowało mi tego.


ⓘ
To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...