Maschinelles Lernen im Handel: Theorie, Modelle, Praxis und Algo-Trading - Seite 1196
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Wunderschön!
Frage als Python-Spezialist, geben Sie mir etwas in Python für Experimente, ich habe fast herausgefunden, Sharp, es Links mit MT5 ohne Probleme überhaupt, C # und Python sind angeblich unterstützt, dann kann ich zu Python als auch bewegen ;)
Python hat NICHTS mit unserem Problem zu tun. Python ist ein Haufen von allem und jedem, was für uns nützlich sein kann, ein Hinterwäldler-Subplot mit obskuren Versionen, die nicht von oben bis unten kompatibel sind. Die Unterstützung von Python ist rein rustikal, auf Enthusiasten. Annehmbare Paketrubriken in Python gibt es nicht als solche. Alles, was in Python zu finden ist, ist eine Forumssuche, von Enthusiasten.
Dies wird besonders deutlich, wenn man Python mit R vergleicht. R ist unser Händlersystem mit einem ausgezeichneten Referenzapparat und unserem Rubricator. Es gibt keinerlei Probleme, die benötigten Werkzeuge zu finden. Jedes Paket ist gut dokumentiert: Beschreibungen von Funktionsaufrufen, Links zu Algorithmen, die diese Funktionen implementieren, Beispiele, Links zu Artikeln, die sich auf das Paket beziehen. R kann als Lehrbuch für jedes Problem verwendet werden. Und das gesamte Material ist absolut konkret und wird durch den entsprechenden Code unterstützt.
Python hat keinen Vorteil gegenüber R und kann ihn auch nicht haben, weil alles, was für uns interessant ist, in Cp geschrieben ist, während Python oder R die Shells für diese Pakete sind. Manchmal schlägt Python die Entstehung neuer Pakete, weil es keine Anforderungen an die Paketgestaltung und weitere Unterstützung gibt. Alles, was auf R Mirrors erscheint, wird moderiert und Müll wird herausgefiltert.
Die Kehrseite von R ist Srr, R selbst ist in Srr geschrieben und hat eine perfekt dokumentierte Schnittstelle zwischen R und Srr. Es ist also jederzeit möglich, die R-Shell wegzulassen und das in Srr geschriebene Tool selbst direkt aus Programmen auf MCL zu verwenden.
Eine letzte Sache. Soweit ich weiß, gibt es noch keine Brücke zwischen Python und MCL. Aber eine solche Brücke zwischen R und beiden MCLs gibt es schon seit vielen Jahren, sie ist in kodobase frei verfügbar, und es gibt keine Beschwerden - alles funktioniert stabil, der Tester funktioniert und ich habe noch keine Beschwerden über die Geschwindigkeit gesehen: Daten werden im Speicher gesendet.
Python hat überhaupt NICHTS mit unseren Problemen zu tun. Python ist ein Haufen von allem und jedem, was uns nützlich ist, ein Hinterwäldler-Subplot mit unverständlichen Versionen, die von oben bis unten nicht kompatibel sind. Die Unterstützung von Python ist rein rustikal, auf Enthusiasten. Annehmbare Paketrubriken in Python gibt es nicht als solche. Alles, was in Python zu finden ist, ist eine Forumssuche, von Enthusiasten.
Dies wird besonders deutlich, wenn man Python mit R vergleicht. R ist unser Händlersystem mit einem ausgezeichneten Referenzapparat und unserem Rubricator. Es gibt überhaupt keine Probleme, die benötigten Werkzeuge zu finden. Jedes Paket ist gut dokumentiert: Beschreibungen von Funktionsaufrufen, Links zu Algorithmen, die diese Funktionen implementieren, Beispiele, Links zu Artikeln, die sich auf das Paket beziehen. R kann als Lehrbuch für jedes Problem verwendet werden. Und das gesamte Material ist absolut konkret und wird durch den entsprechenden Code unterstützt.
Python hat keinen Vorteil gegenüber R und kann ihn auch nicht haben, weil alles, was für uns interessant ist, in Cp geschrieben ist, während Python oder R die Shells für diese Pakete sind. Manchmal ist Python dem neuen Paket voraus, weil es keine Anforderungen an das Paketdesign und die Wartung gibt. Alles, was auf R Mirrors erscheint, wird moderiert und der Müll herausgefiltert.
Die Kehrseite von R ist Srr, R selbst ist in Srr geschrieben und hat eine perfekt dokumentierte Schnittstelle zwischen R und Srr. Es ist also jederzeit möglich, die R-Shell wegzulassen und das in Srr geschriebene Tool selbst direkt aus Programmen auf MCL zu verwenden.
Eine letzte Sache. Soweit ich weiß, gibt es noch keine Brücke zwischen Python und MCL. Aber eine solche Brücke zwischen R und den beiden MCLs gibt es schon seit vielen Jahren, sie ist in kodobase frei verfügbar und es gibt keine Beschwerden - alles läuft stabil, der Tester funktioniert und ich habe noch keine Beschwerden über die Geschwindigkeit gesehen: die Daten werden im Speicher gesendet.
Ich bevorzuge auch R, aber ich glaube, dass die Zukunft in unserem Bereich in Python liegt. Sie können darauf ein komplettes geschlossenes System aufbauen, von der Analyse bis zum Handel. Ein Beispiel ist Quantopian. Das wird bei R nicht funktionieren.
Ich bevorzuge auch R, aber ich glaube, dass die Zukunft in unserem Bereich in Python liegt. Damit lässt sich ein komplettes geschlossenes System aufbauen, von der Analyse bis zum Handel. Ein Beispiel ist Quantopian. Das wird in R nicht funktionieren.
Warum klappt es nicht? Ich habe den Eindruck, dass dies bereits seit vielen Jahren der Fall ist. Es gibt ein eigenes IBrokers-Terminal, das eine API zu demselben Broker wie quantopian hat.
Noch einmal: Python ist die gleiche Shell wie R. Nur R ist eine ernstzunehmende Entwicklung, während Python ein praktisches Werkzeug ist, das viele Nutzer hat, die nicht zu unserem Kerngeschäft gehören und Lärm verursachen.
Die Kehrseite von R ist Srr, R selbst ist in Srr geschrieben und hat eine perfekt dokumentierte Schnittstelle zwischen R und Srr. Daher ist es jederzeit möglich, die Shell in R wegzulassen und das Werkzeug selbst, das in Srr geschrieben ist, direkt aus Programmen in MKL zu verwenden.
Das ist wahrscheinlich der Grund, warum die Brücke für R in Pascal geschrieben ist.
Sie wären ein guter Verkäufer, herzlichen Glückwunsch
Sie wären ein guter Verkäufer, herzlichen Glückwunsch.
Nennen Sie mindestens ein weithin bekanntes und beliebtes (nicht bei Ihnen, sondern in der Weltgemeinschaft) Paket für maschinelles Lernen in R.
Gibt es noch andere? Nicht in R? Es gibt fast 200 von ihnen in caret shell allein und nicht alle, wie keras selbst. Möchten Sie, dass ich Statistiken über ihre Verwendung in der Weltgemeinschaft sammle?
Das ist alles nur leeres Gerede, wie jedes Gespräch über die Wahl einer Programmiersprache. Ich bin kein Fan von Podlouches. Und das ist für mich das entscheidende Kriterium. Jedem das Seine.
Gibt es noch andere? Nicht bei R? Allein in der Caret-Shell gibt es fast 200 von ihnen, und nicht alle, wie Keras selbst. Möchten Sie, dass ich Statistiken über ihre Verwendung in der Weltgemeinschaft sammle?
Das ist alles nur leeres Gerede, genau wie jedes Gespräch über die Wahl einer Programmiersprache. Ich bin kein Fan von Podlouches. Und das ist für mich das entscheidende Kriterium. Aber jedem das Seine.
Nun, ich sehe, dass sie beginnen, R hinzuzufügen, wie TFlow und MXnet, vorher war es nur Python.
Das ist wahrscheinlich der Grund, warum die Brücke für R in Pascal geschrieben ist.
Welchen Unterschied macht es, in welcher Sprache sie geschrieben ist?
Die Brücke wurde vor 10 Jahren geschrieben, damals wurde sie verwendet, um Studenten das Programmieren beizubringen. Dann starb Pascal plötzlich.
Aber der Hauptvorteil der Brücke - die Primitivität, es erfordert keine Zeit zu meistern.
Ich habe hier sogar eine Zweigstelle eröffnet und mich bemüht, etwas Anständigeres zu schreiben, sogar die ToR zu formulieren, aber niemand will es, also haben wir, was wir haben. Python hat das auch nicht.
Ok, ich sehe, dass sie angefangen haben, R hinzuzufügen, wie TFlow und MXnet, bevor es nur Python gab
Ich habe im Forum geschrieben: Ich sehe keinen Vorteil darin, ein Paket durch ein anderes zu ersetzen. Das ganze Problem sind die Prädiktoren und ihre Vorhersagekraft für eine bestimmte Lehrkraft. Wenn dieses Problem gelöst ist, kann man auf Kosten des Pakets ein paar Prozent des Fehlers loswerden, aber das ist die Mühe nicht wert.