Fehler, Irrtümer, Fragen - Seite 673
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
Renat, zero - vielen Dank für Ihre Aufmerksamkeit für das Thema und Ihre konstruktive Antwort!
Nächste.
1. über x64
Renat:
Die korrektere Option ist ein Upgrade auf x64.
...
Natürlich, wenn jemand Hunderte von Indikatoren in den Modus der Markt-Scanning, ohne ihre Entladen aufrufen, sollten sie direkt auf die 64-Bit-Version gehen + installieren zusätzlichen Speicher.
Es ist seltsam, dass ich im Moment umfangreiche Tests auf x32 durchführe. Jeder anständige x64-Computer mit 16 GB Arbeitsspeicher (ohne fanatisch über Grafikkarten und Monitore) kann für 15.000 Rubel gekauft werden.
Der Umstieg auf x64 ist auf jeden Fall der richtige Weg. Aber. Das eine schließt das andere nicht aus. Selbst meine 16 Gigabyte (die ich habe) möchte ich nicht für unnötige Daten verschwenden. Ich habe noch andere Dinge parallel zu bearbeiten - MSVS, Matlab usw., mit denen ich ebenfalls umfangreiche Aufgaben berechnen möchte. Ich freue mich, dass Sie das verstehen und bereit sind, nach Möglichkeiten zu suchen, Geld zu sparen.
2. über einen festen Beginn der Geschichte:
Renat:
Wir selbst wollen den Ressourcenverbrauch reduzieren. Vielleicht könnte die Lösung eine Funktion IndicatorMaxDepth(uint len) sein, die nur auf in diesem EA erstellte Indikatoren wirkt.
Das Problem ist jedoch, dass während der Prüfung die Puffer der Indikatoren im Akkumulationsmodus zusammen mit der Historie wachsen und keine Speicherung erfolgt.
Ich stimme (fast) voll und ganz zu. Haftungsausschluss: In vielen Fällen wird die Optimierung nur an einem kleinen Teil der letzten Geschichte vorgenommen. In diesem Fall können die Einsparungen ganz erheblich sein. Dennoch halte ich die Option für relativ funktionsfähig - vor allem, wenn Sie eine gute Arbeit oder Schätzungen über die Umsetzung haben. Für mich, zum Beispiel, die Option scheint nicht ganz vollwertig - eine Menge Arbeit, und das Ergebnis ist nicht radikal. Eine halbe Lösung.
3. Hier ist das Yaz! :
Renat:
DieHistorie des Indikators in rltime zu trimmen, während die eingestellte Tiefe beibehalten wird , ist mit schönen Pannen behaftet und wird die Programmierer, die die Synchronität der Balken des Diagramms und des Indikatorpuffers berechnen/gewohnt haben,direkt umhauen.
Nein! Wenn sich die Balken des Diagramms auf die gleiche Weise verhalten, also synchron, ist das nicht problematisch. Mit anderen Worten: Wenn die Ringpuffer (auch wenn sie unterschiedlich groß sind) immer (zwangsweise) Verwendung des AsSeries-Flags - es werden keine massiven Probleme für den Benutzer erwartet.
// In diesem Fall wäre es sinnvoll, dem Benutzer alle Verlaufspuffer als Indikator (d.h. kreisförmig, mit AsSeries=true) zu präsentieren.
In dieser Variante:
(1) Es gibt eine interne Darstellung von Indikator- und Preis-Arrays (auf Ihrer Seite): Indizierung von links nach rechts (AsSeries==false), die Größen betreffen den Benutzer nicht, und in der Tat"Eintrag ist verboten".
Und (2) es gibt eine Benutzerseite - alle Puffer sind kreisförmig (in der Implementierung sieht der Benutzer ein virtuelles lineares Array), die Indexierung erfolgt von rechts nach links (AsSeries==true) und die Größe wird vom Benutzer festgelegt.
Welches ist das Dach des Benutzers hier? Keines. Wenn außerhalb des Bereichs - Standardreaktion Array außerhalb des Bereichs.
Nur Sie haben Schwierigkeiten (keine kleinen, um ehrlich zu sein). Aber! In Anbetracht der Universalität des Systems - Sie müssen sich nur einmal anstrengen. Und alle "netten Pannen" im Keim zu ersticken, beim Beta-Debugging. Danach - allgemeines Glück und sehr wirtschaftliche Konstruktion.
Wir werden eine Überarbeitung des Indikator-Caches durchführen, der nun das Prinzip der maximalen Effizienz gegen das Prinzip der Speichereinsparung einsetzt. Indikatoren, die abgelehnt wurden, werden sofort entladen, anstatt sie wie bisher für einige Zeit im Speicher zu halten. Dadurch wird es möglich, Hunderte von Indikatoren hintereinander mit einem direkten Entladen über IndicatorRelease aufzurufen.
3. hier kommt der Jazel! :
Nein! Das ist nicht der Fall, wenn sich die Diagrammbalken auf die gleiche Weise verhalten - nämlich synchron. Mit anderen Worten: Wenn Ringpuffer (auch wenn sie unterschiedlich groß sind) immer (zwangsweise) Verwendung des AsSeries-Flags - massive Probleme sind für den Benutzer nicht zu erwarten.
// In diesem Fall wäre es zweckmäßig, alle dem Benutzer zur Verfügung gestellten historischen Puffer indikativ (d. h. zirkulär, mit AsSeries=true) zu gestalten.
In dieser Variante:
(1) Es gibt eine interne Darstellung von Indikator- und Preis-Arrays (auf Ihrer Seite): Indizierung von links nach rechts (AsSeries==false), die Größen betreffen den Benutzer nicht, und in der Tat"Eintrag ist verboten".
Und (2) es gibt eine Benutzerseite - alle Puffer sind kreisförmig (in der Implementierung sieht der Benutzer ein virtuelles lineares Array), die Indexierung erfolgt von rechts nach links (AsSeries==true) und die Größe wird vom Benutzer festgelegt.
Welches ist das Dach des Benutzers hier? Keines. Wenn der Benutzer die Reichweite verlässt - Standardreaktion Array außerhalb der Reichweite.
Nur Sie haben Schwierigkeiten (keine kleinen, um ehrlich zu sein). Aber! In Anbetracht der Universalität des Systems - Sie müssen sich nur einmal anstrengen. Und alle "netten Pannen" müssen während der Beta-Testphase im Keim erstickt werden, damit alle zufrieden sind und die Konstruktion sehr wirtschaftlich ist .
Gute Idee, ich bin voll dafür. Aber es hebt die Umsetzung des Ringschemas nicht auf, sondern ergänzt es nur auf angenehme Weise.Lassen Sie mich die Testbedingungen beschreiben:
Infolge der automatischen Unterschreitung des Indikators haben wir
Ich werde die Bedingungen des Tests beschreiben:
Als Ergebnis der automatischen Unterschreitung des Indikators haben wir:
1.
Ja, es ist erträglich. Es wird kaum zu Massenunzufriedenheit führen, im Gegenteil, die Wirtschaft wird sehr attraktiv sein. Niemand verbietet, den Speicher durch die Installation einer riesigen MaxBar zu verschwenden.
// Aber die Indikatoren stören durch das Überspringen von Balken! Das ist der Punkt, an dem die Unzufriedenheit berechtigt ist!
// Sie tolerieren also sogar das... :) Nun, wir müssen... :(
2.
Nein, nein und nein! Das Kreislaufsystem ist genau das, was zu enormen Einsparungen beim Kopieren von Geschichtsschichten führt. Bei einer Verschiebung um einen Balken (N Balken) müssen wir genau einen Wert (N Werte) kopieren. Die(Benutzer-)Kosten der Indexvirtualisierung sind vernachlässigbar. Sie sind sogar in Stresstests nur schwer zu erkennen(der Rest der Division wird vom Prozessor in einem Taktzyklus berechnet + die Verschiebung des virtuellen Pufferanfangs bei jeder Verschiebung durch die Geschichte dauert ein paar weitere Taktzyklen). Es gibt also fast keine Geschwindigkeitseinbußen. Es ist unmöglich, diese Verlangsamung zu erkennen, so gering ist sie. Und vor dem Hintergrund der enormen Speichereinsparung stehen diese Verluste in keinem Verhältnis zum Gewinn.
3.
Ehhh, ein Gesicht...
Aus irgendeinem Grund wird so viel getanzt und geschrien, dass die Indikatoren an den unbegrenzten Balken ersticken, aber kein Wort über tanzende grafische Objekte. Versuchen Sie, zum Beispiel, super große Andrews' Pitchfork auf Unlimited (auf MN1, zum Beispiel) zu bauen, dann begrenzen Sie die Anzahl der Bars in den Terminal-Einstellungen, gehen Sie auf niedrige Timeframes und spulen Sie zu den Ankerpunkten zurück. Einige von ihnen werden sich in einem enormen zeitlichen Abstand zu den Extrema befinden (dies ist der Fall, während die Mistgabeln aller drei Punkte ausschließlich im Bereich der realen M1-Balken liegen, ohne über die Grenze der gefälschten Balken aus höheren Zeitrahmen hinauszugehen!) Und warum ist das so? Offensichtlich, weil wir nicht genügend historische Daten über M1 hatten, um den genauen M1-Wert einiger autobindender Punkte zu berechnen. Aber was haben historische Daten damit zu tun? Nun, vielleicht waren sie ausreichend, aber die im Schaufenster ausgestellten Barren waren es nicht, daher die Verschiebungen. Das heißt, dass einige Punkte "nicht wirklich wissen, wo sie sind".
Ich wünschte, jemand würde das selbst überprüfen, oder vielleicht bin ich der Einzige, der so ein Chaos hat...
Ich habe eine Merkwürdigkeit festgestellt!
Wenn Sie zum Zeitpunkt der Bildung eines neuen Balkens die Open- und Close-Werte früherer Balken (z. B. 10 frühere Balken) ablesen und sie dann 5 Sekunden später erneut abrufen, dann sind einige dieser Werte unterschiedlich, und wenn Sie sie während der Bildung eines neuen Balkens abrufen, dann ist alles in Ordnung, aber in den ersten paar Sekunden sind diese Werte aus irgendeinem Grund unterschiedlich.
Ich hoffe, ich habe das deutlich erklärt.
Können Sie mir sagen, ob vor dem Lesen der Werte von Open- und Close-Balken zu Beginn eines neuen Balkens eine Verzögerung von mehr als 5 Sekunden auftreten sollte?
Hier ist ein Beispiel für einen Betrieb:
Oben wird nach einer Verzögerung korrekt ausgelöst, unten kurz nach einem neuen Balken mit einem Fehler, und rechts der Benchmark für die 6te Zeile.
Vielleicht ist das Problem unsynchronisiert, ein neuer Balken sollte vorzugsweise von allen verwendeten Tools verfolgt werden.
Ja, Sie haben Recht behalten, danke!
Ähnliches gilt für die Oper.