Alle Inhalte von Mythos
-
Projekt: Entwicklung Community-EA
Und wiedermal ein sorry von mir für die Funkstille. Bin derzeit beruflich jede Woche ein paar Tage Graz wo gar nix geht, und daheim geht leider auch recht wenig weil dann natürlich die liegen gebliebenen Dinge gemacht werden wollen. Da es keine weiteren Meldungen zum letzten Codeblock gab, hier die "finale" Version zur "Abstimmung" : void checkAndHandleSignals() { int res; int filterSignal=FLAT; int entrySignal =FLAT; double stop=0.0; double tp=0.0; double entry= 0; double lots= 1.0; //---- get Signals for opening positions entrySignal = calcEntrySignal(); filterSignal = calcFilterSignal(); if(filterSignal == FLAT || filterSignal != entrySignal) return; //---- open buy if(filterSignal + entrySignal == 2*LONG && (calculateCurrentOrders() == 0 || calcOpenDirection() == LONG || HedgeAllowed)) { entry= Ask; stop=calcInitStopDiff(OP_BUY); lots= calcLots(stop); if(stop > 0) stop = entry - stop; else stop= 0; tp=calcTPDiff(OP_BUY); if(tp > 0) tp= entry + tp; else tp= 0; res = tbSendOrder(Symbol(),OP_BUY,lots,entry,3,stop,tp,"buy",MAGICNR, 0,-1); } //---- open sell if(filterSignal + entrySignal == 2*SHORT && (calculateCurrentOrders() == 0 || calcOpenDirection() == SHORT || HedgeAllowed)) { entry= Bid; stop=calcInitStopDiff(OP_SELL); lots= calcLots(stop); if(stop > 0) stop = entry - stop; else stop= 0; tp=calcTPDiff(OP_SELL); if(tp > 0) tp= entry + tp; else tp= 0; res = tbSendOrder(Symbol(),OP_SELL,lots,entry,3,stop,tp,"sell",MAGICNR, 0,-1); } //---- } wegen Namensänderung wird somit start angepasst: void start() { handleOpenOrders(); if(isTradeAllowed()) checkAndHandleSignals(); } Als nächstes fehlt eh nur mehr ein Punkt im Struktogramm: @Wolf: hab dich nicht überlesen. Danke für den Hinweis. Mir fehlt derzeit leider die Zeit mir die Bibliothek anzuschauen. Aber klingt interessant.
-
Projekt: Entwicklung Community-EA
Stimmt, am schönsten wär ein Parameter bei der tbSendOrder, sodass die Stops einmal direkt beim eröffnen mitgesendet, einmal nachträglich gesetzt werden. bzw. gar nicht zur tbSendOrder sondern ein "globaler" Parameter in der TradeBox den man im init() setzt so wie das infolevel. Damit wär hier keine Codeänderung nötig ;)
-
Close zu bestimmten Datum, aber wie?
Im Prinzip ist iClose da eh schon ein Overkill. Wozu extra nochmal angeben das es das aktuelle Symbol und der aktuelle TimeFrame sein soll? Dafür gibts doch "Close[]" ;) Der Knackpunkt ist (wie WOGO schon gezeigt hat) das "iBarShift". Deine Variante würde nur funktionieren wenn der Markt nie zu wäre, denn du zählst einfach die tehoretisch vergangenen Bars in der Zeit zurück.
-
KW46 · DAX30 · Börsentipp-Gewinnspiel
Ich bin für das Schlachten eines Gockel (für die nit Össis: ein Hahn )...
-
Projekt: Entwicklung Community-EA
Also wenn die calcStop "unabsichtlich" stop zu den Mindestabständen: die tbSendOrder überprüft das automatisch und setzt stop und tp so nahe wie möglich an das gewünschte Level. Wenn gar keine Stops beim eröffnen gesetzt werden dürfen, gibt die TB derzeit glaub ich einfach nach x versuchen auf. das müsste man dann ggf. für den konkreten Broker anpassen. Is mMn ein sehr spezielles Problem, das hier gleich allgemein zu lösen (mit Parameter etc.) bläst den Code eher unnötig auf oder?
-
Projekt: Entwicklung Community-EA
Juhu Beteiligung ;) guter Punkt, ich wär dafür es in einer Funktion zu lassen. wie wärs mit checkAndHandleSignals() ? hoppla, hast natürlich recht. Ich merks schon gar nimmer, vermutlich ne Berufskrankheit ;) also so? if(filterSignal == FLAT || filterSignal != entrySignal) return; hoppla... um sicher zu gehen sollte es wohl eher so heißen: if(stop > 0) stop = entry - stop; else stop= 0; Die calcStop soll auch die Möglichkeit haben ein "kein Stop" zurückzugeben, was einer Stopdiff von 0 entspricht. Wär dann konsistent mit dem Parameter für die OrderSend. ich hätts genau umgekehrt gesehen. Wenn man ihnen Logikspezifische Parameter dazugibt, muss man im Fall einer Änderung der Logik, den Code hier auch ändern. Im aktuellen Fall ist der "checkForOpen" egal wie die "calcInitStopDiff" zu ihrem Wert kommt, geht sie genaugenommen ja auch nix an. Somit kann man innerhalb der calcInitStopDiff jederzeit was ändern ohne das man hier nachbessern muss. Ändert man später die Logik für den Stop, ändert man nur diese eine Funktion, und nix drumherum... oder versteh ich dich falsch? Innerhalb der calcInitStopDiff kann man dann die Entscheidung "welchen Stopp verwenden wir?" etc. einbauen...
-
Projekt: Entwicklung Community-EA
Ok weiter gehts. Da es keine Kommentare zur start() gab, würd ich sagen wir gehen weiter im Text ;) Bereits "erledigt" vom Struktogramm wär damit der Teil und aus Ebene2: Implementiert als: void start() { handleOpenOrders(); if(isTradeAllowed()) checkForOpen(); } bool isTradeAllowed() { if (!EachTickMode && !isNewBar()) return false; if(Bars<100 || !IsTradeAllowed()) return false; if(!isTradingTime()) return false; if(calculateCurrentOrders() < MaxOpenOrders) return true; else return false; } Als nächsten Punkt würd ich diesen vorschlagen: Dieses Modul entspricht im wesentlichen der Funktion checkForOpen() aus Wolfs EA. Hier eine leicht modifizierte Variante als mein Vorschlag für das Modul: void checkForOpen() { int res; int filterSignal=FLAT; int entrySignal =FLAT; double stop=0.0; double tp=0.0; double entry= 0; double lots= 1.0; //---- get Signals for opening positions entrySignal = calcEntrySignal(); filterSignal = calcFilterSignal(); if(filterSignal == FLAT || filterSignal*entrySignal <= 0) return; //---- open buy if(filterSignal + entrySignal == 2*LONG && (calculateCurrentOrders() == 0 || calcOpenDirection() == LONG || HedgeAllowed)) { entry= Ask; stop=calcInitStopDiff(OP_BUY); lots= calcLots(stop); if(stop > 0) stop = entry - stop; tp=calcTPDiff(OP_BUY); if(tp > 0) tp= entry + tp; res = tbSendOrder(Symbol(),OP_BUY,lots,entry,3,stop,tp,"buy",MAGICNR, 0,-1); } //---- open sell if(filterSignal + entrySignal == 2*SHORT && (calculateCurrentOrders() == 0 || calcOpenDirection() == SHORT || HedgeAllowed)) { entry= Bid; stop=calcInitStopDiff(OP_SELL); lots= calcLots(stop); if(stop > 0) stop = entry - stop; tp=calcTPDiff(OP_SELL); if(tp > 0) tp= entry + tp; res = tbSendOrder(Symbol(),OP_SELL,lots,entry,3,stop,tp,"sell",MAGICNR, 0,-1); } //---- } Wie beim ersten Teil muss man hier noch die Funktionen für die tatsächliche EA-Logik erst implementieren, aber ich starte hiermit einfach mal die "Diskussionsgrundlage". Ich denk es is leichter verständlich wenn wir uns vom Groben ins Feine arbeiten und erstmal die allgemeine Programmstruktur in code fassen bevor wir dann die konkreten Logik-Funktionen angehen. Freu mich wie immer auf Meinungen.
-
Willkommen Ferry
Willkommen bei Tom-Next vielen Dank für die kleine Vorstellung, klingt nach einem erfahrungsreichen Leben. Das Erstellen von Erfahrungsberichten zu Brokern ist hier natürlich nicht verboten. Wir freuen uns sogar über gute "unabhängige" Reviews und Berichte, schließlich profitieren alle davon. Wie du im anderen Thread gesehen hast, mögen wir nur kein Guerilla-marketing. Wenn du magst freuen wir uns auf eine kleine Review zu dem Broker. Man hört ja oft von so Lockangeboten, wo dann aber keine Gewinne ausgezahlt werden etc. Ansonsten wirst du hier im Forum sicher viele Gleichgesinnte treffen. Also einfach rein ins Getümmel ;)
-
neuer Laptop
Bei mir schon. Ich hab Laptop und direkt dahinter etwas höher (also der externe schließt direkt an der Oberkante des Laptops an) den externen großen Monitor. Hat den Vorteil das man nit so nach unten in den Laptopschirm schaut sondern gerader sitzt (i zumindest).
-
Facebook Markup Language (FBML) - Seite erstellen und iFrame einbinden
Hmmm, da gibts was zum zusammenklicken? ich vermute mal "ein richtiges". Also solls eine Facebookapplikation werden? Ein bissl bebildert is es da (halt auf englisch): Facebook Developers Zugegeben, es is teils "schwierig" erklärt. Im wesentlichen läufts so: Du verwendest die developersapp (musst einmal deine Daten freigeben), dort erstellst eine neue App (dafür musst mit Handy oder Kreditkarte als realer User bestätigt sein). Die App läuft dann so, das du einen iframe hast, in dem deine App angezeigt wird. Alle Links etc. laufen also weiterhin. Im einfachsten Fall gibts du also dann einfach bei der Canvas-URL die page an wo du hinwillst. (also die URL die im "Iframe" angezeigt werden soll). seit 1.Oktober musst auch eine sichere URL dazuangeben. Wenn du zusätzliche Daten vom User haben willst (wo er herkommt und wie alt er ca is kriegst immer), musst ihn selber zum bestätigungsdialog weiterleiten und halt sagen was du genau haben willst. Willst eine App für die EP machen? wär vermutlich kein Prob. Lustig wirds wennst dann die Graph API bzw. den OpenGraph verwenden willst. Man kann übrigens auch mehrere Developers bei einer App dazupacken ;) (Wenn meine App schon vorzeigetauglich wär, würd ich sie ja als Demo reinstellen, aber sie es derzeit halt nur ein eingebundener Iframe )
-
Facebook Markup Language (FBML) - Seite erstellen und iFrame einbinden
Mit der FBML noch nit genau, aber i bin grad sowieso dabei eine Facebook App zu bauen. Was willst denn genau machen? kurzer Research: würd mit der FBML also nit unbedingt was neues bauen.
-
Projekt: Entwicklung Community-EA
Kurzes Lebenszeichen. Letzte Woche war ich (leider) beruflich durchgehend unterwegs und eingeteilt, wodurch i zu nix gekommen bin und das Wochenende wird vermutlich auch ohne Internetzugang verlaufen, von mir kommt hier also frühestens nächste Woche wieder ein Beitrag. Gibts sonst Kommentare zur start() oder sollen wir dann im Code weitergehen?
-
Projekt: Entwicklung Community-EA
Hier mal ein textuelles Struktogramm wie ich mir den groben Ablauf des EA vorstellen könnte. Textuell deshalb weil man so einfach einzelne Abschnitte zitieren kann und nit immer in einer Grafik rummalen muss. Außerdem ist der Komplexitätsgrad noch niedrig genug das man nit mehr braucht. Wer mag darf gern eine schöne Grafik daraus machen ;) Ebene1 (start()) - Verarbeitung offener Positionen ? Eröffnung neuer Orders erlaubt? + JA: Überprüfe auf Signal + NEIN: Nix. Ebene2 (aufgerufene Funktionen/Module) Verarbeitung offener Positionen: Für alle offenen Positionen - ziehe TrailingStop/Breakeven nach ? Position aufgrund von Timeout zu schließen? + JA: schließe Pos und geh zur nächsten. ? Position aufgrund von Zeitfilter zu schließen? + JA: schließe Pos und geh zur nächsten. Eröffnung neuer Orders erlaubt: ? Wurde dieser Bar bereits überprüft? + JA: return false; ? Außerhalb der erlaubten Handelszeiten? + JA: return false; ? Anzahl der maximal gleichzeitigen Orders bereits erreicht? + JA: return false; - return true; Überprüfe auf Signal: - Berechne Signalrichtung (SHORT, FLAT oder LONG) - Berechne Filterrichtung (SHORT, FLAT oder LONG) ? Sind bereits Positionen offen? + JA: Ermittle Richtung dieser Positionen ? Sind Richtung von Signal und Filter unterschiedlich (oder Signal flat)? + JA: return ? Ist Signalrichtung ungleich der bestehenden Positionen und keine gegensätzlichen Positionen erlaubt? + JA: return - Berechne InitStopentfernung - Berechne Positionsgröße - Berechne TPentfernung - Öffne Position Aus meiner Sicht wären die fetten Punkte mögliche Module die (als eigene Funktionen) man separat entwickeln kann (Der Vollständigkeitshalber: Was die Module machen ist in Post #171 beschrieben). Dafür müsste aber einerseits erstmal die aufrufende Struktur stehen, anderseits sprechen die schon genannten Gründe des public learnings gegen die parallele Entwicklung der Module. Wie schon gesagt, wenn sich genug finden die den EA "schnell" bauen möchten, kann man es in ein eigenes Thema ausgliedern. Hier haben wir uns (soweit ich das sehe) darauf geeinigt defakto bei 0 zu starten und den gesamten Prozess Schritt für Schritt durchzukauen. Hier soll dieses "Struktogramm" in erster Linie zur groben Orientierung dienen. Gibts Meinungen zur Struktur/Ablauf? (Ich freu mich auch über ein "is ok so" ;)
-
Projekt: Entwicklung Community-EA
Aus meiner Sicht gibt es 2 Möglichkeiten: 1. Wir schauen das wir möglichst schnell und effizient einen fertigen EA haben. 2. Wir versuchen es auch als "Schauentwicklung" für Anfänger/Mitleser zu gestalten. Im 1. Fall wär der nächste Schritt: Aufteilung und Definition einzelner Module, Verteilung der Aufgaben an Entwickler. Zusammenbauen und testen. Damit wär der EA schnell fertig, aber jeder Entwickler hat nur seinen eigenen Code "verstanden" und öffentlich präsentiert und durchgearbeitet wird überhaupt nix weil zulange dauert etc. Im 2. Fall "müssen" wir jeden einzelnen Schritt durchkauen und erarbeiten. Ja das dauert länger, aber damit kann jeder Anfänger was damit anfangen. Zum Struktogramm und Modulaufteilung: Eigentlich gibts die Modulaufteilung ja schon in Post #171. Wer gern ein Struktogramm dazu machen will, ist herzlich eingeladen. Oder fehlt noch eine Information?
-
Projekt: Entwicklung Community-EA
Danke Wolf für die Erklärung. Aber ich glaube wenn wir es weiter in dem Stil machen (Du erklärst uns was im EA passiert), ist es endgültig nur dein EA und wir kommentieren. Damit es ein Gemeinschaftsprojekt bleibt, sollten wir es in der Gruppe Schritt für Schritt durchackern und hinterfragen. Es geht ja nicht hauptsächlich darum zu verstehen was der EA tut, sondern eher darum das wir einen EA bauen wo alle mitbestimmen wie es gemacht wird. In dem Sinn ist der EA eigentlich eine implementierte Version "deiner Meinung" (und als solches auch sehr gut), jetzt fehlt halt die Meinung der anderen. Also langsam und Schritt für Schritt. Aus meiner Sicht erster Punkt in der Implementierung: Was kommt in die start()? Wolf zeigt uns einen sehr spartanischen Ansatz. Aus meiner Sicht ist es sehr vorteilhaft für die Modularisierung und damit schnelle austauschbarkeit von Teilen, wenn man logische Komponenten in eigene Funktionen packt. Für mich müsste es nicht ganz so extrem aufgeräumt sein wie bei Wolf, kann aber ;) Hier der Code: void start() { //---- if(Bars<100 || !IsTradeAllowed()) return; if (!EachTickMode && !isNewBar()) return; if(calculateCurrentOrders(Symbol())==0) checkForOpen(); else checkForClose(); //---- } (@Wolf: hab ein bissl was angepasst da du bei den Namensbezeichnungen nit ganz einheitlich warst ) Schritt für Schritt: - wenn zuwenig Bars vorhanden oder traden nicht erlaubt -> tu nix (return) - wenn wir nicht jeden Tick überprüfen und es ist kein neuer Bar-> tu nix Dann kommt die eigentliche Tradingthematik: - gibt es offene Orders? wenn ja: checkForClose() sonst: checkForOpen(). Meine Anmerkungen (wenn man so aufgeräumt arbeitet): - ich würde IsTradeAllowed gleich erweitern auf eine eigene Funktion wo man Zeitabhängige Filter etc einbauen kann. - ich würde checkForClose() in handleOpenOrders() umbenennen und immer aufrufen. Damit wird der EA auch multipleOrder-fähig und es passt von der Bezeichnung her besser. checkForClose() schließt ja nicht nur sondern zieht auch stops nach etc. (sollte es zumindest). - weiters würde ich die Abfrage ob Orders offen sind und ob dann getraded werden darf in das eigene isTradeAllowed() packen. - das handleOpenOrders() sollte man nicht mit den gleichen Beschränkungen (nur neuer Bar etc) ausführen wie das checkForOpen(), es kann ja Zeitfilter etc. geben die innerhalb des Bars aktiv werden und dann auch aktiviert werden sollten. (oder wenn man dann später den Stop nicht mehr an den Broker sendet sondern selber verwaltet, dann muss man bei jedem Tick überprüfen) Also nach der groben Logik: - verarbeite offene Orders (stopnachziehen, schließen whatever) (ob vor oder nach dem eröffnen ist dann eine Detailfrage, in der Form ist man schneller im Trendwechsel wenn nur gleichgeschaltete Orders erlaubt) - ist es gerade erlaubt neue Orders zu eröffnen? wenn ja: checkForOpen() codemäßig: void start() { handleOpenOrders(); if(isTradeAllowed()) checkForOpen(); } bool isTradeAllowed() { if (!EachTickMode && !isNewBar()) return false; if(Bars<100 || !IsTradeAllowed()) return false; if(calculateCurrentOrders() < MaxOpenOrders) return true; else return false; } Das isTradeAllowed implementiert also die Logik "Dürfte ich bei dem Tick eine neue Order eröffnen" unabhängig von Signalen etc. Wie gesagt, nur für die eröffnung, die Verarbeitung bereits offener Orders ist mMn ein ganz anderes (unabhängiges) Thema und sollte deswegen auch unabhängig implementiert werden. soweit meine 2 cent ;) Nochwas zum Ablauf: Wenn wir wirklich gemeinsam alles durchgehen wollen, müssen wir uns glaub ich wieder auf einzelne Bereiche beschränken und derweil die anderen Themen außen vorlassen, wenn wir jetzt gleichzeitig über mehrere Funktionen diskutieren und parallel noch neue features vorschlagen, verliert sich das Ganze.
-
Projekt: Entwicklung Community-EA
gern. Ansonsten find ich den Vorschlag von Rainworm gut. Am besten immer den besprochenen Teil direkt als Code einbinden. Einerseits damit man nit zuviel auf einmal angeht, andererseits damit jeder weiß um was es geht ohne den Code parallel offen zu haben und rumscrollen zu müssen.
-
Projekt: Entwicklung Community-EA
Also ich seh es weiterhin als Gemeinschaftsprojekt. Es stimmt, Wolf hat sehr viel allein gemacht, da besteht die Gefahr das es mehr zu "seinem EA mit unseren Anmerkungen" wird. Was is euch lieber: Wolfs EA-Grundgerüst erweitern oder echt komplett bei 0 starten und langsam gemeinsam aufbauen? Wie gesagt, für Anfänger und stille Mitleser ist ein dokumentiertes langsames von 0 weg sicher optimal. Das dauert halt dementsprechend lange bis es dann wirklich fertig ist. Wir können es auch teilen, hier bleibt der "Public learning"-teil wo der EA langsam von 0 aufgezogen wird, wer es eilig hat, kann sich mit Wolf an "seiner" Variante beteiligen. (Würde dafür einfach die entsprechenden Posts auslagern, sofern gewünscht). Damit besteht nur das Risiko das sich die (jetzt schon überschaubare) Anzahl der Mitentwickler halbiert...
-
Projekt: Entwicklung Community-EA
Hi, bin leider gerade etwas eingeteilt und habs nur "überflogen", aber sieht nett aus. Einen Anfänger schreckt es sicher schon ein bissl ab, aber ich befürchte das werden wir nicht verhindern können. Dafür müssten wir wirklich bei fast leerem File starten. @Wolf: Vielleicht könnten wir die Infomaschinerie (also das logging) derweil noch rausnehmen? Ist die Struktur jetzt vorbereitet auf die beschriebene Logik? Magst du vielleicht kurz den Ablauf erklären? Die start() is ja sehr spartanisch. Welche Funktion tut was, wie ist der grobe Programmablauf? Da du hier schon recht weit in der Implementierung bist, wärs dann sicher für andere Coder leichter einzusteigen. Was meinen die anderen? @#import: formal muss es danach nochmal kommen, aber der compiler kommt mit beidem klar.
-
KW44 · DAX30 · Börsentipp-Gewinnspiel
tjo... soviel dazu...
-
KW44 · DAX30 · Börsentipp-Gewinnspiel
Hab i Anfang der Woche auch gedacht... dank der Griechen. Jetzt schauts irgendwie besser aus... dank der Griechen ;) Also derzeit is es echt reines Münze werfen...
-
KW44 · DAX30 · Börsentipp-Gewinnspiel
hast du gleich 2 Prämien gekriegt?
-
KW42 · DAX30 · Börsentipp-Gewinnspiel
also bei mir is Geld jetzt da.
-
KW44 · DAX30 · Börsentipp-Gewinnspiel
dachte das is in D so üblich
-
KW44 · DAX30 · Börsentipp-Gewinnspiel
Die wollen mir den Platz 1 in der EP Hall of Fame wegnehmen, weil ich den Namen von deren Bier hab
-
Zugriffsrechte
Mein Fehler, alle anderen in dem Thread aktiven User, sind schon lang genug da, das sie meine TradeBox kennen/davon gehört haben ;) Hab schlicht darauf vergessen den hinweis als Link auf den Downloadbereich zu machen... mea culpa. Du meinst die DailyRange Sache wegen "next try"? Nicht ganz, das Projekt einen gemeinsamen EA von 0 zu bauen, gabs noch nicht. Es gab aber schön öfters den Fall das jemand einen Ansatz/EA vorgestellt hat wo es teils noch Probleme gab etc. die man dann gemeinsam versucht hat zu beheben. Aber das war dann eben immer eine Hilfe für denjenigen und kein gemeinsames bei 0 starten. btw. die Forumsuche spukt für TradeBox auch das Supporttopic aus, halt als letztes (bei mir)... Aber ich befürchte darauf hast du noch keinen Zugriff (so wie ursprünglich auch bei der codingconvention... auch mein Fehler... ich sollts heut besser lassen ;)