Lieber Besucher, herzlich willkommen bei: INVESTOX-Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.
Mittwoch, 30. April 2008, 12:19
... genau, ABER ...
Hallo Udo!
... vielen Dank für Deine prompte Info.
ABER:
Das funktioniert nun (standardmäßig) nur für den GD exp. geglättet. Nun angenommen ich will dies
auch mit dem RSI, dem Momentum, dem CCI, ... anstellen. Wie gesagt: Konkreten SourceCode habe ich (noch) nicht - primär
ist's vielmehr eine Idee. So wie ich das Glättungsmass mit dem KAMA dynamisch GLÄTTEN kann möchte ich eventuell auch die
Anzahl der Perioden dynamisch belegen (nicht als hardcoded value).
Ob dies nun auch im Backtest sinnvolle Ergebnisse bringt, kann ich zum derzeitigen Zeitpunkt leider nicht beurteilen - eine
gewisse dynamische Anpassung an die "Marktverhältnisse" erscheint mir jedoch sinnvoll.
Überlegung: Ein potentielles System - basierend auf einem MACD-Crossover (wobei GD(10) cross GD(20)) ist wahrscheinlich im
Schnitt schlechter als ein MACD-Crossover (wobei GD(DynPer) cross GD(DynPer*2)) dass immer zwischen einem x-Schnitt und einem
doppelt so schnellem Schnitt kreuzt, wobei eben durch die Belegung von DynPer festgelegt wird, ob dies 5/10 oder 10/20 oder 100/200 ist.
Vielleicht kannst Du mir noch kurz mitteilen, ob dies so ALLGEMEIN für mehrere Indis funktioniert, oder
ob ich hier auf ext. Sourcen ausweichen muss.
Eine weitere Bitte/Frage noch:
Ich hatte schon das vergnügen mich 3 Semester mit diversen prozeduralen bzw. tw. auch objektorientierten Sprachen anzufreunden (das ist auch der Grund, warum mir die externe Programmierung zwar zeitintensiver, aber trotzdem "noch in diesem Leben" realisierbar erscheint).
-> in welcher Form kann ich hier ext. Source einbinden (Visual Basic bzw. VBScript war leider in den 3 Semestern nicht dabei).
C, C++, C#, Java stehen so zusagen "zur Wahl"
(leider kann ich nicht mit allem "gleich viel" anfangen, aber wer mal (wenn auch nur ein bißchen) programmiert hat, kann meinen "Gedankengang der universellen Programmierung" sicherlich nachvollziehen (wenn man prozedurale Programmierung versteht ist's eigentlich wurscht ob die Syntax Pascal, C oder sonstwas ist. Selbige Argumentation natürlich mit C#, Java & Co. für die objektorientierten).
Für die HardCore-Programmer: Bitte diese Argumentation nicht allzusehr "auf die Waagschale" legen - mir ist (von hörensagen) schon klar, dass es Unterscheide im Detail gibt ... aber ein Array ist ein Array, und Rekursion ist Rekursion und prozedurale Funktionsaufrufe oder einfache Objekthierarchien schaffe ich auch noch (nach syntaktischer Einarbeitungsphase).
Vielen Dank für Deine Mühe (vor allem meine langen mails zu lesen
).
Grüße von Peter
... vielen Dank für Deine prompte Info.
ABER:
Das funktioniert nun (standardmäßig) nur für den GD exp. geglättet. Nun angenommen ich will dies
auch mit dem RSI, dem Momentum, dem CCI, ... anstellen. Wie gesagt: Konkreten SourceCode habe ich (noch) nicht - primär
ist's vielmehr eine Idee. So wie ich das Glättungsmass mit dem KAMA dynamisch GLÄTTEN kann möchte ich eventuell auch die
Anzahl der Perioden dynamisch belegen (nicht als hardcoded value).
Ob dies nun auch im Backtest sinnvolle Ergebnisse bringt, kann ich zum derzeitigen Zeitpunkt leider nicht beurteilen - eine
gewisse dynamische Anpassung an die "Marktverhältnisse" erscheint mir jedoch sinnvoll.
Überlegung: Ein potentielles System - basierend auf einem MACD-Crossover (wobei GD(10) cross GD(20)) ist wahrscheinlich im
Schnitt schlechter als ein MACD-Crossover (wobei GD(DynPer) cross GD(DynPer*2)) dass immer zwischen einem x-Schnitt und einem
doppelt so schnellem Schnitt kreuzt, wobei eben durch die Belegung von DynPer festgelegt wird, ob dies 5/10 oder 10/20 oder 100/200 ist.
Vielleicht kannst Du mir noch kurz mitteilen, ob dies so ALLGEMEIN für mehrere Indis funktioniert, oder
ob ich hier auf ext. Sourcen ausweichen muss.
Eine weitere Bitte/Frage noch:
Ich hatte schon das vergnügen mich 3 Semester mit diversen prozeduralen bzw. tw. auch objektorientierten Sprachen anzufreunden (das ist auch der Grund, warum mir die externe Programmierung zwar zeitintensiver, aber trotzdem "noch in diesem Leben" realisierbar erscheint).
-> in welcher Form kann ich hier ext. Source einbinden (Visual Basic bzw. VBScript war leider in den 3 Semestern nicht dabei).
C, C++, C#, Java stehen so zusagen "zur Wahl"
(leider kann ich nicht mit allem "gleich viel" anfangen, aber wer mal (wenn auch nur ein bißchen) programmiert hat, kann meinen "Gedankengang der universellen Programmierung" sicherlich nachvollziehen (wenn man prozedurale Programmierung versteht ist's eigentlich wurscht ob die Syntax Pascal, C oder sonstwas ist. Selbige Argumentation natürlich mit C#, Java & Co. für die objektorientierten).
Für die HardCore-Programmer: Bitte diese Argumentation nicht allzusehr "auf die Waagschale" legen - mir ist (von hörensagen) schon klar, dass es Unterscheide im Detail gibt ... aber ein Array ist ein Array, und Rekursion ist Rekursion und prozedurale Funktionsaufrufe oder einfache Objekthierarchien schaffe ich auch noch (nach syntaktischer Einarbeitungsphase).
Vielen Dank für Deine Mühe (vor allem meine langen mails zu lesen
).Grüße von Peter
Zitat
Freitag, 2. Mai 2008, 13:40
RE: ... es werde Licht
1. >>> SumVar(MOM(Close,1), Perioden)/Perioden ........ wäre demnach Momentum für die dynamischen Perioden (MOM(Close, 1) ... MOM(Close, 23) je nach Belegung von Perioden)
... habe mich gestern abends noch ein wenig damit beschäftigt (Papier). Dieser/mein Berechnungsansatz führt übrigens zu einem falschen Ergebnis (eigentlich auch klar - das relative Verhältnis aktueller Bar zu Bar vor x-Perioden kann ja wohl schwer der Durschnitt der Einzelverhältnisse sein. Wenn man also die einzelnen Previous-Bar-Deltas aufsummiert und dann das entsprechende Verhältnis ausrechnet klappt's auch wie gewünscht.
@Fritz + Udo
Danke für Eure Inputs - meine Berechnungsmethode "aus der Hüfte geschossen" war jedoch eher Mist (musste ich hier noch posten, nicht dass da jemand diesen falschen Momentum-Ansatz einbaut und sich dann wundert).
Grüße von
Peter
