atecon / fep

Forecast Evaluation Package for gretl

Forecast Evaluation Package for Gretl

Download the working paper version here: http://www.boeckler.de/pdf/p_imk_wp_190_2018.pdf

fep's Issues

Comparing Predictive Accuracy in the Presence of a Loss Function Shape Parameter, Patton & Barendse, 2022, JBES, 40(3), 1057-1069.

http://public.econ.duke.edu/~ap172/Barendse_Patton_8dec20.pdf

Das ist ziemlich neu und gewissermaßen eine Erweiterung von Giacomini-White, den wir ja auch schon haben. Es wird wohl ein Kontinuum von Verlustfunktionen zugelassen. Andererseits ist unsere GW-Implementation noch ziemlich restriktiv (nur U- und V-shape), insofern könnten wir überlegen, ob wir nicht erstmal den GW-Test bei uns verallgemeinern, indem wir auch andere Verluste unterstützen (u.U. komplett benutzerspezifiziert?).

Wrong p-value for CG sign-test

Hi @schreibe,

I found a bug in the Campbell & Ghysels sign nonparam. statistics which starts here: https://github.com/atecon/FEP/blob/master/src/FEP_tests_individual.inp#L429

For a current project, I obtain p-values lager than 1 for the sign statistics which is computed here:
https://github.com/atecon/FEP/blob/master/src/FEP_tests_individual.inp#L503

if b.CGSIGNstat < (T + 1) / 2 # left tail of the distribution
        temp = pvalue(B, 0.5, T, b.CGSIGNstat)
        # (gretl does > x, not >= x here!)
        b.CGSIGNpval = 2 * (1 - temp) # because of symmetry under p=0.5
else	# right tail
        # (force X >= x by passing x' = x-1, since gretl does > x)
        b.CGSIGNpval = 2 * pvalue(B, 0.5, T, b.CGSIGNstat - 1)
        # (again, because of symmetry)
endif

In my example, I have n=80 trials and a test statistics of 40. Using gretl's p-value finder via the GUI, I get:

Binomial (p = 0.5, n = 80):
Prob(x > 40) = 0.455536
Prob(x <= 40) = 0.544464
Prob(x >= 40) = 0.544464
Prob(x = 40) = 0.0889279

However, doCGtest() returns p-value of 1.0889279. Here for replication locally:

temp = pvalue(B, 0.5, 80, 40)
pval = 2 * (1 - temp) # because of symmetry under p=0.5
print pval  #1.0889279

pval_sign_righttail = 2 * pvalue(B, 0.5, 80, 40 - 1)
print pval_sign_righttail # 1.0889279

I think what we actually want under the first if-condiction is:

scalar greater_than = pvalue(B, 0.5, 80, 40)
scalar equal_to_teststat = 1 - 2 * greater_than # because of symmetry under p=0.5
scalar geq = greater_than + equal_to_teststat

greater_than =  0.45553606
equal_to_teststat =  0.088927879
geq =  0.54446394

For the thing under the else keyword, I can't remember the details about the -1 "correction" right now. But this part also needs being fixed.

Once, we have clarified this issue, I can implement the fix within the bugfix/loadextra branch for which already a pull-request exists.

Testing for Unobserved Heterogeneity via k-means Clustering, Patton & Weller, 2022, Journal of Business & Economic Statistics, forthcoming.

http://public.econ.duke.edu/~ap172/Patton_Weller_testing_july19.pdf

H0 scheint zu sein, dass es nur einen Cluster gibt. Soll einfach zu implementieren sein, finde ich insofern interessant; und Du hast ja das k-means-Paket.

existierende getLoss-Funktion verstärkt einbauen

Wir haben schon getLoss(), momentan für linlin, linex, dlinex, quadquad. Dies sollten wir in verschiedenen anderen Funktionen einbauen, um damit mehr Auswahl bei der gewünschten Verlustfunktion zu haben. (Und dann perspektivisch noch andere Verlustfunktionen zu ermöglichen, aber das ist wieder ein anderes Sub-Thema.)

Testing Forecast Optimality under Unknown Loss, Patton & Timmermann, 2007, Journal of the American Statistical Association, 102(480), 1172-1184.

http://public.econ.duke.edu/~ap172/Patton_Timmermann_JASA_2007.pdf

Auch schon älter, scheint eine Erweiterung des EKT-Frameworks zu sein, das wir ja schon in FEP haben.

Improve sample script

Comment by Jack for next version:
"For the next versions, I would probably find it a little nicer if you made the sample script more compact by using defbundle() or _(). But it's just a matter of taste."

Change / clarify GUI error message "Need forecast (fc) input!"

As noted by Allin, this message may happen when in the GUI you leave the fc arg empty, and it is a little misleading. (In some cases fc must be non-empty, but in other cases it's OK.)
Let's change the error message to something like: "Need forecast (fc) input for the chosen test!" (Perhaps also name the chosen test.)

(In the future, Allin's new ui-maker facility may be used, but that is very new and experimental right now.)

Erläuterungstext zum GW-Test verbessern

Was soll z.B. der folgende Satz bedeuten: "The conditional test for forecasting performance tests whether the loss-differential between two forecasts is conditional on current information, z_t." Müsste man da vielleicht "is conditional on" durch "depends on" ersetzen? Aber das wäre wohl nicht der einzige unklare Satz.

doGWtest: "z" mehrfach verwendet

Hi,
folgender Fehler vom Skript unten ausgelöst:
*** error in function doGWtest, line 51

list z += genseries("z", b.z)

Das tritt nur auf, wenn b.z vom Typ series ist (im Ggs. zu matrix oder list). Der Name z ist (in derselben Codezeile sichtbar) schon durch die Gesamtliste belegt und kann daher nicht verwendet werden.
Im Branch FEPGWenhancements (oder so ähnlich) ist dieser Bug schon gefixt, indem die Liste statt mit z mit h_inst benannt wird. (In Anlehnung an den Original-GW-Artikel mit der h_t-Funktion.)

-sven

clear
set verbose off
include FEP.gfn
open FEPdata.gdt --frompkg=FEP

#------------------
# Giacomini & White
#------------------
bundle b = null
b.y = y
b.f1 = fc			# FC 1 series
b.f2 = fc(-1)		# FC 2 series
b.loss = 2			# 1="U-shape" (default), 2="V-shape" 
b.verb = 1
b.cond = 1			# 0=un-, 1=conditional
series fc2 = fc(-2)
series b.z = fc2	# conditioning variables

applyFCtests(&b, "GW")
print b

Forecast Rationality Tests Based on Multi-Horizon Bounds, Patton & Timmermann, 2012, Journal of Business and Economic Statistics, 30(1), 1-17.

http://public.econ.duke.edu/~ap172/Patton_Timmermann_bounds_JBES_2012.pdf

Matlab-Code: http://public.econ.duke.edu/~ap172/PT_bounds_test_toolbox_feb14.zip

Schon etwas älter, insofern wäre die Frage, ob es sich lohnt. Aber ein Teil ihrer Tests geht sogar ohne die ex-post-Realisationen, also nur mit den Prognosen an sich, das hört sich auch wieder interessant an, also für FEP, meine ich.

Sinn von L(-b.fhor to -b.fhor) ?

Hi Artur, in der doGWtest-Funktion werden für den bedingten (conditional) Test verzögerte Verlustdifferenziale hinzugefügt. Das ist soweit schön und gut. Aber da steht:
z += L(-b.fhor to -b.fhor),
und das sieht etwas komisch aus. Warum nicht einfach L(-b.fhor) ? Oder soll es eigentlich heißen L(-1 to -b.fhor), wäre für den Multistep-Ansatz auch gut denkbar. (Es ist m.E. nicht zwingend, weil man in der Wahl der Bedingungsmenge etwas frei ist bei GW.) Oder sollte diese Syntax irgendeinen gretl-Bug umschiffen?
Bitte um sachdienliche Hinweise! Danke.

Idee für Umsetzung allgemeiner benutzerspezifizierter Verlustfunktionen

Dies ist auch ein Kommentar im Quellcode irgendwo, ich kopiere ihn hierher zur besseren Übersicht.
Dies würde mindestens die Funktionen doDMtest und doGWtest betreffen, in FEP_tests_other.inp.

TODO: Allow for further loss functions in future

/* Idea for an interface (Sven, December 2022):

-- The string b.lossfunc = "<funcname>" would refer to an
  active/loaded user func
 (errorif( b.loss == 0 && (!inbundle(b,"lossfunc") || b.lossfunc=="")))
-- Such a user func would have to have the following signature:
  args: series y (realization), series f (forecasts)
  return value: series loss  
-- b.lossfunc == "U" (or quad) could be used instead of b.loss == 1,
  and b.lossfunc == "V" instead of b.loss == 2
-- Then for the non-U and non-V cases we would simply do:
  series L = feval(b.lossfunc, e1, e2)
*/