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.
Donnerstag, 30. August 2007, 23:24
Unabhängig davon ist aber natürlich klar, dass das Zusammenspiel von Handelsregeln, Stops, Aktualisierung und Enter/Exitbasis genauestens zu prüfen ist, bevor man ein System real handelt, und zwar auch im Einsatz mit virtuellem Broker und Papertrader. Das ist aber doch wirklich nichts Neues.
Dennoch sind gewisse Fallstricke bei eben diesem Zusammenspiel ein gewichtiger Grund, warum manch ein User, nachdem er sich endlich in die Software eingearbeitet hat, sich entnervt für längere Zeit von diesem zweifellos bestechenden Programm verabschiedet. Das hat die Software nicht verdient.
Wäre es nicht möglich, vor der Implementierung weiterer Programmkomplexität den Projektratgeber um einen "Fallstrickwarner" zu erweitern?
Der könnte etwa dann Alarm schlagen, wenn aufgrund von Regelfehlern in die Zukunft geschaut wird oder wenn z.B. das Zusammenspiel von Enter-Exit-Basis,Preisfeld und DatePart (!!!) user-verursachte Logikfehler bei der HS-Entwicklung aufweist(ein Lieblingsfallstrickthema von mir, das mich schon viel Zeit gekostet hat).
Freitag, 31. August 2007, 09:51
ich denke auch, dass es sicher möglich ist, bestimmte dinge zu generalisieren.
z.b. dass man ohne ref-1 keine grösseren komps in systemen verwenden darf, dass man open delay 0 nur mit ref-1 verwenden darf etc. etc.
ich bin mir sicher, dass man da eine systematische checklist, was man nur mit was verwenden kann, erarbeiten kann, bzw was welche einstellung an anderer stelle erfordert. dazu kann ich gerne einen neuen thread aufmachen, wo die user dann solche fälle zusammentragen. daraus kann man sicher solch ein kleines fallstricktool
bauen oder einfach nur eine tabelle, die man dann punkt für punkt abhakt, um nichts zu vergessen. dass man da natürlich nicht alles reinpacken kann,
erscheint logisch, aber offenbar sind es doch immer irgendwo dieselben sachen, die in bestimmten, eigentlich klar bestimmbaren fällen, probleme machen.
was haltet ihr davon so einen listenthread aufzumachen, wo solche dinge gebündelt werden?
dann kann vielleicht auch endlich mal einer was zum thema sagen und harte zahlen nennen, lol :-)
z.b. dass man ohne ref-1 keine grösseren komps in systemen verwenden darf, dass man open delay 0 nur mit ref-1 verwenden darf etc. etc.
ich bin mir sicher, dass man da eine systematische checklist, was man nur mit was verwenden kann, erarbeiten kann, bzw was welche einstellung an anderer stelle erfordert. dazu kann ich gerne einen neuen thread aufmachen, wo die user dann solche fälle zusammentragen. daraus kann man sicher solch ein kleines fallstricktool
bauen oder einfach nur eine tabelle, die man dann punkt für punkt abhakt, um nichts zu vergessen. dass man da natürlich nicht alles reinpacken kann,
erscheint logisch, aber offenbar sind es doch immer irgendwo dieselben sachen, die in bestimmten, eigentlich klar bestimmbaren fällen, probleme machen.
was haltet ihr davon so einen listenthread aufzumachen, wo solche dinge gebündelt werden?
dann kann vielleicht auch endlich mal einer was zum thema sagen und harte zahlen nennen, lol :-)
Aus Text kann man sehr wenig ableiten!
Freitag, 31. August 2007, 20:28
Hallo,
dies wurde ja schon öfters vorgeschlagen. Ich sehe aber leider nicht, dass sich dies durch eine statische Prüfung erreichen lässt. Insbesondere die Folgen von "Flattersignalen" bei der Verwendung unvollendeter Perioden werden so weit ich dies sehen kann nur durch eine Datenfeed-Simulation bzw. dann im Realtest deutlich. Ich sehe auch nicht, dass dies ein spezielles Problem beim Arbeiten mit dieser Software ist.
Viele Grüße
Andreas Knöpfel
Flattersignale, die erst im Realtest deutlich werden, würde ich mit Verlaub sehr wohl als Problem bei der Arbeit mit dieser Software bezeichnen.
Aber auch im Vorfeld von "Flattersignalen" würde ich als vielleicht eher unbedarfter, aber interessierter Kundeschon Probleme sehen, die das Interesse, mit dieser Software zu arbeiten, massiv einschränken.
Wenn ich z.B. ein HS entwickelt habe, das bei Enterbasis Open Delay 1 eben zum Open der nächsten Periode einsteigt und das Entersignal wie erwartet identisch mit dem Handelsbeginn ist, möchte ich nicht die Überraschung erleben, dass beim Ergänzen der Regeln mit DatePart plötlzich ein Entersignal eine Periode vorher erscheint und der Handelsbeginn dann mit "Hold" im Signalprotokoll erscheint statt mit Enter. Denn als unbedarfter Kunde dieser Softwre habe ich ja zuvor mühsam gelernt, dass ich einsteige, wenn diese tolle Software Enter im Signalprotokoll ausgibt.
Das nur mal als Beispiel für die Begründung eines Rufes nach einem Fallstrickwächter.
Freitag, 31. August 2007, 22:11
Ich bin froh, daß ich die Simulationen machen konnte und deshalb nicht alle Fehler erst real gemerkt habe.
Ich kenn keine gar keine andere Software wo man vorher simulieren kann ?
Die Simulationen sehe ich als Vorteil und gar nicht als Problem.
na klar!!!! :-) daher war ich ja so frustriert, als ich sie nicht zum laufen bekommen habe!!!!
ich träume von einem kleinen fenster mit "Playtaste", wo dann, wenn ich drücke, ein fenster aufgeht, das mich fragt
von wann bis wann und wie schnell es denn bitte sein soll :-)
Freitag, 31. August 2007, 22:33
@olli
Das muss ich grafisch etwas aufbereiten-tue ich am WE!
Alles schön und gut aber wenn nun die Daten vorkomprimiert sind-z.B. 5 Minuten,ein Enter und ein Intraday-Stopp innerhalb einer Periode gleichzeitig auftauchen und tangieren was dann? Mit vorkomprimierten Daten wird man das Problem nie erkennen und mit Tickdaten womöglich nicht so schnell! Genau darauf wollte ich Eingangs hinaus.Wenn das System EOD Daten berechnet,hat man nämlich exakt das gleiche Problem da nur C_O_H_L zur Verfügung steht-ganz zu schweigen von P&F,RENKO und Spannenchart mit vorkomprimierten Daten in Verbindung mit dem Intraday-Stopp!
danke, bin schon mal gespannt. :-)
das mit den fallstricken ist sicher etwas, was wir mal irgendwo zentral abhandeln sollten, im interesse aller. wenn dann herr knöpfel daraus anregungen bezieht umso besser.
was das verwenden von vorkomprimierten daten in renko und spanne angeht, habe ich vor so etwas bis jetzt instinktiv zurückgeschreckt, da ich mir dachte,
dass da etwas schiefgehen muss... daher würde es vielleicht in machen fällen schon helfen, die kombititel auch in spanne oder renko anlegen zu können...