Alles um Metatrader 4.0 - Handelsmethoden und Indikatoren

      Vorschlag zur Nutzung von GitHub

      Nachdem ein Leser es nicht lassen konnte, entgegen allen gesetzlichen Regeln und der Hausordnung eine vollständige private Nachricht zu veröffentlichen, gebe ich sie hiermit als das Urheberrecht besitzender und darum dazu berechtigter User für alle Leser frei. Damit kann sich jeder davon überzeugen, wie konstruktiv, sachlich und ohne hinterbringerische Bosheit meine Vorschläge sind, die ich auch im nicht öffentlichen Schriftverkehr mache:

      Subjekt: Dein Vorschlag zur Programmierung

      Hallo <Anrede mit Vornamen, der hier außer in der verbotenerweise veröffentlichten Mail nicht öffentlich gemacht wurde>!

      (1) Bezugnehmend auf Deinen guten Vorschlag im Tread MT4/MT5-EA´s für außerbörsliche Orderaufgabe wollte ich Dich - als jemanden, der mit professioneller Software-Entwicklung wahrscheinlich deutlich vertrauter ist, als die Mehrheit der Board-User hier - fragen, was Du von der Bereitstellung der Ergebnisse in einer Web-basierten Versions-Verwaltung wie GitHub, Bitbucket oder Co. bzw. einem selbst aufgesetzten Versions-Verwaltungs-Server hältst?

      Hier wird öfter mal Software in verschiedenen Versionen vorgestellt und manchmal sogar einige Male gepflegt, die sich dann sehr unübersichtlich und schwer nachvollziehbar über später kaum auffindbare Artikel verstreut. Wegen einer Mischung aus Unverständnis für die Notwendigkeit vernünftiger technologischer Infrastrukturen und der Faulheit, die nur wenigen wirklich nötigen Kommandos überhaupt anzusehen (von "einzuarbeiten" will ich gar nicht sprechen), war es hier bisher nur in einem einzigen Projekt (über eine eher nur zur Demo eingestellte Seite hinaus) möglich, GitHub zu nutzen. Die meisten hier mal erstellten Softwares sind dann auch früher oder später nicht mehr weiter gepflegt beerdigt worden.

      (2) Für gut versionierbare, weniger Software-Abhängigkeiten schaffende und auf die wesentlichen Gestaltungs-Elemente beschränkten (und damit auch für durchschnittlich in der Text-Verarbeitung versierte Menschen noch komfortabel erstellbare) Dokumentationen (Ideen, Pläne, Designs, Entwickler- und Nutzer-Doku) ist übrigens Markdown (präziser standardisierte Version CommonMark) besser geeignet als die extrem aufgebläht-unübersichtlichen Word-/OpenOffice-XML-Zip-Formate. Diese tendieren mit ihren überbordenden Gestaltungs-Möglichkeiten nicht gerade zu konzeptueller Layout-Einfachheit und können bei weitergehender Ausschöpfung der Möglichkeiten die Dokumente auch ziemlich anfällig für teils größere Probleme bei auch nur minimalen Änderungen machen.

      (3) Bezüglich der von Dir angeforderten Dokumentation lasse ich mich mal überraschen, denn die meisten bisher veröffentlichten User-"Systeme" ließen sich am Ende trotz immer neuer "Regeln" nicht in Performance und Volatilität stabilisieren und wegen dieser immer neuen "Regeln" auch nur schwer formalisieren oder sie waren so plump, dass sie eine Trennschärfe von 50:50 und damit nicht mal einen Ansatzpunkt zur Verbesserung hatten. Andererseits gab es hier wohl schon mehr als eine Implementation zum Feierabend-Trading (eine wohl auf einem Raspi), die nach irgendwas scannten, also gibt es wohl User, die genug Anhaltspunkte heraus lesen konnten.

      Ich wünsche Dir viel Erfolg und stehe Dir für konstruktive Zusammenarbeit auch (mit nicht überbordendem Zeit-Budget) zur Verfügung. Wegen verschiedenener, jeweils gut begründeter Ursachen, die nicht von allen Beteiligten übermäßig positiv aufgenommen würden, nehme ich am Feierabend-Trading-Thread aber kaum teil und lese im Gegensatz zu den meisten anderen Threads auch nur sporadisch einzelne Artikel daraus.

      Außerdem ich selber nicht auf den EOD-TF fokussiert bin, weil er eine völlig unbefriedigende Expectunity bei dünner Datenlage (z. B. gegenüber 5 min oder noch deutlich kürzer) und damit deutlich schlechtere Voraussetzungen für eine Validierung von Trading-Ideen mit ausreichender statistischer Power hat. Schein-Backtests ohne ausreichende statistische Power sind aber trotz erheblichen Aufwandes, bis man sie fertiggestellt hat, methodisch so fehlerhaft. dass sie unabhängig von ihren scheinbar pseudo-exakten sonstigen Kennzahlen nicht mal in der Lage sind, die Wirksamkeit einer Strategie zu belegen, geschweige denn einzelne Elemente daraus als besonders geeignete Kandidaten zur Optimierung zu priorisieren.

      Beste Grüße, NG

      ---

      Ich merke auch noch an, dass die Antwort auf diese Email dürre 4 Worte waren, die weder Inhaltliches einbrachten noch eine weitere Beschäftigung mit dem Vorschlag oder einen sonstigen Verbleib andeuteten. Deshalb sind einige Zweifel bezüglich eines echten Wunsches nach konstruktiver Mitarbeit, die sich durch Unmengen von Posts, denen ein erkennbarer zielführender roter Faden fehlt, nicht überdecken lassen, immer noch vorhanden.

      Statt in einem fort, denkbare Mitstreiter zu brüskieren, sollte jetzt mal nachnutzbare Leistung kommen.

      @NG

      Nein, ein Crack bin ich nicht. Es tauchen immer noch viele spanische Dörfer auf wenn ich mal so Diskussionen unter Informatiker verfolge. :)

      Der Candletalk-GitHub ist eine tolle Sache und wünschenswert dass er sich füllt, denn allzu programmierlastig scheint der Candletalk ja eigentlich gar nicht zu sein.

      GitHub-Repository zur Demonstration

      Das Clean-Code-Development hat als Devise das Erreichen höchster Qualität durch einen permanenten transparenten Verbesserungs-Prozess. Die Grund-Ideen wurden insbesondere zusammenhängend und unter diesem Namen im IT-Kult-Buch von Robert C. Martin: Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code beschrieben, wozu es auch das neuere Nachfolge-Werk Clean Coder: Verhaltensregeln für professionelle Programmierer gibt. Eine deutsche Seite dazu ist clean-code-developer.de.

      Eine ganz wichtige Vorgehensweise darin ist, seinen eigenen, aber auch fremden !! Code beim Bemerken auch noch so kleiner Verbesserungs-Möglichkeiten umgehend anzupassen. Das wird von R. C. Martin mit vorbildlichen Pfadfindern verglichen, die einen Rastplatz sauberer verlassen sollten, als sie ihn vorgefunden haben. Code, der nicht mehr diesem lebenden Verbesserungs-Prozess unterliegt, beginnt umgehend in einer Zombie-Existenz zu vergammeln, da er in gewisser Hinsicht schon geistig tot ist.

      Das gilt selbst, obwohl sich der Code rein datenmäßig natürlich auch in unendlich langer Zeit nie ändert. Aber es gibt kein Interesse mehr, an ihm Erfahrungen und Einsichten zu sammeln und ihn für neue Dinge anzupassen. Irgendwann ist er dann soweit vom aktuellen state-of-the-art entfernt, dass ihn niemand mehr anfassen möchte, selbst wenn es dafür neu auftretenden Bedarf geben sollte, so dass er dann zugunsten einer völligen Neuprogrammierung entsorgt wird.

      Damit diese häufig vorzunehmenden Änderungen lebendigen Codes nicht in unvorhersehbaren neuen Fehlern enden, sollte zu jedem erstellten Programm auch ein Test-Rahmen für eine ausreichende Anzahl von Fällen mitgeliefert werden, der die zu erzielenden Resultate automatisch prüfen kann. Für eine langfristige Qualitäts-Erhaltung und den Einsatz automatischer Prüfungen sind solche Test-Rahmen absolut unerlässlich. Ehrlicherweise muss aber auch gesagt werden, dass das Erstellen umfangreicher automatischer Tests in der Größenordnung des Aufwandes durchaus mit der zu prüfenden Software vergleichbar werden kann.

      Ich stelle wie im letzten Post vorgeschlagen mal eine minimal verbesserte Version in einem eigenen GitHub-Repository ein.

      Die Änderungen beziehen sich auf das Isolieren auch in ähnlichen Aufgaben allgemein nutzbarer Funktionen, die durch Übergabe einer konkreten Funktion abstrakt, aber sofort anwendbar gehalten werden können.

      Auf den oben erwähnten Test-Rahmen habe ich in diesem Fall mal verzichtet, weil das Programm eigentlich mehr als Demo zum Hineinsehen in GitHub gesehen werden sollte und nicht gleich als über zig Files gehende Build-Umgebung mit vielen Abhängigkeiten untereinander, die dann doch eine gewisse Einarbeitung erfordern.

      Lesen von Code Anderer kann eine wertvolle Inspiration sein

      @ weberm

      Die Programmierung eines neuen Problems bringt immer neue Einsichten und Erfahrungen und neben der eigentlichen Problem-Lösung geht es bei professioneller Herangehensweise gerade auch um das Mitnehmen dieses Skills-Gewinnes, der für die künftige eigene Entwicklung oft wertvoller sein kann als die vielleicht nur kurzzeitig bedeutende monentan erarbeitete konkrete Problem-Lösung.

      Obwohl Du nach eigener Aussage (noch?) kein absoluter Programmier-Crack bist, habe ich mir Deine Lösung eine ganze Weile Zeile für Zeile genau angesehen, einfach nur, um mich in die Intentionen anderer Programmierer hinein zu versetzen. Insofern empfand ich es als durchaus produktiven Gedankenaustausch und sehe bei beiden Lösungen ihre Berechtigung und Möglichkeiten zur Verbesserung.

      Bei den Internet-Standards, den sog. RFC (Requests for Comments) wird vor einer Verabschiedung sogar gefordert, dass es aus Prinzip in sehr begrenzter Zeit zwei unabhängige Implementationen gibt. Das wird so streng gehandhabt, dass die aus guten Gründen am meisten auf der ganzen Welt genutzte Datenbank-Software SQLite leider kein Internet-Standard werden konnte, weil niemand einen Grund sah, ein langjährig exzellent bewährtes System noch einmal nachzuprogrammieren.

      Würden die programmierenden User in diesem Forum professioneller zusammen arbeiten, wäre auch die Nutzung einer Quellcode-Verwaltungs-Plattform wie GitHub sehr praktisch. Damit könnten dann einmal in Angriff genommene Projekte von mehreren Programmierern gemeinsam voran geschrieben werden. Dann wären auch minimale Veränderungen sofort einfach einbringbar ohne den für die Veröffentlichung einer nur marginalen Änderung von den Meisten gegenüber einem erneuten Foren-Post als zu groß empfundenen Overhead und einem möglicherweise empfundenen "Wichtig-Tu-Faktor" in der Nähe aufdringlicher Doppelposts.

      Es gibt dort seit Mail 2012 sogar einen User Candletalk, für den Hintman freundlicherweise den Namen und sein Logo gestattete, welcher für eine Zusammenarbeit zur Programmierung einer Untersuchung von zwei Strategien geplant war. Das Interesse bis auf die zwei aktivsten reale Beiträge liefernden Teilnehmer war dann aber nicht so groß, dass das es damals nicht weiter verfolgt wurde, zumal bei den beiden Haupt-Aktiven berufliche und persönliche Gründe wenig Zeit ließen, so dass dort derzeit keine Projekt-Repositories vorhanden sind.

      Auf jeden Fall würde das Weiterschreiben von einmal begonnenen Quelltexten, mit den Services einer Quelltext-Verwaltung, die versehentlich eingebaute Fehler durch nachvollziehbares Aufbewahren aller Zwischenstände leichtestens reparieren lassen, deutlich professioneller sein, als das zig Posts auseinander liegende Posten sporadischer Quelltext-Änderungen mit nur mühevoller manueller Nachvollziehbarkeit. Gerne können alle interessierten User Schreibrechte für die Candletalk-Repositories erhalten, wenn sie mir den dazu nötigen SSH-Key schicken.

      Für die Bekanntheit des Candletalk als Hort professioneller Finanz-Experten wäre die Bündelung auf dem neuesten Stand befindlicher kollektiv gehüteter Quellcodes eine deutliche Steigerung der Reputation gegenüber verstreuten und später nur noch zufällig auffindbaren Leistungen, die bei ihrer Erstellung ja ein durchaus nicht triviales Maß an Kreativität verlangt haben, deren Ergebnis alleine wegen effektiver Nichtauffindbarkeit vom Untergang bedroht ist.

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Norbert Gundeler“ ()

      @NG
      Danke für deine Mühe und das Lob! Jetzt habe ich fast ein schlechtes Gewissen, weil es doppelt gecodet wurde.

      Für mich war das Arbeiten mit datetime das erste Mal. Auch wenn beide Skripte zum Ziel führen, kann man gut sehen, dass man sich kleine Umwege – wie die Berechnung des Datums zu Umstellung der Sommer-/Winterzeit - sparen kann, wenn man die vorhandenen Module bereits gut kennt.

      Ich hatte auch eine Variante zubereitet, aber als ich sie posten wollte, hatte weberm seine schon in durchaus sehenswerter Form :thumbup: fertig.

      Da sie die Timezonen-Datenbank benutzt, so dass man sich nicht um jedes Detail der weltweiten Zeitumstellungen kümmern muss (was vielleicht für andere Aufgaben mit mehreren Zeitzonen interessant sein könnte), poste ich sie trotzdem, obwohl ich als intensiver Kommandozeilen-User nicht mit so schönen Dingen aufwarte, wie weberm mit einem File-Dialog.

      Ansonsten merke ich an, dass meine Dukascopy-Download-Daten ein anderes Format haben:

      Quellcode

      1. 09.11.2015 00:36:00.000,1.07396,1.07406,1.07394,1.07395,65949996.9482

      Python-Quellcode

      1. #! /bin/python
      4. # Converts a Dukascopy historical quote file line by line from
      5. # quote time in GMT time zone to quote time in MET/MEST time zone.
      6. #
      7. # usage: Dukascopy_time_converter.py <input.csv> ...
      8. #
      9. # Will create output files named <input.converted.csv>
      10. # in same directory as input files.
      11. #
      12. #
      13. # Needs package pytz, which can be installed with the command:
      14. #
      15. # easy_install --upgrade pytz
      16. # or perhaps some similiar as:
      17. # easy_install-2.7 --upgrade pytz
      20. import csv
      21. import datetime
      22. import os.path
      23. import pytz
      24. import sys
      27. def main():
      28. """top level entry function"""
      30. # datetime related configuration
      32. local_time_zone = pytz.timezone('Europe/Berlin')
      33. datetime_format = '%d.%m.%Y %H:%M:%S.%f'
      35. # function definitions for details of work
      37. def convert_file(in_file_name):
      38. """do conversion for one file"""
      40. def get_out_file_name(in_file_name):
      41. """derive output file name from input file name"""
      42. out_file_infix = '.converted'
      43. return out_file_infix.join(os.path.splitext(in_file_name))
      45. def copy_head_line():
      46. """simple copy of header line"""
      47. csv_writer.writerow(csv_reader.next())
      49. def convert_data_lines():
      50. """convert data lines after the header line"""
      51. for line in csv_reader: # reader is now on first data line
      52. csv_writer.writerow(convert_line(line))
      54. def convert_line(line):
      55. """convert one data line"""
      56. line[0] = convert_utc_to_local_time_zone(line[0])
      57. return line
      59. def convert_utc_to_local_time_zone(string):
      60. """converts a datetime string in UTC time zone to local time zone"""
      61. utc = datetime.datetime.strptime(string, datetime_format)
      62. utc = utc.replace(tzinfo = pytz.utc)
      63. local = utc.astimezone(local_time_zone)
      64. local = local_time_zone.normalize(local)
      65. local = local.strftime(datetime_format)
      66. return local[0:-3]
      68. # open files and CSV reader and writer and call worker functions
      70. out_file_name = get_out_file_name(in_file_name)
      71. with open(in_file_name ) as in_file :
      72. with open(out_file_name, 'w') as out_file:
      73. csv_reader = csv.reader(in_file )
      74. csv_writer = csv.writer(out_file)
      76. copy_head_line()
      77. convert_data_lines()
      79. # loop over all files given as arguments
      81. for in_file_name in sys.argv[1:]:
      82. convert_file(in_file_name)
      85. main()

      weberm schrieb:

      Kennt jemand ein Skript, das die Dukascopydaten in MESZ inkl. Sommer-/Winterzeit bringt?


      Okay, hab's in Python hinbekommen. Hier der Code falls jemand Bedarf hat: PasteBin

      Das Skript setzt die Dukascopydaten in unsere Zeitzone und stellt auch automatisch auf Sommer-/Winterzeit um. Ebenso werden jegliche Weekend-Daten weggelassen. Das Ausgabeformat kann man dann easy in den Metatrader importieren.

      Voraussetzungen:
      • Die Daten müssen wie beschrieben in einem bestimmten Datumsformat von Dukascopy heruntergeladen werden.
      • Im Skript selbst muss man händisch das zu transferierende Asset eingeben (also z.B. EURUSD, GBPUSD)

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „weberm“ ()

      MT5-MQL5-Syntax- und -Konzepte auch in MT4-MQL4

      Ich habe lange nichts mehr im MT4 programmiert, da ich den MT5 nutze. Nachdem ich jetzt wieder mal dazu animiert wurde, stelle ich befriedigt fest, dass es im MT4 seit Build 600 vom 03.02.2014 dort eine weitgehende Vereinheitlichung von Sprache und Entwicklungsumgebung in Richtung MQL5, einer richtigen objekt-orientierten, an C++ angelehnten Version von MQL4 gibt.

      Es bleiben zwar Unterschiede im Handling im MT4 und MT5, aber die Sprache hat damit deutlich gewonnen. In der Uralt-Version von MQL4 fehlten einfach zu viele oft gebrauchte Konstrukte, wie Strukturen. Dass jetzt eine weitgehende Vereinheitlichung vorhanden ist und die Sprache sich deutlich professioneller anfühlt, ist ein sehr großer Fortschritt.

      Jetzt kann man endlich auch vernünftig für den MT4 entwickeln. Ich schreibe dieses Post eigentlich nur, weil in diesem Forum sich dazu noch niemand geäußert hat und vielleicht auch Andere da nicht so sehr den Fokus drauf hatten.

      OpenCL

      Im MT5 kann man dafür geeignetes Number-Crunching mittels OpenCL auch auf die Graphik-Karten mit einer eigens dafür vorgesehenen OpenCL API auslagern. Wenn ich dafür Zeit habe, werde ich das auch mal für reale Anwendungsfälle benchmarken.
      Bilder

      • OpenCL.png

        14,16 kB, 1.255×137, 504 mal angesehen

      Möchte was austesten und ich weiss, bzw. habe es schon mal selbst ausprobiert, dass man sich die candle einzeln anzeigen lassen kann und dann mit " enter " die nächste Kerze usw.
      Wenn man so will einen backtest.

      Haber hier schon gesucht, aber leider nichts gefuden.

      Weiss jemand wie man das bei metatrader 4.0 macht.

      Danke
      Harley
      Wer Rechtschreibfehler in meinen Beiträgen findet, darf sie gerne behalten!
      candletrading.de/blog/category/tradingblogs/harley-fgbl/

      Die Alpari-Demo liefert bei mir seit 24. Juli keine Daten für den DAX mehr (Symbolname _GX). Hat jemand ähnliche Probleme oder am besten eine Lösung?
      Welche anderen Metatrader-Anbieter ohne Laufzeitbegrenzung der Demo gibt es im Moment?

      Gruß Shakesbier
      Gruss Shakesbier
      Two Bier or not two Bier (Shakesbier) :D