Mein Ansatz. Der Kern ist der Motor. - Seite 38
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
Sieh an, sieh an... Nur zu, Peter.
Sie haben Recht, was die "Verschlechterung" betrifft, aber ich denke, Sie sind anmaßend, was die "Anwerbung von Nutzern" betrifft.
Aber, nur zu. Es mag jemanden geben, der programmieren kann, aber er handelt "hands off".
Ich denke, es gibt eine berühmte amerikanische Plattform für den manuellen Handel. Es besteht die Möglichkeit, Aktionen innerhalb der Plattform teilweise zu automatisieren, aber man muss wissen, wie man das macht. Es gibt auch eine API. Aber wie viele werden es schaffen?
Wir können handliche Halbautomaten schreiben und sie den Kunden anbieten. Und nicht nur sie. Allen Händlern, die manuell handeln, können wir eine teilweise Automatisierung von Aktionen anbieten, den Markt von Tabellen aus beobachten und mit dem Programm über Dialogfenster interagieren. Anzeige von Meldungen über Marktereignisse. Nun, vielleicht weiß oder verstehe ich etwas nicht, aber theoretisch?
Wir hingegen können handliche Halbautomaten schreiben und sie den Kunden anbieten. Und nicht nur sie. Wir können allen Händlern, die manuell handeln, eine teilweise Automatisierung ihrer Aktionen anbieten, den Markt von Tabellen aus beobachten und mit dem Programm durch Dialogfenster interagieren. Anzeige von Meldungen über Marktereignisse. Nun, vielleicht weiß oder verstehe ich etwas nicht, aber theoretisch?
Es gibt nur einen Weg, das herauszufinden.
Veröffentlichen Sie doch wenigstens etwas.
Lassen Sie es weniger als ideal und ohne Plüschkas (wenn nötig, später hinzufügen), und sofort sehen, die Nachfrage + Feedback von Nutzern gehen wird und es wird klarer sein, in welche Richtung als nächstes zu graben.
Je früher Sie es tun, desto mehr Zeit sparen Sie (oder besser gesagt, desto weniger Zeit verlieren Sie... :(
Für solche Ratschläge hätte ich zu meiner Zeit viel gegeben :)
Sieh an, sieh an... Nur zu, Peter.
Sie haben Recht, was die "Verschlechterung" betrifft, aber ich denke, Sie sind anmaßend, wenn Sie von der "Abwanderung der Nutzer" sprechen.
Aber, nur zu. Vielleicht gibt es jemanden, der programmieren kann, aber der "hands on" handelt.
Das ist nicht möglich. Diejenigen, die wissen, wie man programmiert, werden sicherlich einen Assistenten in MQL5 machen und nur 1-2 Wochen damit verbringen, MQL5 Handelsoperationen zu studieren.
Was den halbautomatischen Roboter betrifft, werde ich in ein paar Stunden ein Video machen und Ihnen zeigen, wie ein moderner automatisierter Roboter aussieht, der im halbautomatischen Modus als Expert Advisor arbeiten kann.
Und dafür muss man keine komplizierten Tafeln neu erfinden, sondern es ganz einfach machen, damit es für alle klarer ist.
Die Nutzer von heute sind durch den Gral des Testens degradiert. Sie müssen zu ein wenig Komplexität und Verantwortung für ihr Handeln angehalten werden. Andernfalls kommt es zu einer vollständigen Degradierung des Algotradings.
Ich sehe keine andere Zukunft für die Nische des Algotrading. Ehrlich gesagt, ich sehe nicht...
So viel Pathos... Ich sehe die erhobenen Hände der Trauer ;)))
Sie, Petya, lieben die Rolle des Messias.
Alle sind degradiert... was ist nur mit der Welt los... Ihr Auftrag, Ihr Schicksal ist es, eine degenerierte Menschheit in eine strahlende Zukunft des Algotradings zu führen. Hier gibt es bereits eine Diagnose. Aus dem Stehgreif...
Petya, stellen Sie sich nicht dumm.
Es gibt etwas an mql oop, das ich persönlich nicht mag. Jedes "leere" Objekt benötigt 16 Bytes. Außerdem benötigt der Zeiger 8 Bytes, also insgesamt 24 Bytes für ein Objekt, ohne die Daten mitzuzählen. Wenn Sie stattdessen eine Eigenschaftsmatrix verwenden, können Sie ein "leeres" Objekt durch 6 Ints ersetzen, von denen jedes fast alles außer Zeichenketten speichern kann (für Zeit oder Preis reicht in 99 % der Fälle ein Int)
Und dynamic_cast Typ Konvertierung Betrieb ist nicht billig in Bezug auf die Geschwindigkeit. Die Methode des Themenstarters (ich habe sie natürlich nicht gesehen, aber theoretisch) könnte also schneller arbeiten und weniger Speicherplatz benötigen als analog mit OOP.
Ilya Malev:
Die Methode von topikstarter (ich habe sie natürlich nicht gesehen, aber theoretisch) kann also schneller arbeiten und weniger Speicherplatz benötigen als OOP-Analoga.
Das kann es nicht, denn der "Kern" des Themenstarters ist ein Array von Zeichenketten immenser Größe, und über die Effizienz eines solchen Ansatzes zu sprechen ist unrealistisch, selbst theoretisch.
Und die dynamic_cast-Typkonvertierung ist nicht gerade schnell. Die Methode des Themenstarters (ich habe sie natürlich nicht gesehen, aber in der Theorie) kann also schneller arbeiten und weniger Speicherplatz belegen als ihr OOP-Analogon.
Es wird also niemand behaupten, dass der direkte Zugriff auf ein riesiges globales Array schneller ist als all diese Schnittstellenkonstruktionen und Typkonvertierungen. Wir können auch an Design Patterns denken, z.B. Visitor mit Double Dispatch - da gibt es eine ganze Menge Overhead.
All dies wird jedoch durch die Bequemlichkeit der Unterstützung und Änderung kompensiert. Leider ist die maximale Übertragung jeglicher Denkanstrengung auf den Computer schon seit langem Mainstream in der Programmierentwicklung. Das geht so weit, dass die Summe einer arithmetischen Progression mit Hilfe einer Schleife berechnet wird, anstatt die bekannte Summenformel zu verwenden. In diesem Sinne stimme ich mit Peter überein, dass die Menschen "entwürdigend" sind.
Aber leider hat man keine Wahl - entweder man "degradiert" mit allen anderen und versucht, nicht so schnell zu sein, oder man ist hoffnungslos im Rückstand. Und die Tatsache, dass Ihr Programm unwirksam ist, ist von geringer Bedeutung.
Hier sehe ich sogar eine Analogie zum Wettbewerb in der Biologie, im Verhältnis zwischen Raubtier und Beute: Der Hase, der vor dem Wolf davonläuft, konkurriert in Wirklichkeit gar nicht mit dem Wolf, sondern mit anderen Hasen. Er muss nicht so schnell wie möglich von dem Wolf wegkommen. Viel wichtiger ist es, dass er nicht als letzter vor dem Wolf wegläuft. Denn wenn er der Letzte ist, der wegläuft, wird er gefressen, aber wenn er schneller wegläuft als alle anderen, verbraucht er mehr Energie als nötig, und die kann für nützlichere Dinge verwendet werden.
So ist es mit allen Arten von Programmiertechnologien... Die effizienteste Art, in Assembler zu programmieren, aber sie erfordert so viel Aufwand, dass sie keinen Sinn macht - die Energie ist besser für produktivere Zwecke eingesetzt, auch wenn der Code dabei nicht so effizient ist. Peters Array mit globalem Zugriff ist von der gleichen Art. Der Zugriff darauf ist effizient, aber sich zu merken, was wo liegt und wie man worauf zugreift, ist zu mühsam.
Das kann es nicht, denn der "Kern" beim Themenstarter ist eine Reihe von Strings von immenser Größe, und es ist unrealistisch, auch nur theoretisch, über die Wirksamkeit eines solchen Ansatzes zu sprechen.
Handelt es sich wirklich um eine Reihe von Zeichenketten oder ist das nur eine Redewendung? Wenn die Daten durch mql (String)-Strings dargestellt werden, gibt es wirklich keine Chance...
Der Zugriff darauf ist effizient, aber sich zu merken, was wo liegt und wie man darauf zugreift, ist zu aufwendig.
Wenn der "Kern" fertig ist, können Sie mit relativ geringem Aufwand eine bequeme Schnittstelle einrichten, die alle Probleme der "unbeholfenen" Darstellung und des Zugangs zu Informationen löst. Obwohl dies ein müßiges Gerede ist, wie ich es verstehe, hat TC seine Codes nicht veröffentlicht und wer weiß, ob sie überhaupt in der Natur sind :) Oder hat er sie veröffentlicht? Ehrlich gesagt, habe ich es nicht geschafft, alle 38 Seiten zu lesen.
Außerdem ist eine Methode, die sich ausschließlich auf "Halbautomaten" beschränkt, per definitionem wertlos. Obwohl sie dazu beitragen kann, eine lokale, begrenzte Nische auf dem Markt für Produkte und Freiberufler zu besetzen