INVESTOX-Forum

Hallo Hans-Jürgen,

m.M. sollte das Schlüsselwort nur im Berechungsfeld global berechnen. Wenn es übergreifend auf STOPPS und die ENTER/EXIT Basis angewendet wird kann nur noch SPALTE (SE) dort eingesetzt werden und die Flexibilität,vor allen bei den Stopps, würde stark eingeschränkt!

Zudem wäre der Backtest kritisch zu betrachten! Weiterhin ist es problematisch wenn ein User die Formeln-so wie Du-unter Definiton eingibt und dann "#_USECOLVALUES#" dort ebenfalls einfügt! Werden jetzt wirklich alle Formeln auf den Brick berechnet? Ich habe es jetzt noch nicht vollends ausgetestet aber ich kann mir vorstellen das es Probleme geben könnte!

Noch ein Problem in dem Zusammenhang: Wie werden gemischte Berechnungen abgehandelt-ein Indikator wird auf SPALTE berechnet und ein zweiter nicht?

Alles in allen sollte das Schlüsselwort-wenn vorgesehen-auf sämtliche berechnungen in den Definitionsfeldern für Inputs zugreifen können,egal ob (Global) CALC davor steht oder nicht!



>>eine Checkbox im Einstelldialog der Komprimierung sein oder etwas >>anderes, was machbar ist... vielleicht "global #_USECOLVALUES#" in >>den Definitionen.

Prima Idee der ich voll zustimme!

Hallo,

derzeit ist es ja so, dass #_USECOLVALUES# für die gesamte Formel gültig ist, in der das Schlüsselwort steht, egal wo es in der Formel steht. Dies lässt sich auch nur schwer ändern. Andererseits kann man auf diese Weise recht einfach ein Handelssystem umstellen, so dass eine globale Einstellung m.E. nicht viel bringt bzw. auch eher verwirren könnte, da man nach nachvollzieht, wo sich dies überall auswirkt.

Wenn man einzelne Berechnungen differenziert vornehmen möchte, kann man zum einen auch die Kursfelder (OHLC bzw. Spalte(XY)) direkt ansprechen oder einen entsprechenden Anwenderindikator definieren, indem das Schlüsselwort #_USECOLVALUES# dann lokal gilt.

Viele Grüße
Andreas Knöpfel

@ Herrn Knöpfel,

zusammengefasst gibt es drei Szenarien für das Schlüsselwort:

-alle Inputs sollen auf die Spalte berechnet werden
-alle Inputs werden als fixe HI_LO Preisspannen berechnet
-es sollen gemischte Inputs berechnet werden

Im letzten Fall bin ich mir nicht so sicher bzw. wurde nicht getestet, ob man das innerhalb eines Handelssystem Dialog so hinbekommt.


Der zuerst genannte Fall darf sich nicht auf STOPPS und ENTER/EXIT BASIS auswirken weil sonst abgefälscht wird falls Spalte (SE) nicht verwendet wird! Demzufolge müsste der Dialog nur zur Auswahl stellen, ob alle Inputs auf die Spalte oder auf Preisspanne berechnet werden sollen.

Wie Hans-Jürgen festgestellt hat, wird #_usecolvalues# nicht immer akzeptiert und kritisch scheint die globale Berechnung dann zu sein,wenn sämtliche Inputs unter DEFINITION geschrieben werden!

Für den User gäbe es klare Anweisungen die man mit einem Satz beschreiben kann und die (wenn machbar) mit einer Aktivierung erledigt sind! Etweder man aktiviert #_usecolValues oder nicht. Mischformen würden einen Sonderfall darstellen wobei m.M. die manuell individuelle Definition unumgänglich ist!

Hallo,
man muß sich immer vor Augen halten, daß Renko eine Darstellungsvariante für die Periodeneinteilung ist und daß man im Endeffekt nur mit den realen Kursen der jeweiligen Perioden arbeiten kann. Wenn man Indikatoren auf Spaltenwerte berechnen möchte, so kann man das explizit machen.

Zitat

Evtl. ist es besser, bei der Anlage des HS die Berechnung auf Spaltenwerte explizid ein- bzw. aus zu schalten. Und dies will ich zur Diskussion stellen.

Klar könnte man das machen, was für viele ggfs. auch erleichternd wäre.
Warum nicht?

Für mich ist es allerdings logisch, daß OHLC immer die echten Kurse der Spalte sind/sein müssen und auch direkt/primär angesprochen werden sollten.

Man kann in HSen so viele Dinge auch sehr genau und exakt mit Investox definieren, allerdings sollte sich das Kerlchen nicht immer totrechnen müssen. Herr Knöpfel wird wissen was damit gemeint ist.

Vuego

Hallo Vuego,

eine Alternative gäbe es zu C_O_H_V ,nämlich dann,wenn wirklich alles auf SPALTE (SE) bzw OPEN mit konstanten Preisspannen berechnet werden soll. In dem Fall könnte das Schlüsselwort systemübergreifend arbeiten!

Hallo Hans Jürgen,

V~~~verlieren.... Muss natülich heissen: "L"... schäm...

Hallo,

im Moment ist es ja so, dass durch den Einsatz des Schlüsselworts #_UseColValues# die Bedeutung von OHLC uminterpretiert wird. Dies kann in der Tat Verwirrung stiften, denn man will vielleicht einfach einen Indikator auf Spaltenwerte berechnen lassen aber dennoch auf die Kursdaten zugreifen (z.B. für ein Limit innerhalb der Handelsregeln), zudem ist die "Reichweite" des Schlüsselworts nicht einfach zu erkennen. Das sollte verbessert werden.

Wozu benötigen wir #_UseColValues# überhaupt? In erster Linie m.E dafür, die Berechnung von eingebauten Indikatoren festzulegen, bei denen man kein Preisfeld angeben kann, weil sie feste Preisfelder verwenden (z.B. ADX mit OHLC). Dagegen kann man z.B. bei einem RSI ohnehin festlegen, worauf dieser berechnet wird.

Mein Vorschlag, den ich gerne zur Diskussion stelle, wäre daher folgender:

- In der Komprimierungseinstellung wird global für das gesamte HS bzw. den gesamten Chart festgelegt, ob ADX, ATR und vergleichbare Indikatoren Spaltenwerte verwenden oder Kursdaten. Die Bedeutung von OHCL wird dadurch aber nicht verändert (diese liefern stets die Kursdaten).

- Ansonsten erfolgt die Angabe, ob Spaltenwerte verwendet werden sollen, immer explizit:
RSI(close,10) - berechnet RSI auf Kursdaten
RSI(Spalte(SC), 10) - berechnet RSI auf "Spaltenschlußkurse" (

Der Spalte-Indikator müsste dazu mit SC und SO (Spaltenopen, Spaltenclose) ergänzt werden.

M.E. wäre dies so transparent, man hätte aber nicht die Möglichkeit, einfach die Bedeutung von OHLC per Schalter umzustellen (gerade dies, kann aber zu Fehlinterpretationen führen).

Viele Grüße
Andreas Knöpfel

@ MM

Ich arbeite mit einem >>S_SC "Five Klick"<< Keyboard!Da dürfte eine Verwechslung gar nicht vorkommen... ......

Hallo,

@MM: so meinte ich das eigentlich nicht:
>>a) generell ALLES auf der Renko-Ebene berechnet (in HS +Chart), unter >>Angabe des Spaltenwertes

Das würde bedeuten, dass auch RSI(close,5) oder Close>3500 stets auf Spaltenwerte berechnet werden, auch in Stops? Wenn aber z.B. in der Einstiegsbasis Close steht, wäre das dann auch ein Spaltenwert.
Man könnte es so machen, es wäre in manchen Fällen bequemer, die Fehleranfälligkeit aber u.U. größer.

Viele Grüße
Andreas Knöpfel

Hallo Herr Knöpfel,

wenn alles auf Spaltenwerte berechnet wird (Stopps und ENTER/EXIT Basis eingeschlossen) werden die Anwendungsmöglichkeiten und die Flexibilität eines Handelssystems sehr eingeschränkt! Man kann lediglich mit Spalte SE
arbeiten, weil dieser Wert den ersten real handelbaren Tick der neuen Spalte/Kästchen darstellt.

CLOSE des aktuellen Kästchen ist je nach gewählter Einstellung weiter entfernt so das ein kurzfristiger Return stattfinden muss damit der Wert getouchet wird! Für ORM wäre das das kein Problem aber für den Backtest schon! Man würde komfortabel ein unrealistisches HS zusammenklicken! Realistisch sehe ich bei der genannten Varaiante nur die Möglichkeit, das wirklich alle Berechnungen auf Basis SPALTE SE stattfinden-real so wie auch im Backtest. Diverse Stopps sind dann natürlich nicht mehr verwendbar wie z.B. der Sofort Stopp oder der Intraday Stopp.Allerdings gäbe es dafür Alternativen!

Als ausreichend erscheint mir, wenn man das Schlüsselwort eintägt und alle Inputs auf Spalte berechnet werden,egal wo sie stehen und wie sie definiert sind! Man müsste abwägen ob man Stopps und die ENTER BASIS mit einbezieht oder nicht! Wenn jemand tatsächlich alles auf Spalte berechnen möchte, dann ist es viel bequemer eine Funktion zu aktivieren die alles steuert! Realistisch sehe ich das aber nur unter dem o.G. Aspekt!

Vielleicht könnte man es so steuern:

-Aktvierung unter INVESTOX-EINSTELLUNG~~veranlasst das komplette HS auf Spalte zu rechnen!

-#_usecol Values#~~veranlasst das HS alles in den Berechungsfelder,ausgenommen Stopps und ENTER,auf Spalte zu berechnen

-manuelle Steuerung wobei jede Zeile vom User individuell definiert werden muss.

Ich denke somit wären fast alle Möglichkeiten abgedeckt!

Was meinen die anderen?


Frage zum letzt genannten Punkt: Wie werden "Mischformen" (Spalten vs C_O_H_L Perisspannen) berechnet?

Hallo,

was liefern die neuen Werte (SPALTE SC/SO) wenn ein Reversal eingesetzt wird und die Indis auf OPEN berechnet werden sollen? Was wenn das komplette HS mit Reveresal und OPEN berechnet werden soll? Wir P&F/ RENKO gleich ausgewertet?

Spalte SE kann m.M. nicht entfallen weil dies ein logischer Schluss zu einer Spalteneröffnung ist. OPEN kann natürlich auch eingesetzt werden aber wenn man sich den Arbeitsgang in der Praxis vorstellt dann wird zu viel vermischt was dann eher zur Verwirrung führt!

Wenn umkrempeln, dann sollten klare und einfach verständliche Regeln gefunden werden und nicht solche, bei denen man um 3 Ecken denken muss! Umso komplizierter die Funktion wird, desto komplzierter ist die Kontrolle des HS. Der Arbeitsgang sollte daher logisch und klar definierbar sein und nicht nur das Schlüsselwort logisch funktionieren!Das sollte man m.M. auch berücksichtigen....