Mythos

Ich sag mal so: es wäre praktisch wenn man das könnte, weil dann könnte ich nachschauen... Ich werd mal versuchen was zusammenzuschreiben. Edit: hab nachgeschaut, es gibt schon ein bissl was: http://www.tom-next.com/community/topic/59173-exchange-guide/#entry116203 Da sind die Funktionen die der User sieht dokumentiert. Wie gesagt, ist nicht viel aber eben genau das was ich wollte genau so drin wie ich es wollte. Ohne Kompromisse (abgesehen davon das man alles immer noch mehr erweitern und verbessern könnte ;) ^^ Die 95% waren eigentlich nur ein "Extrembeispiel". Ich persönlich glaub nicht das es mit entsprechenden hohen Anforderungen eine Lib gibt die über 60%-70% kommt (aber ich kenn einfach zuwenige um hier wirklich ein Urteil fällen zu können). Das geht los bei der Art der Datenverwaltung (welche History ist möglich, wie performant werden große Datenmengen verarbeitet), über die Anpassung des Stils (Schriftarten, Positionierung, Hintergrundfarben/Bilder, Icons) bis zum Funktionsumfang für den User. Und vor allem bei der Datenverwaltung merkt man meist erst bei der direkten Entwicklung obs geht oder nicht, bzw. muss sich dann auf Kompromisse oder Workarounds einlassen. Das heißt jetzt nicht das die Libs schlecht sind oder zuwenig Umfang haben, aber es decken sich halt zB nur 40% des Lib Umfangs mit den eigenen Anforderungen. zB bei Netdania: Wenn ich da im Menü und Properties etc. herumschaue steckt massiv was dahinter im Bereich Designanpassung und so. Für mich stellt sich die Frage ob man das braucht, auf der anderen Seite muss man im Menü herumsuchen um zu zoomen...

lol keine Ahnung. Das war damals aber auch viel learning-by-doing für die Basics. Ohne die Datenanbindung und alles (was man bei einer Bibliothek ja auch selber machen müsste) kannst das TEFEx-Charting vermutlich in einer Woche (inkl. buffer für den ganzen Kleinkram den ich jetzt vergessen hab, testen etc.) neu schreiben. Da steckt ja auch nit soo viel drin. Keine Objekte, keine Indis etc. Jo, liegt aber hauptsächlich an meiner schlechten Erfahrung mit Chart-bibs (hab aber möglicherweise nur die falschen getestet). Ich bin grundsätzlich der Meinung "im Zweifel selber schreiben". Vor allem wenn man gewisse Anforderungen an das Ding hat, es frei erweiterbar sein soll und der geschätzte Aufwand nicht zu massiv ist. Ich meine es gibt sicher möglicherweise gute Bibliotheken die 95% der Anforderungen abdecken, aber wenn man eine "perfekte" Lösung haben will, dann muss man sich vorab überlegen ob nicht die restlichen 5% (wenn überhaupt machbar mit der Bibliothek) nicht aufwändiger werden als wenn man das ganze selber entwickelt hätte. Und beim Charting ist es mMn so...

Für den laufenden Betrieb (also wenn das System "funktioniert" und läuft) bin ich voll bei dir. Da sollte man alles raushauen was man nit braucht und performance kostet. Aber für die Entwicklung des Systems braucht man mMn sehr viel charting und grafische Auswertungen der Backtests. Aber da ist die Frage ob man das wirklich selber schreiben muss. Man kann ja die Logik in einer vorhandenen Software (MT, NT, MC oder wie sie alle heißen) entwickeln und das fertige System dann erst selber umsetzen.

Kommt drauf an in welcher Form du das Prog hast. Ggf. kannst versuchen auf die Klassen zuzugreifen bzw. per Profiler dir anschauen welche Klassen geladen werden und dementsprechend rückschlüsse ziehen (die packagestruktur enthält normal die domain etc.). Ansonsten bleibt dir glaub ich nur die Optik und ggf. Lizenzfiles. Nö is mir keine bekannt. Ich würd jetzt auch mal in Frage stellen ob es sowas gibt. Vor allem wenn es wirklich anspruchsvoll sein soll. Der Nachteil an einer Lib ist ja immer das sie entweder sehr speziell für einen konkreten Zweck ist (und alles darüber hinaus wieder selber gecodet werden muss) oder super allgemein aber dafür eben einen ziemlichen overhead hat (weil man eben nit alles braucht, bzw. details anders). TEFEx Charting is ein schönes Beispiel: Ursprünglich wollt ich eine Lib nutzen, nur die war zu langsam und aufgebläht, deswegen hab ichs dann komplett selber geschrieben. Damit hat man einfach die komplette Kontrolle über Funktion und Aussehen, und kann auch das Hauptaugenmerk auf das legen was wichtig ist (zB Speed). Zur Frage: TEFEx Charting basiert auf mythos. Ich kenn jetzt nit viele Chartingplattformen, aber ich kann mir nit vorstellen das eine von den "mächtigeren" das Charting nit selber geschrieben hat...

Hallo Uwe und willkommen bei Tom-Next. Da bist du definitiv nicht alleine und findest hier definitiv sehr viele Ansprechpartner und Hilfe in allen Bereichen. Da muss ich dich gleich warnen: (gut) programmieren zu können hilft definitiv wenn man ein automatisches Handelssystem schreiben will. Aber das wichtigste ist "das System". Sprich die Handelslogik. Und eine funktionierende Handelslogik zu finden erfordert mMn viel Erfahrung mit dem Markt und Hintergrundwissen. Also wenn du mit "schlechter Trader" den psychischen Part meinst, dann ist ein Handelssystem das Beste was du machen kannst. Wenn du ein "schlechter Trader" im Sinn von "ich finde keine funktionierende Logik" meinst, dann hilft auch kein Handelssystem. Will dich aber nicht demotivieren (nur warnen), einen Versuch ist es auf jeden Fall wert ;)

Das Problem ist sicher nicht auf das Internet beschränkt, aber durch die "Anonymität" des Internet wirds glaub ich deutlich verstärkt. Vor allem weil es plötzlich "global" wird. Früher konnte man von den Kindern in der eigenen Schule/Dorf gemobbt werden. Heute kann ein Kind aus Hintertupfing ein anderes aus Berlin mobben ohne es jeh gesehen zu haben, einfach nur "weil alle es machen" bzw. es keine andere Möglichkeit hat seinen Frust abzubauen. Und durch diese geographischen Entfernungen sind die Angreifer auch im wesentlichen unantastbar. Wenn ein Kind aus der Schule übertrieben hat, gab es früher ein Gespräch zwischen den Eltern oder so. Versuch das mal von Hintertupfing nach Berlin. Von den 30% bin ich ehrlich gesagt nicht überrascht, vor allem wenn man sich die derzeitige Situation in den Schulen ansieht. Da hätt ich schon fast mit mehr gerechnet. Was man dagegen tun kann: Keine Ahnung, ich denk die einzige Möglichkeit ist bei der Erziehung der Kinder anzusetzen... aber wie gesagt: keine Ahnung wie.

Mit iBarShift ;) Du kannst beim Umrechnen von Indizes zwischen den Timeframes nur nach der Zeit gehen, da du ja keine Garantie hast wieviele Bars es in kleineren Timeframe gab. Also entweder iBarShift oder so wie WOGO den höheren TimeFrame parallel checken und den index updaten

Was spricht gegen iBarShift? int start() { int i,counted_bars=IndicatorCounted(); //---- check for possible errors if(counted_bars<0) return(-1); //---- last counted bar will be recounted if(counted_bars>0) counted_bars--; int limit=Bars-counted_bars; if(Period()>PERIOD_H4) return(-1); double last_week_low,last_week_high; for(i=limit-1; i>=0; i--) { // 1sts Days of Week if(TimeDayOfWeek(Time[i])<=2 && TimeDayOfWeek(Time[i+1])>=4) { //we are at the first bar of the week, means nearest bar in W1 is this weeks bar int shift= iBarShift(Symbol(),PERIOD_W1,Time[i],false); last_week_low=iLow(Symbol(),PERIOD_W1,shift+1); last_week_high= iHigh(Symbol(),PERIOD_W1,shift+1); } low_Buffer[i]=last_week_low; high_Buffer[i]=last_week_high; } //---- return(0); } (habs jetzt aber nit getestet... )

ObjectGet liefert ein double. Typ ist also richtig. Mein Fehler, bei yDistance retouniert es int, der cast sollte aber funktionieren, sprich 0 bleibt 0. Warum du die 0 zurückbekommst: Weil die yDistance von longAR2 0 ist. PS: bitte code auch wirklich in code-tags einbetten zwecks Lesbarkeit. Danke.

Jup, Der Bias der einzelnen Sensoren etc. wird sicher auch ein Prob. Und ja, natürlich is das Erdschwerefeld dabei, i find nur den Namen immer noch irgendwie lustig ;) Klingt immer so ein bissl nach Bullshitbingo (no offense ;) Wollen schon. Wenn GPS innerhalb von Gebäuden (und überhaupt, egal wo) cm genau und realtime funktioniert, dann gern... Der Traum wäre, das ich das Phone in der Hand halte, um ein paar centimeter nach rechts schwenke und das phone die bewegung korrekt erkennt. Ob das in der Form realisierbar ist, ist zugegebenermaßen sehr fraglich, aber i hab ja Zeit und Motivation ;)

Thx, ja ich bin im wesentlichen allein. Is derzeit ein reines Hobby-projekt. Formellastig stört mich überhaupt nit, is sogar gut dann weiß man wovon die Leute schwafeln ;) Derzeit hab ich das Gefühl mein Hauptproblem ist einerseits ein starkes rauschen aus den Beschleunigungssensoren, aber noch schlimmer die Challenge ein möglichst exaktes "wo ist oben" und "wie stark ist die Gravitation/Offset gerade wirklich" zu kriegen. Durch die doppelte Integration tut das Rauschen ziemlich weh. Durch schlechten "Upvektor"/falsche Gravitation gehts erst recht durch die Decke...

Erdschwerefeld... klingt nett ;) Ne es geht um Positionstracking vom Smartphone. Und eben nicht im GPS-Genauigkeitsmodus sondern realtime und (hoffentlich) im cm Bereich. Aufgrund des Rauschens etc. schauts nur derzeit nit gerade hoffnungsvoll aus :(

danke, werd ich mir anschauen. btw. willkommen bei Tom-Next ;)

Danke, ich brauch nicht direkt einen Einstieg sondern suche eher Leute die schon diverse Erfahrungen damit gemacht haben, die Theorie, Herleitungen etc. hatten wir alles auf der Uni. Wie gesagt nicht direkt finanztechnisch. Ich will aus den Messdaten von Gyroscop und Beschleunigungssensor in Summe möglichst gute Schätzungen für die Bewegung des Objekts errechnen... Und die erste Frage ist die richtige Wahl des Models/Zustandsvektors und dann die Frage des Prozessrauschens... aber mal sehen so kompliziert kanns ja nit sein ;)

Man muss auf keinen Fall die gesamte Doku studieren (auch wenn es hilft), aber wo man (sowohl als Anfänger als auch als Profi) nicht vorbeikommt ist die Dokukmentation der verwendeten Funktionen. Du musst sie ja nichtmal suchen, ich habs dir eh schon verlinkt (teils sogar zitiert). Sei mir nit böse, aber selber lesen musst du sie wenigstens schon. Ich helfe ja gerne, aber wenn ich das Gefühl krieg Posts zu schreiben die dann eh nit gelesen werden, dann sinkt meine Motivation sehr schnell.

Klingt gleich wie bei mir. Nur als Vorwarnung (schon wieder): Die Demowerte kannst (vor allem hier) vergessen. Den Demotest solltest du auf rein programmiertechnische Teile des EA konzentrieren (tut er was er soll etc). Ansonsten: Toi toi toi ;)

Ah ok, das is dann ein leicht anderer Ansatz. Wär gespannt obs funkt. Ich befürchte aber, das die Fälle wo der schnelle nur einen schnellen Ausschlag hatte und wieder zurück kommt und die Fälle wo der Langsame im Moment der Order "merkt" das er hinten nach ist und dich nicht ausführt bzw. mit requotes und slipage überhäuft, überwiegen. Im Endeffekt müsstest du ja auch sehr schnell wieder aus dem Markt raus. Weil was bringt es wenn du durch den schnellen broker "weißt" das es gleich 4 Pips raufgeht und auch noch reinkommst (beim langsamen), wenn du die Order trotzdem erst 10 Pips tiefer schließen kannst? Und ich vermute jetzt einfach mal das du beim langsamen genau dann nicht reinkommst, wenn der Kurs in "deine" Richtung laufen würde, und genau dann ausgeführt wirst (wenn auch ggf. mit 1 Minute Verspätung) wenn der Kurs gegen dich läuft...

Das hab ich mir damals auch gedacht. Nur das in der Praxis der lahme Broker vermehrt Requotes gesendet hat, bzw. die Orderausführung genauso lahm war. Das Problem bei Arbitrage ist ja: du musst bei beiden Brokern zeitgleich zum erwarteten Kurs reinkommen. Beim schnellen ist das normal kein Problem. Aber was machst du wenn du zB beim langsamen 1 Minute lang requotes hast? Oder 1 Minute wartest bis überhaupt ein Reply vom Broker kommt? In der Zeit hast du dann eine Position beim schnellen Broker offen die massiv gegen dich gehen kann (vor allem weil Arbitragemöglichkeiten meist in aktiven Marktphasen passieren). Will dir das System nicht ausreden, nur warnen "Been there, done that, messed around".

Das klingt ein bissl wie der RobinHood den wir mal probiert haben. Long story short: Didnt work in real life ;)

Also für das erste Array brauchst du vermutlich noch keine Zeit definieren, da du eh die Time[] von den M1 Daten hast. Mir fällt aber gerade auf das du für den DXY vermutlich aufpassen musst wenn du bei allen symbols nur auf den Index gehst. Ich wär mir jetzt nicht sicher ob alle Symbols das gleiche Time/Index mapping haben... (Sprich ob die Bars gleich sind etc.) Für die Tageshighs etc. wärs dann sicher wichtig in einem zweiten Array mitzuspeichern für welchen Tag diese Werte gelten. Es hängt jetzt davon ab welchen Aufwand du rundherum betreiben willst bzw. wieviele verschiedene Berechnungen du so weiterverarbeiten willst. Aber du könntest zB einen Indikator schreiben der einen Subindikator (deine M1 Berechnung) aufruft und das High/Low der Indikatorperiode selber speichert. Dann übernimmt die Indikatorlogik sozusagen das Zuordnen von Werten zu den Zeiten. Wäre möglicherweise etwas aufwändiger zu coden (muss aber gar nicht sein) aber dafür einfacher zu lesen und besser wiederverwendbar etc.

Nein, iHigh etc. geht nur auf Symbole, nicht auf eigene Arrays. Bei einem eigenen Array kannst du nur mit ArrayMaximum etc. arbeiten. Für manche Indicatoren gibts auch eine "OnArray" Variante. Für ATR scheinbar leider nicht. (Macht irgendwie auch Sinn da ein Array ja nur eine Series ist, ATR aber High und Low braucht.) Was genau willst du machen? Die High und Low Kurve von DXY? Auf den ersten Blick wird das in der Form schwer da die Highkurve ja nicht durch diese Formel mit den Highs berechnet werden kann... Ich glaub das einzige was du machen kannst, ist ihn auf M1 berechnen und dann auf das Array High/Low etc. auszurechnen.

Definitiv! Vor allem wenn er entspannt davon erzählt hat man das Gefühl er berichtet von einem neuen Hollywood-streifen und nicht von seiner Vergangenheit. Das einzige was ich sofort gespürt hab war, das sich sein rechter Fuß noch an die schnellen Autos erinnert ;) ich sag nur "Keine Sorge, das is meine Hausstrecke"

mMn ist dann aber auch die Frage warum Geld die übergeordnete Rolle einnimmt. Abgesehen von Profitgier etc. sind es doch auch wir Konsumenten die hier Druck aufbauen. Solang die Masse nur nach dem Preis entscheidet mit wem sie fliegt, wird/muss bei den Fluglinien auch an allen Ecken und Enden gespart werden. Wenn ein Flug nach London billiger ist als ein Mittagessen, sollte man halt als Konsument auch nachdenken anfangen.

ich glaub du hast meine Posts nicht genau gelesen, das war nur ein Codeteil, kein fertiges Script. Weil AFAIK ein deutlicher Unterschied zwischen MQL5 und MQL4 besteht. MQL5 ist OO, MQL4 nicht. Es kann sein das einige Build-In Methoden zufällig gleich heißen und funktionieren, aber wenn man MQL4 programmieren will, würde ich auch die MQL4 doku empfehlen.... Steht alles bereits in meinen Posts. Hier liegt scheinbar ein gravierendes Missverständniss vor. Es geht nicht darum das wir Code liefern und du den testest und Bemerkungen machst. Sondern DU willst ein Script bauen, und wir sind hier um Fragen zu beantworten und Anmerkungen zu geben. Ich vermute mal das du den von dir geposteten Code noch nicht kompiliert hast, der kompiliert nämlich nicht. 1. Fehlt da Schritt 1 und 3 aus meinem vorigen Post. 2. Hast du scheinbar 2 Codeblöcke derart zusammenkopiert das es weder Sinn noch korrekte Syntax ergibt.

Naja, um eine "Abhandlung" darüber zu schreiben muss man vermutlich ziemlich viel schwafeln, sonst wird das nit lang. Der Erwartungswert ist der Schätzer für den Mittelwert einer Zufallsvariable. Einfacher ausgedrückt: Der Wert um den die Zufallsgröße "schwankt". Genau genommen sagt der Erwartungswert an sich also noch nichts aus. Es ist immer die Frage von was. Im Bereich Trading wird fast immer der Erwartungswert des Gewinns pro Trade genommen. bzw. des Gewinns pro Lot. Der bekannte "durchschnittliche Gewinn pro Trade" ist eigentlich genau der Erwartungswert der Zufallsgröße "Gewinn pro Trade" der aber so gesehen wenig aussagt wenn nicht jeder Trade mit gleichem Risiko gefahren wird. Der Profitfaktor hingegen ist /. Der hat mit den meist verwendeten Erwartungswerten (also von Gewinn pro Risiko, bzw. Gewinn pro Trade) nur sehr entfernt zu tun. Und das er sich darauf bezieht würd ich jetzt überhaupt nicht sehen. Zur Berechnung: Wenn man vereinfacht annimmt man hat 2 mögliche Werte für eine Zufallsvariable (zb TP= 2R und SL = -1R) und kennt die Verteilung (wäre in dem Fall die Trefferquote), dann errechnet sich der Erwartungswert aus der Summe von *. Bei 60% Trefferquote wäre hier Erwartungswert= 0.6*2+0.4*(-1)= 1.2 -0.4= 0.8 Interpretationsmäßig sagt der EW einfach: Wenn man viele stichproben nimmt (zB viele Trades aus dieser Verteilung macht) wird man im Mittel diesen Wert erreichen. In unserem Fall durchschnittlich 0.8R pro Trade gewinnen. Man sieht hier auch gleich wie wichtig die "Einheit" ist. Dieser Erwartungswert wurde in R gemessen wo es nur 2 Werte gab. die gleiche Zufallsvariable in € gemessen, wenn R keinen fixen € Wert hat, ist viel schwieriger zu rechnen da es ggf. sehr viele mögliche Werte gibt deren Wahrscheinlichkeiten nicht mehr so einfach zu bestimmen sind. Aber was bringt es mir wenn ich durchschnittlich 0.8R gewinne, wenn alle 60% Gewinntrades zwar 2R aber nur 100 Euro bringen, aber die 40% Verlusttrades nur 1R aber 200 Euro verlieren. Man kann hier also wie überall in der Statistik, mit korrekter Anwendung der Methoden, trotzdem falsche/wertlose/irreführende Aussagen machen. Und noch schlimmer: es sich unbewusst selber schön rechnen. hth