Donnerstag, 25. April 2024, 13:48 UTC+2

Sie sind nicht angemeldet.

  • Anmelden
  • Registrieren

sten

Experte

Registrierungsdatum: 6. September 2002

Beiträge: 2 879

1

Mittwoch, 3. April 2013, 12:28

Überlegung um Komp() ohne inneres Ref-1 in Intraday-HS einsetzen zu können

Hallo,

ich habe ein 60min Intraday-Handelssystem und möchte dort einen GD() reinlegen der seine eigene Periode (im Bereich 1 bis 70min) hat.
Könnte man im Pyseudocode so umsetzen:

Zitat

Ref(Komp(#Ref(GD(Close,10),-1)#,#1-70min...robustbar#),-1)

, d.h. mit inneren und äußeren Ref-1 um sicherzugehen, dass der Indikator nicht in die Zukunft schaut.

Ich suche eine Möglichkeit zumindestens ein Ref-1 einzusparen (das innerer) und trotzdem keinen Zukunftsblick zu riskieren.

Dazu müsste man doch eigentlich nur erreichen, dass die interne Investoxberechung auf den Close der Perioden synchronisiert.
Ich stelle mir das so vor, wenn man die beiden Perioden graphisch, nebeneinander darstellen würde:
.......60min
.....|------------|Close (HS-Komprimierung)
.......63min
..|---------------|Close (dynamische Komp-Periode)

dann müsste eigentlich die obere Komp()-Berechnung ohne inneres Ref-1 auskommen, d.h. selbst dann wenn der Komp()-Indikator einen größeren Wert als 60min für seine Komprimierung verwenden würde, kann er die zusätzlichen Minuten (im Bsp. 3min) gegenüber der HS-Komprimierung aus der Vergangenheit holen.

Ist meine Denkweise erstmal so korrekt?
Wenn ja, wie muss Investox konfiguriert werden, damit intern so gerechnet wird? Möglicherweise hängt das ja nicht nur vom Komp()-Indikator, sondern auch noch von globalen Einstellungen ab?

Danke.

Viele Grüße
Sten

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »sten« (3. April 2013, 12:34)


Lenzelott Männlich

Experte

Registrierungsdatum: 30. Dezember 2002

Beiträge: 3 051

Wohnort: Giessen

2

Mittwoch, 3. April 2013, 22:50


Ist meine Denkweise erstmal so korrekt?


Nein, das ist alles in meinen Augen ziemlicher Unsinn.

eine KOMP() muss imho immer ein vielfaches der Grundkomprimierung des HS sein.
Also HS auf 1 Minuten Bars, dann kannst Du 60 minuten Komp verwenden um Deine Signale zu berechnen und von mir aus auch 67 Minuten um irgendwas anderes drüber zu legen.
Aber einen 60 Minuten Bar auf 63 Minuten zu komprimieren wird Dir nicht gelingen.
If you think it´s expensive to hire a professional, wait until you hire an amateur.

Bernd

Experte

Registrierungsdatum: 5. Juni 2005

Beiträge: 4 071

Wohnort: Iringsweg

3

Donnerstag, 4. April 2013, 16:00

eine KOMP() muss imho immer ein vielfaches der Grundkomprimierung des HS sein.

Das ist imho mit Nichten der Fall. Mit Neffen auch nicht :D

Innerhalb von Komp() wird eine eigene Zeitreihe ab den Tickdaten bzw. des Titels auf der Platte neu eingelesen, komprimiert und erst dann auf das Close der Basis-Komprimierung synchronisiert. Daher kann der ganze Formelsallat (ja, da kann ja nicht nur ein Titel stehen, ganze HS-Konstrukte können dort unabhängig vom Basis System und dessen Kontext eingenistet werden) innerhalb der Komp() Formel zunächst einmal unabhängig vom Grundsystem aggieren. Die Komp-Formel ist sozusagen eine völlig autarke Umgebung, fast wie ein HS im HS!

Um keinen Zukunftsblick zu erzeugen, muss dann, wenn die Komp-Komprimierung > Basiskomprimierung ist (oder auch variablen Zeitabschnitten wie Spanne und Renko etc., die potentiell geeignet sind, einmal grösser als die Basis-Komprimierung zu werden) innerhalb der Komp() Formel mit Ref( ,-1) gearbeitet werden. Letzterer Fall ist besonders tückisch, ist solch ein HS doch oft "immer" zeitstabil, aber dann plötzlich einmal doch nicht!

Damit das so erzeugte Konstrukt bei der Synchronisation auf das Close der Basis-Komprimierung nicht flattert, wird bei Open, Delay 0 dann natürlich noch ein äusseres Ref(,-1) um die gesamte Komp() Sache herum nötig (übrigens kann man mit KompSynch() auf anderes synchronisieren, z.B. auf das Open der Basis Komprimierung, dann würde m.E. das zusätzliche äussere Ref(,-1) bei Open, Delay 0 entfallen).

Langer Rede kurzer Unsinn, am Ende im Ergebniss stimme ich mit Lenzelott soweit überein, dass ich keine Möglichkeit kenne oder sehe, auf das innere Ref(,-1) dann zu verzichten, wenn die Komp() Komprimierungs-Angabe bei Open Delay 0 grösser als die Basis Komprimierung ist oder werden kann, wenn das Signal nie flattern können darf. Ich sage sogar, dass es noch ein äusseres Ref(,-1) benötigt! Andererseits stimme ich in dem anderen Punkt nicht überein: imho kann die Komp() Komprimierung kleiner sein als die Basis-Komprimierung.

Dass letzteres verschärft trickreich ist, weil sich innerhalb einer Basis-Periode mehrere Komp() Perioden die Hand reichen, steht natürlich ausser Frage :P Warum das so ist, ist jetzt mit diesen Ausführungen vielleicht klarer geworden.

Für sten: ich sehe keine Möglichkeit, wie im Beispiel 63 Minuten Komp() Perioden exakt am Close (oder mit KompSynch() am Open) einer 60 Minuten Periode enden zu lassen. Vielmehr werden die Prioden (Basis- und auch Komp()) um Mitternacht los laufen, mit den erwähnten Ref(,-1)sen zeitlich stabilisiert werden müssen und können dann erst sauber verwendet werden (sauber = Backtest entspricht realhandel). Der Kasus Knacktus ist sicher, dass ab Mitternacht vorwärtsgerechnet wird - nicht ab einer Basis-Komprimierungs Periode rückwärts in der Zeit. Imho. Es sei denn, Herr Knöpfel hat dafür nen lustigen Haken an Bord, den ich dann doch noch übersehen habe :D

Übrigens Lenzelott: wenn das wahr wäre: "eine KOMP() muss imho immer ein vielfaches der Grundkomprimierung des HS sein. ", dann könnten keine variablen Komp() Komprimierungen verwendet werden in einer zeitlich festen Basis-Komprimierung - hier floatet der Komp() Kontext ja ganz offensichtlich potentiell zwischen < und > als die Basis Komprimierung :rolleyes:
Gruss
Bernd