Beeinflusst das Aufnehmen der Protokolle der abhängigen und / oder unabhängigen Variablen die Modellfehler und damit die Gültigkeit der Inferenz?

Ich sehe oft Leute (Statistiker und Praktiker), die Variablen ohne einen zweiten Gedanken transformieren. Ich hatte immer Angst vor Transformationen, weil ich befürchte, dass sie die Fehlerverteilung ändern und somit zu ungültigen Schlussfolgerungen führen könnten, aber es ist so häufig, dass ich etwas falsch verstehen muss.

Angenommen, ich habe ein Modell, um Ideen zu korrigieren

Y = β_{0} \exp X^{β_{1}} + ϵ, ϵ \sim N (0, σ^{2})

$Y=\beta_0\exp X^{\beta_1}+\epsilon,\ \epsilon\sim\mathcal{N}(0,\sigma^2)$

Dies könnte im Prinzip von NLS angepasst werden. Fast immer sehe ich jedoch Leute, die Protokolle nehmen und passen

\log Y = \log β_{0} + β_{1} \log X + ? ? ? \Rightarrow Z = α_{0} + β_{1} W + ? ? ?

$\log{Y}=\log\beta_0+\beta_1\log{X}+???\Rightarrow Z=\alpha_0+\beta_1W+???$

Ich weiß, dass dies von OLS angepasst werden kann, aber ich weiß nicht, wie ich die Konfidenzintervalle für die Parameter berechnen soll, geschweige denn Vorhersageintervalle oder Toleranzintervalle.

Und das war ein sehr einfacher Fall: Betrachten Sie diesen (für mich) wesentlich komplexeren Fall, in dem ich nicht die Form der Beziehung zwischen und a priori annehme , sondern versuche, sie aus Daten abzuleiten, z. ein GAM. Betrachten wir die folgenden Daten: $Y$ $X$

library(readr)
library(dplyr)
library(ggplot2)

# data
device <- structure(list(Amplification = c(1.00644, 1.00861, 1.00936, 1.00944, 
1.01111, 1.01291, 1.01369, 1.01552, 1.01963, 1.02396, 1.03016, 
1.03911, 1.04861, 1.0753, 1.11572, 1.1728, 1.2512, 1.35919, 1.50447, 
1.69446, 1.94737, 2.26728, 2.66248, 3.14672, 3.74638, 4.48604, 
5.40735, 6.56322, 8.01865, 9.8788, 12.2692, 15.3878, 19.535, 
20.5192, 21.5678, 22.6852, 23.8745, 25.1438, 26.5022, 27.9537, 
29.5101, 31.184, 32.9943, 34.9456, 37.0535, 39.325, 41.7975, 
44.5037, 47.466, 50.7181, 54.2794, 58.2247, 62.6346, 67.5392, 
73.0477, 79.2657, 86.3285, 94.4213, 103.781, 114.723, 127.637, 
143.129, 162.01, 185.551, 215.704, 255.635, 310.876, 392.231, 
523.313, 768.967, 1388.19, 4882.47), Voltage = c(34.7732, 24.7936, 
39.7788, 44.7776, 49.7758, 54.7784, 64.778, 74.775, 79.7739, 
84.7738, 89.7723, 94.772, 99.772, 109.774, 119.777, 129.784, 
139.789, 149.79, 159.784, 169.772, 179.758, 189.749, 199.743, 
209.736, 219.749, 229.755, 239.762, 249.766, 259.771, 269.775, 
279.778, 289.781, 299.783, 301.783, 303.782, 305.781, 307.781, 
309.781, 311.781, 313.781, 315.78, 317.781, 319.78, 321.78, 323.78, 
325.78, 327.779, 329.78, 331.78, 333.781, 335.773, 337.774, 339.781, 
341.783, 343.783, 345.783, 347.783, 349.785, 351.785, 353.786, 
355.786, 357.787, 359.786, 361.787, 363.787, 365.788, 367.79, 
369.792, 371.792, 373.794, 375.797, 377.8)), .Names = c("Amplification", 
"Voltage"), row.names = c(NA, -72L), class = "data.frame")

Wenn ich die Daten ohne logarithmische Transformation von , sehen das resultierende Modell und die Vertrauensgrenzen nicht so gut aus: $X$

# build model
model <- gam(Voltage ~ s(Amplification, sp = 0.001), data = device)

# compute predictions with standard errors and rename columns to make plotting simpler 
Amplifications <- data.frame(Amplification = seq(min(APD_data$Amplification), 
                                           max(APD_data$Amplification), length.out = 500))
predictions <- predict.gam(model, Amplifications, se.fit = TRUE)
predictions <- cbind(Amplifications, predictions)
predictions <- rename(predictions, Voltage = fit) 

# plot data, model and standard errors
ggplot(device, aes(x = Amplification, y = Voltage)) +
  geom_point() +
  geom_ribbon(data = predictions, 
              aes(ymin = Voltage - 1.96*se.fit, ymax = Voltage + 1.96*se.fit), 
              fill = "grey70", alpha = 0.5) +
  geom_line(data = predictions, color = "blue")

Aber wenn ich nur logarithmisch transformiere , scheinen die Vertrauensgrenzen für viel kleiner zu werden: $X$ $Y$

log_model <- gam(Voltage ~ s(log(Amplification)), data = device)
# the rest of the code stays the same, except for log_model in place of model

Offensichtlich ist etwas faul. Sind diese Konfidenzintervalle zuverlässig? BEARBEITEN Dies ist nicht einfach ein Problem des Glättungsgrades, wie es in einer Antwort vorgeschlagen wurde. Ohne die Protokolltransformation ist der Glättungsparameter

> model$sp
s(Amplification) 
     5.03049e-07

Mit der Log-Transformation ist der Glättungsparameter tatsächlich viel größer:

>log_model$sp
s(log(Amplification)) 
         0.0005156608

Dies ist jedoch nicht der Grund, warum die Konfidenzintervalle so klein werden. In der Tat werden durch die Verwendung eines noch größeren Glättungsparameters sp = 0.001unter Vermeidung jeglicher Protokolltransformation die Oszillationen reduziert (wie im Fall der Protokolltransformation), aber die Standardfehler sind in Bezug auf den Fall der Protokolltransformation immer noch sehr groß:

smooth_model <- gam(Voltage ~ s(Amplification, sp = 0.001), data = device)
# the rest of the code stays the same, except for smooth_model in place of model

Was passiert im Allgemeinen mit den Konfidenzintervallen , wenn ich die Transformation und / oder protokolliere ? Wenn es im allgemeinen Fall nicht möglich ist, quantitativ zu antworten, akzeptiere ich eine Antwort, die für den ersten Fall (das Exponentialmodell) quantitativ ist (dh eine Formel zeigt) und für den zweiten Fall mindestens ein handwedelndes Argument liefert (GAM-Modell). $X$ $Y$

— DeltaIV
quelle

Wenn Sie die Variablen "transformieren", passen Sie ein völlig anderes Modell an. Die zugehörigen Konfidenzintervalle sind gültig, wenn das transformierte Modell gültig ist (z. B. in Ihrem ersten Beispiel, wenn die Fehler auf der ursprünglichen Skala tatsächlich multiplikativ sind). Sie unterscheiden sich nur, weil es sich um unterschiedliche Modelle handelt. Sie müssen vorsichtig sein, wenn Sie dann die Transformation invertieren müssen: ist keine unvoreingenommene Vorhersage für ein neues (es ist jedoch median-unvoreingenommen ).

{\hat{β}}_{0} {\tilde{X}}^{\hat{β_{1}}}

$\hat{\beta}_0\tilde{X}^\hat{\beta_1}$

Y

$Y$

— Chris Haug

Ich kenne Gam nicht und die Dokumentation bezieht sich auf ein Buch, das ich nicht habe. Aufgrund des Verhaltens der Sache gehe ich jedoch davon aus, dass versucht wird, eine unbekannte Funktion mithilfe von Polynomen zu approximieren. Polynome können Formen wie y = ln (x) schlecht approximieren, und dies erklärt möglicherweise die schlechte Leistung von Gam hier. Das Klingeln, das Hugh Perkins erwähnt, kommt nicht von einer Sprungfunktion oder einer unzureichenden Glättung (wie ich wieder vermute), sondern von der Tatsache, dass Polynome klingeln, wenn logarithmische Funktionen angenähert werden. Ihre Daten sehen für mich logarithmisch und nicht polynomisch aus. Sie können mit Vuongs Test testen.

— Bill

@ Bill vielen Dank für die Eingaben. GAM verwendet keine Polynome, sondern bestrafte Regressionssplines, die nicht alle Probleme von Polynomen aufweisen (siehe zum Beispiel "Eine Einführung in das statistische Lernen" von James et al.). Tatsächlich kann eine der verfügbaren Spline-Basen mgcvals eine Summe von Begriffen vom Typ - ich kann sie ausprobieren. Was ist Voung's Test? Können Sie weitere Details angeben? Wissen Sie, ob es in einem R-Paket implementiert ist?

x^{2} \log (x)

$x^2\log(x)$

— DeltaIV

Chris Haugs Punkt wird als Re-Transformations-Problem bezeichnet. Zu diesem Thema gibt es auf der Website eine Reihe von Fragen und Antworten. Ich habe einige Fragen allgemein zu diesem Thema beantwortet, eine finden Sie hier: stats.stackexchange.com/questions/55692/…

— Bill

Hier (glaube ich) habe ich verlinkt: herc.research.va.gov/include/page.asp?id=cost-regression

— Bill

Sie sehen ein Klingeln, das das Ergebnis des Durchlaufens einer Hochfrequenzänderung, dh einer Schrittfunktion, durch ein Tiefpassfilter, dh das GAM, ist.

Wenn Sie die Protokolltransformation anwenden, ändern Sie den Gradienten des nahezu vertikalen Abschnitts des Diagramms auf der linken Seite so, dass er etwas weniger steil ist, weniger implizite hohe Frequenzen aufweist und der Klingeleffekt verschwindet.

Bearbeiten: einige Bilder vom Klingeln hier: /electronics/79717/what-can-reduce-overshoot-and-ringing-on-a-simple-square-wave-pulse-generator

Edit2: Beachten Sie, dass eine zunehmende Glättung das Klingeln erhöhen würde , da die Glättung im Wesentlichen das Tiefpassfilter ist, das das Klingeln verursacht. Was das Klingeln reduzieren würde, wäre zum Beispiel: 1. Entfernen Sie die Punkte in der ansteigenden Klippenkante links und passen Sie sie wieder an, oder 2. Reduzieren Sie die Glättung oder 3. Reduzieren Sie die Frequenz / erhöhen Sie die Wellenlänge / erhöhen Sie die Grenzfrequenz der Glättung .

Sie können sehen, dass der Rest des Diagramms mehr oder weniger geradlinig ist, wenn Sie das Klippenbit entfernen. Warum passt das GAM also eine Sinuswelle durch diese Punkte? Dies liegt ausschließlich daran, dass der Teil mit den Klippen einen sehr hohen Gradienten erzwingt, der dann zu einem nachfolgenden Überschwingen führt.

Edit3: Wenn ich es wäre, würde ich versuchen, eine Transformation zu finden, die den Graphen in eine ungefähr gerade Linie verwandelt. Ich bin mir nicht ganz sicher, wie diese Transformation aussehen würde, aber es sieht so aus, als wäre der Graph fast eine flache Linie, asymptotisch für ~ 380 oder so. Dies ist eine stärkere Nichtlinearität als zB log, die flach wird, aber nicht ganz so schnell, denke ich. Vielleicht so etwas wie ein inverses Sigmoid? Sigmoid ist:

y = \frac{1}{1 + \exp (- x)}

$y = \frac{1}{1 + \exp(-x)}$

... und sieht aus wie (aus Wikipedia https://en.wikipedia.org/wiki/Sigmoid_function )

Inverses Sigmoid ist die logitFunktion, https://en.wikipedia.org/wiki/Logit :

f (x) = \log (\frac{1}{1 - x})

$f(x) = \log \left( \frac{1}{1-x} \right)$

Vielleicht könnte eine damit verbundene Transformation oder eine parametrisierte Version davon den Graphen näher an eine gerade Linie bringen und somit für statistische Standardtechniken zugänglicher sein?

— Hugh Perkins
quelle

Wenn das, was Sie sagen, richtig ist, sollte ich in der Lage sein, das gleiche Ergebnis zu erzielen, indem ich einfach den Glättungsparameter des GAM von Hand erhöhe, anstatt gamihn durch Kreuzvalidierung auswählen zu lassen. Interessant: Ich werde das testen. Ich schätze die Einsicht (+1), aber sie beantwortet nicht die ursprüngliche Frage nach der Auswirkung von Log-Transformationen auf die Konfidenzintervalle.

— DeltaIV

Ihre Antwort ist nicht korrekt oder zumindest unvollständig. Wie ich in meinem Experiment bewiesen habe, ist die Auswirkung der Protokolltransformation auf die Konfidenzintervalle nicht auf die erhöhte Glättung zurückzuführen. Wenn ich keine Protokolltransformation mache, aber noch mehr Glättung anwende, erhalte ich Konfidenzintervalle, die viel größer sind. Siehe meine bearbeitete Frage.

— DeltaIV

fügte einige Gedanken zum Effekt der Änderung der Glättung beim Klingeln hinzu; und eine mögliche Verwendung von, logitum den Graphen in etwas zu verwandeln, das näher an einer geraden Linie liegt

— Hugh Perkins

In meinen Experimenten zur Reduzierung der Glättung wurde das Klingeln erhöht , wenn Sie mit Klingeln die Schwingungen meinen: Ich kann die Frage jetzt nicht bearbeiten, werde es aber nächste Woche tun. Mein Problem sind jedoch die Konfidenzintervalle, nicht die Regressionskurve: Ihre Antwort deckt sie nicht ab.

— DeltaIV

Eine Beschreibung zum Abrufen von Konfidenzintervallen für OLS finden Sie auf Wikipedia unter en.wikipedia.org/wiki/Simple_linear_regression im Abschnitt 'Modellbasierte Eigenschaften'. Ist es das was du meinst?

— Hugh Perkins