[Robast-commits] r313 - in branches/robast-0.7/pkg/RobAStBase: . R man
noreply at r-forge.r-project.org
noreply at r-forge.r-project.org
Tue Jun 30 15:02:55 CEST 2009
Author: stamats
Date: 2009-06-30 15:02:54 +0200 (Tue, 30 Jun 2009)
New Revision: 313
Added:
branches/robast-0.7/pkg/RobAStBase/inst/
Removed:
branches/robast-0.7/pkg/RobAStBase/R/comment.txt
Modified:
branches/robast-0.7/pkg/RobAStBase/DESCRIPTION
branches/robast-0.7/pkg/RobAStBase/R/IC.R
branches/robast-0.7/pkg/RobAStBase/man/0RobAStBase-package.Rd
Log:
merged branch and trunk
Modified: branches/robast-0.7/pkg/RobAStBase/DESCRIPTION
===================================================================
--- branches/robast-0.7/pkg/RobAStBase/DESCRIPTION 2009-06-30 12:52:45 UTC (rev 312)
+++ branches/robast-0.7/pkg/RobAStBase/DESCRIPTION 2009-06-30 13:02:54 UTC (rev 313)
@@ -1,6 +1,6 @@
Package: RobAStBase
Version: 0.7
-Date: 2009-01-29
+Date: 2009-04-14
Title: Robust Asymptotic Statistics
Description: Base S4-classes and functions for robust asymptotic
statistics.
Modified: branches/robast-0.7/pkg/RobAStBase/R/IC.R
===================================================================
--- branches/robast-0.7/pkg/RobAStBase/R/IC.R 2009-06-30 12:52:45 UTC (rev 312)
+++ branches/robast-0.7/pkg/RobAStBase/R/IC.R 2009-06-30 13:02:54 UTC (rev 313)
@@ -53,7 +53,7 @@
setMethod("checkIC", signature(IC = "IC", L2Fam = "missing"),
function(IC, out = TRUE, ...){
L2Fam <- eval(IC at CallL2Fam)
- checkIC(IC, L2Fam, ...)
+ checkIC(IC, L2Fam, out = out, ...)
})
## check centering and Fisher consistency
setMethod("checkIC", signature(IC = "IC", L2Fam = "L2ParamFamily"),
Deleted: branches/robast-0.7/pkg/RobAStBase/R/comment.txt
===================================================================
--- branches/robast-0.7/pkg/RobAStBase/R/comment.txt 2009-06-30 12:52:45 UTC (rev 312)
+++ branches/robast-0.7/pkg/RobAStBase/R/comment.txt 2009-06-30 13:02:54 UTC (rev 313)
@@ -1,113 +0,0 @@
----------------------------------------------------------------------------
-Nachteil: Produkt-Design
----------------------------------------------------------------------------
-Meines Erachtens ist die volle Nutzung vom Method dispatch im
-"kartesischen Produkt"-Modell nicht erforderlich
-(d.h. dispatch auf dem Tripel x, IC, start),
-weil das eine nicht notwendige Vielzahl extrem ähnlicher
-Methoden nach sich zieht --- genauer
-
- $\#\mbox{Klassen für x} \times #\mbox{Klassen für IC}
- \times #\mbox{Klassen für start}$
-
- Zahl an Methoden ---
-
-Das hast Du ja bisher konsequent (und fehlerfrei!) so gemacht,
-diese Redundanz stellt sich aber nun in der Maintenance als nachteilig heraus:
-Modifikationen müssten in gleicher Form für alle Methoden gemacht werden.
-
-Zwei Auswegstrategien:
-
-(a) immer noch viele Methoden, aber ähnliche Methoden rufen immer
-mit getMethod(signature="") eine Referenz-Methode auf
-
-(b) wir machen aus der Methode kStepEstimator doch wieder eine
-gewöhnliche Funktion, rufen aber in ihr Methoden auf, die einen Dispatch
-jeweils nach nur einem Original-Argument machen ---
-das logarithmiert die Zahl der benötigten Methoden (oder macht aus dem
-Produkt eine Summe); funktioniert aber natürlich nur dann, wenn der Dispatch
-nach den einzelnen Argumenten unabhängig (im Sinn wie in stochastischer
-Unabhängigkeit (!)) gemacht werden können.
-
-Diesen Designpunkt sollten wir auf jeden Fall auch in unserem Artikel
-encaps aufnehmen.
-
-Mein Vorschlag ist (b) --- siehe auch kStepEstimator() in oneKstepEstimator.R
-den Code will ich aber noch genauer checken.
-
----------------------------------------------------------------------------
-voller Parameter bei k-Schritt-Schätzer
----------------------------------------------------------------------------
-Hier tut sich nun noch beim k-Schritt-Schätzer ein weiteres Problem auf:
-Was machen wir genau mit partiellen ICs bei "Bewegungen des Modells" ;
-dafür brauchen wir ja eine Schätzung für das volle $\theta$ ---
-auch hier zwei Strategien:
-
-Zunächst sollte in beiden Strategien ein ("sehr") robuster Start-Schätzer
-$\theta_0$ für das volle $\theta$ berechnet werden; dann
-
-(1) Gegeben $D=D_\theta=\partial/\partial t \tau (t)|_{t=\theta}$
- und die robust optimale pIC $\eta=\eta_\theta$
- berechne "nur" die weitere pIC $\chi=D^- \eta$,
- $D^-$ generalisierte Inverse von $D$
- und datiere theta auf durch
- $\theta_{i+1}=\theta_i + {\rm mean}(\chi(X_i))$
- --- das würde die Projektion von $\theta_0$ im Orthogonalraum
- zum Spaltenraum von $D$ in der Iteration invariant lassen, da
- $$(\EM_p-D^-D) \theta_{i+1}=
- =(\EM_p-D^-D) \theta_{i} + {\rm mean}(\chi(X_i)) - D^-D{\rm mean}(\chi(X_i))
- =(\EM_p-D^-D) \theta_{i} + {\rm mean}(D^-\eta (X_i)) - {\rm mean}(D^-D D^-\eta (X_i))
- =(\EM_p-D^-D) \theta_{i} + {\rm mean}(D^-\eta (X_i)) - {\rm mean}(D^-\eta (X_i))
- =(\EM_p-D^-D) \theta_{i} = \ldots = (\EM_p-D^-D) \theta_{0}
- $$
- Wollen wir das ? --- vom Konzept "Nuisance" her sollte uns das Verhalten
- unseres Schätzers auf $(\EM_p-D^-D)$ egal sein ...
-
-(2) --- eher im Sinn von Ri:94, 4.2.11(e):
- Ergänze $\chi$ per Addition auf eine echte IC ---
- dh. nehme eine irgendwie geartete beschränkte IC (D=\EM)
- $\psi$ und produziere
- $\tilde \chi=\chi + (\EM_p-D^-D) \psi$
- und datiere auf mit
- $\theta_{i+1}=\theta_i + {\rm mean}(\tilde\chi(X_i))$
- hier wird also der Schätzer für $\theta$ auch auf $(\EM_p-D^-D)$ weiter
- verbessert, es gilt aber $D\tilde \chi=D\chi=\eta$.
-
-Mir erscheint (2) bei nichtlinearem $\tau$ vertrauenserweckender,
-obwohl das nicht ganz klar ist ....
-
-
-Ich habe mal die Zusatzfunktionen für (2) in
-oneKstepEstimator.R geschrieben --- auch hier ist noch checking
-erforderlich!
-
-* getBoundedIC() für die Gewinnung von $\psi$
-in (2) --- kannst Du da mal drüberschauen; Du kennst Deine RandVar-Klassen
-besser als ich; geclippt wird auf Höhe $b=\tr {\cal I}^-$ und macht dann einen
-Schritt in Ri:94 5.5.2 ...
-
-* Die Umsetzung von Strategie zwei erfolgt in Funktion updateStep(),
-Zeilen 102-120
-(newIC.tot1 ^= \chi, newIC.tot2 ^= (\EM_p-D^-D) \psi)
-mit Aufdatierungs-Schritt in 116-117
-
-Eine if-Abfrage zur Entscheidung (1) oder (2) ist natürlich kein Problem...
-
------------------------------------------------------------------
-lokale update Funktion
------------------------------------------------------------------
-updateStep() , Zeile 91 in oneKstepEstimator.R, wird
-in Funktion kStepEstimator() ja mehrfach benutzt; daher sollte
-eine Funktion hilfreich sein, um Redundanz zu vemeiden ---
-was denkst Du?
------------------------------------------------------------------
-oneStepEstimator
------------------------------------------------------------------
-kann doch eigentlich noch viel stärker kStepEstimator nutzen....
-vgl oneStepEstimator() in oneKstepEstimator.R --- was denkst Du?
------------------------------------------------------------------
-roptest
------------------------------------------------------------------
-Hier ist mir aufgefallen, dass Du bisher die Methode mit Argument
-start als "Estimate" nie nutzt; daher die Einführung von init.est in Zeile 295
-in oneKstepEstimator.R
\ No newline at end of file
Copied: branches/robast-0.7/pkg/RobAStBase/inst (from rev 308, pkg/RobAStBase/inst)
Modified: branches/robast-0.7/pkg/RobAStBase/man/0RobAStBase-package.Rd
===================================================================
--- branches/robast-0.7/pkg/RobAStBase/man/0RobAStBase-package.Rd 2009-06-30 12:52:45 UTC (rev 312)
+++ branches/robast-0.7/pkg/RobAStBase/man/0RobAStBase-package.Rd 2009-06-30 13:02:54 UTC (rev 313)
@@ -12,7 +12,7 @@
\tabular{ll}{
Package: \tab RobAStBase\cr
Version: \tab 0.7 \cr
-Date: \tab 2009-01-29 \cr
+Date: \tab 2009-04-14 \cr
Depends: \tab R(>= 2.7.0), methods, distr(>= 2.0), distrEx(>= 2.0),
distrMod(>= 2.0), RandVar(>= 0.6.3)\cr
LazyLoad: \tab yes\cr
More information about the Robast-commits
mailing list