Maschinelles Lernen im Handel: Theorie, Modelle, Praxis und Algo-Trading - Seite 298
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
Ist es besser, etwas mehr Zeit in die Entwicklung zu investieren und dann immer schnell zu rechnen, oder schnell zu entwickeln und dann immer träge zu rechnen?
Wenn Sie schnell in R entwickeln, aber nur langsam rechnen, wo wollen Sie dann die Berechnungen durchführen? Schnell ein Superauto entwickeln, das langsam zu fahren ist? Ein solches Superauto brauchen Sie nicht.
Bei Forschungsaufgaben steht die Entwicklungsgeschwindigkeit im Vordergrund. Statt einer Person, die superschnellen Code schreibt, aber nur eine Hypothese pro Tag testet, wird eine Person, die langsamen Code schreibt und die ganze Nacht Berechnungen durchführt, aber am nächsten Tag 20 Hypothesen getestet hat, leicht eingestellt werden.
Für die Produktionsimplementierung des Modells ist es einfacher, eine weitere Person gegen ein geringes Gehalt einzustellen, die die vielversprechendsten Modelle in der schnellstmöglichen Sprache umschreibt. Es gibt viele Programmierer und die Konkurrenz ist groß, aber Forscher, die sich etwas Neues einfallen lassen können, sind schwer zu finden :P
Das ist eine gängige Praxis. Suchen Sie nach Stellen als quantitativer Forscher und quantitativer Entwickler. Erstere benötigen in der Regel R/Python, letztere in der Regel C++/Java.
Bei Forschungsaufgaben steht die Geschwindigkeit der Entwicklung im Vordergrund. Anstelle einer Person, die superschnellen Code schreibt, aber nur eine Hypothese pro Tag überprüft, kann eine Person, die langsamen Code schreibt und die ganze Nacht Berechnungen durchführt, am nächsten Tag 20 Hypothesen überprüft haben.
Für die produktive Umsetzung des Modells ist es einfacher, eine weitere Person gegen ein geringes Entgelt einzustellen, die die vielversprechendsten Modelle in einer schnelleren Sprache umschreibt. Es gibt viele Programmierer, und die Konkurrenz ist groß; aber Forscher, die sich etwas Neues einfallen lassen können, sind schwer zu finden :P
Das ist eine gängige Praxis. Suchen Sie nach Stellen als quantitativer Forscher und quantitativer Entwickler. Erstere müssen in der Regel R/Python beherrschen, letztere in der Regel C++/Java.
Wäre es nicht einfacher, fertige und schnelle C++-Bibliotheken zu verwenden, anstatt die gleichen, aber langsamen in R für "schnelle Entwicklung" zu verwenden? Sie, und viele andere hier, tauschen ständig Begriffe aus. In gleicher Weise kann man in einer C-ähnlichen Umgebung "schnell entwickeln". Oder benötigen Sie keine entsprechenden Kenntnisse in Data Mining und Statistik, um in R zu arbeiten? In gleicher Weise benötigen Sie das Wissen, um in C zu entwickeln. Warum also doppelte Arbeit leisten?
Und ich weiß nicht, welche Art von "normaler Praxis" Sie meinen, aber ich bin es gewohnt, alles auf einmal zu erledigen.
Während meiner Tätigkeit als Ingenieur habe ich oft Leute gesehen, die aus irgendeinem Grund dachten, dass sie mit super-duper entwicklungsfreundlicher Software auf jeden Fall gut abschneiden würden... Aber eines konnten sie nicht verstehen: Sie brauchen noch etwas anderes, damit alles gut funktioniert: das Fett in ihren Köpfen.
Ist es nicht einfacher, fertige und schnelle C++-Bibliotheken zu verwenden, anstatt die gleichen, aber langsamen in R für "schnelle Entwicklung" zu verwenden? Sie, und viele andere hier, tauschen ständig Begriffe aus. Genauso kann man in einer C-ähnlichen Umgebung "schnell entwickeln".
Die Wahl der Sprache ist Ihr gutes Recht und Ihre persönliche Angelegenheit. Was die Bibliotheken betrifft, so müssen Sie leider für alle modernen oder ungewöhnlichen Algorithmen alles selbst implementieren. Für die Berechnung der "Bipower-Varianz" (was bedeutet das? :D) habe ich zum Beispiel keine Bibliotheken gefunden.
Oder braucht man keine entsprechenden Kenntnisse in Data Mining und Statistik, um in R zu arbeiten?
Das behaupte ich nicht und ich unterstütze diese Meinung auch nicht.
Und ich weiß nicht, was für eine "gängige Praxis" Sie meinen, aber ich bin es gewohnt, alles auf einmal zu erledigen.
Während meiner Tätigkeit als Ingenieur habe ich oft Leute gesehen, die aus irgendeinem Grund dachten, dass sie mit super-duper entwicklungsfreundlichen Softwarepaketen bestimmt gut zurechtkommen würden... Aber eines konnten sie nicht verstehen - sie brauchten etwas anderes, damit alles gut wurde: das Fett in ihren Köpfen.
Meine Praxis in einigen Projekten mit einer Komplexität von ## Mannjahren, bei denen 95 % des Codes in R geschrieben sind, zeigt, dass verschiedene Tools für verschiedene Aufgaben gut sind, manchmal sogar für langsame, solange sie für Prototypen und nicht für die Produktion verwendet werden. Die Verwendung unterschiedlicher Werkzeuge in verschiedenen Entwicklungsstadien ist in der Entwicklungsbranche gängige Praxis und wird durch die Anforderungen an Spezialisten für unterschiedliche Aufgaben bestätigt. Die von mir erwähnten Projekte wären sehr viel komplexer geworden, wenn sie in einer C-ähnlichen Sprache umgesetzt worden wären, und zwar selbst von Universalsoldaten, die alles wissen und können und die Lösung des Problems sofort und ohne jegliche Forschungsphase schreiben.
Deshalb verabschiede ich mich.
Ist es nicht einfacher, fertige und schnelle C++-Bibliotheken zu verwenden, anstatt die gleichen, aber langsamen Bibliotheken in R für eine "schnelle Entwicklung" zu verwenden?
Bei der Diskussion um R habe ich immer auf eine umfassende, systematische Bewertung dieses "Grafik- und Statistiksystems" gesetzt. die algorithmische Sprache selbst wird im Titel gar nicht erwähnt.
Ein direkter Vergleich der Leistung von Code in R und wie oben beschrieben Code in µl oder einer anderen Programmiersprache an einem konkreten, lokalen Beispiel ist absolut NICHT korrekt, da TC nie wie oben beschrieben aus einer Korrelationsfunktion besteht, sondern immer eine große Menge aus Code und Funktionsaufrufen ist. Da R über einen riesigen Funktionsumfang verfügt, hat der Code in der Regel nur wenige Zeilen (1000 Zeilen sind viel), ist aber inhaltlich sehr umfangreich.
Das Programm selbst, das ein sinnvolles Problem löst, kann grob in zwei Teile unterteilt werden:
Zu Punkt 1: Wenn erhebliche Mengen an Code geschrieben werden müssen, kann das Geschwindigkeitsproblem sehr ernst sein. Es gibt drei Möglichkeiten, sie zu überwinden:
Bei Punkt 2 ist die Leistung ganz anders, und ich bezweifle, dass es ohne besondere Anstrengungen bei der üblichen Entwicklung des µl-Programms R an Leistung übertreffen kann.
Zum Beispiel.
Oberflächlich betrachtet sind die Operationen mit Vektoren und Matrizen in R sehr einfach. Ein Ausdruck der Form a <- b*c wird von der Intel-Bibliothek ausgeführt. Es gibt keine Schleifen. Sie ist für jedermann zugänglich, es sind keine zusätzlichen Kenntnisse oder Anstrengungen erforderlich. Bei der Entwicklung eines μl-Programms werden höchstwahrscheinlich Zyklen verwendet, obwohl es auch möglich ist, auf dieselbe Bibliothek zurückzugreifen (wenn das Programm nicht für den Markt bestimmt ist), aber es ist ein ziemlich hohes Maß an Wissen und Aufwand erforderlich, um dasselbe Ergebnis zu erzielen.
Aber das ist noch nicht alles.
Wenn wir uns mit rechenintensiven Algorithmen befassen, und das sind Appelle an R-Funktionen, hat sich der Entwickler selbst, konfrontiert mit dem Problem der Leistung, mit diesem Problem befasst und es in der Regel in der Entwicklungsphase gelöst. Dies wird in der Regel entweder durch das Schreiben von C-Code oder durch Rückgriff auf C- oder Fortran-Bibliotheken gelöst. Darüber hinaus haben solche Algorithmen unter ihren Parametern die Möglichkeit, die Verwendung vieler Kerne anzugeben. Ein Entwickler in R erhält all dies automatisch und ohne Aufwand. Man kann sich voll und ganz auf das Wesentliche der TK konzentrieren, nicht auf die Technik der Umsetzung. Es ist zu bezweifeln, dass der Entwickler von μl-Programmen den Entwickler von Funktionen in R übertreffen kann, und zwar aus dem trivialen Grund, dass man speziell an der Leistung, nicht aber am Wesen von TC arbeiten muss.
Aus dem Geschriebenen folgt, dass ein korrekter Leistungsvergleich darin bestehen würde, echten TC-Code auf µl und denselben Code auf µl+R (in R gibt es keine Handelsaufträge) zu schreiben und zu vergleichen. Aber in seiner ganzen Pracht - brauchen wir das?
Hat jemand versucht, mit Rekursionsdiagrammen zu arbeiten? Sie können hier darüber lesenhttps://habrahabr.ru/post/145805/, insbesondere um MOs anstelle von rohen BPs zu ersetzen? könnte als eine Option funktionieren
und mehr zu lesenhttp://geo.phys.spbu.ru/Problems_of_geophysics/2005/20_Zolotova_38_2005.pdf
Eine Idee für diejenigen, die sie umsetzen können. Die maschinelle Bildverarbeitung vergleicht diese Diagramme und sucht nach übereinstimmenden Mustern. Als Ersatz für nutzlose Korrelation
Eine Idee für diejenigen, die dies umsetzen können. Maschineller Vergleich dieser Diagramme auf der Suche nach übereinstimmenden Mustern. Als Ersatz für nutzlose Korrelationen.
Zuvor konnten einige Ideen nicht durch TC getestet werden, da die geringe Leistung einiger Algorithmen dies verhinderte. In diesem Fall ist genau das passiert - ein alternativer Algorithmus ermöglichte es dem Optimierer, eine Idee zu erforschen, die so alt ist wie die Welt, aber bisher nicht in einer angemessenen Zeit berechnet werden konnte.
Wenn man Hunderte von Milliarden von Pearson QC in Mustern von einigen tausend Längen berechnen muss, wird die geringe Geschwindigkeit einer scheinbar einfachen Aufgabe zu einem unüberwindbaren Engpass. Wenn ein Problem zu rechenintensiv erscheint, könnte man sagen, dass es sich um ein schlecht formuliertes Problem mit wenig Verständnis handelt. Vielleicht ist es das. Aber was geschehen ist, ist geschehen. Und es ist immer interessant zu sehen, wie andere ähnliche Dinge umsetzen.
Und wenn Sie es auf GPU als auch zu implementieren, werden Sie wirklich wertvoll sein ))
Ohne Ponzi kann man das häufigste Muster finden. Aber was ist der Sinn?
Nun, für eine Musterstrategie muss es natürlich nicht unbedingt die häufigste sein, es kann viele Varianten geben
Dies ist nicht unbedingt die häufigste Variante für Musterstrategien, es kann viele Varianten geben.
Das ist es, was ich nicht verstehe. Die Verwendung von Musterdaten ist nützlich bei der Komprimierung von Daten mit geringem Informationsverlust (verschiedene Medien). Aber was hat das mit der TK zu tun?
Der einfachste Weg, über dieses Thema zu sprechen, ist, das häufigste Muster als Beispiel zu verwenden. Es ist keine schwierige Aufgabe, sie zu finden.
Hier ist ein Rätsel (Muster), das am häufigsten vorkommt. Das Auswahlkriterium ist im Moment nicht so wichtig. Lassen Sie das Rätsel dort sein. Wie kann man sie für den Handel nutzen?
Zu sagen, dass, wenn eine äußerste Geschichte mit einer Zagagulina in den ersten 80 % zusammenfällt, die nächsten Preise demselben Muster folgen wie die restlichen 20 % der Zagagulina, ist Unsinn.
Das ist es, was ich nicht verstehe. Die Verwendung von Musterdaten ist nützlich, um Daten mit geringem Informationsverlust zu komprimieren (verschiedene Medien). Aber was hat das mit der TK zu tun?
Der einfachste Weg, über dieses Thema zu sprechen, ist, das häufigste Muster als Beispiel zu verwenden. Es ist keine schwierige Aufgabe, sie zu finden.
Hier ist ein Rätsel (Muster), das am häufigsten vorkommt. Das Auswahlkriterium ist im Moment nicht so wichtig. Lassen Sie das Rätsel dort sein. Wie kann man sie für den Handel nutzen?
Zu sagen, dass, wenn eine äußerste Geschichte mit einer Zagagulina in den ersten 80 % zusammenfällt, die folgenden Preise den gleichen Weg gehen wie die restlichen 20 % der Zagagulina, ist Unsinn.
Warum halten Sie das für Unsinn? wenn sich die Vorhersage aufgrund der gleichen Geschichte in einer Vielzahl von Fällen bestätigen wird