Skript oder Strategie liefert nach dem Aktualisieren der Seite andere Ergebnisse (Repainting)

Historische Daten enthalten keine Aufzeichnungen über Preisbewegungen innerhalb der Kerzen; nur Open, High, Low und Close (OHLC). Dies führt dazu, dass ein Skript manchmal anders auf historischen Daten und in Echtzeit arbeitet, wo nur der Open-Preis bekannt ist und wo sich der Preis typischerweise viele Male bewegt, bevor die endgültigen High-, Low- und Close-Werte der Echtzeit-Kerze nach deren Schluss feststehen.

Wenn wir ein Skript in einen Chart einfügen, warten, bis es auf eine Anzahl von Echtzeit-Kerzen errechnet wird und dann die Seite neu laden, werden wir manchmal sehen dass sich die Plots eines Skripts leicht ändern. Dieses Verhalten ist eine der wenigen verschiedenen Arten von Verhalten, die gemeinhin als Indikator-Repainting bezeichnet werden. Es ist die Art des Repaintings, mit der wir uns hier beschäftigen und auf die wir uns beziehen werden, wenn wir das Wort Repainting verwenden. Es ist darauf zurückzuführen, dass bestimmte Funktionen in Skripten, wenn sie in Skripten verwendet werden, auf historischen und Echtzeit-Balken unterschiedlich berechnet werden.

Andere Verhaltensweisen, die zu Recht oder fälschlicherweise als Repainting bezeichnet werden, umfassen das Plotten mit einem negativen Offset auf vergangene Kerzen und die Verwendung ansonsten nicht verfügbarer zukünftiger Informationen, die durch falsch verstandene Aufrufe der Security empfangen werden, die Daten welche nicht in Echtzeit verfügbar sind, in Skriptberechnungen einbringen können.

Nicht alle Indikatoren unterliegen der Art des Repainting, die wir hier diskutieren. In den meisten Fällen hängt es davon ab, ob bestimmte Funktionen oder Sprachkonstrukte im Code verwendet werden oder nicht. Bitte beachten Sie, dass dieses Repainting kein Fehler ist; es ist das Ergebnis der inhärenten Unterschiede zwischen historischen Kerzen und Echtzeit-Kerzeninformationen bei TradingView.

In den folgenden Fällen tritt Repainting auf:

1. Strategien mit calc_on_every_tick=true. Eine Strategie mit dem Parameter calc_on_every_tick = false kann ebenfalls zum Repainten neigen, allerdings in geringerem Maße.

2. Verwendung von security für die Abfrage von Daten mit einer höheren Auflösung als die Auflösung des Hauptsymbols des Charts:

// Add this study on 1 minute chart//@version=4study("My Script")c = security(syminfo.tickerid, "5", close)plot(close)plot(c, color=color.red)

HTML

Diese Studie wird sich auf Echtzeit- und historischen Daten unterschiedlich berechnen, unabhängig vom Wert des Look-Ahead-Parameters (siehe lookahead verstehen).

3. Verwendung von Security, um Daten mit einer geringeren Auflösung als die Auflösung des Hauptsymbols des Charts anzufordern (weitere Informationen hier).

4. Alle Skripte, die in Abhängigkeit von einem Startpunkt ausgehen. Intraday-Daten werden je nach Zeiteinheit auf den Wochen-, Monats- oder Jahresanfang ausgerichtet. Dadurch können die Ergebnisse solcher Skripte von Zeit zu Zeit abweichen. Dies sind Fälle, in denen sich Skripte auf einen Startpunkt stützen:

wenn sie valuewhen, barssince oder ema verwenden (aufgrund von Eigenheiten in ihrem Algorithmus)
Jede Backtesting Strategie (unabhängig wie der calc_on_every_tick Parameter definiert ist)

Es besteht eine Abhängigkeit zwischen der Auflösung und der Ausrichtung eines Startpunktes:

1–14 Minuten — Richtet sich nach dem Wochenanfang
15–29 Minuten — Richtet sich nach dem Monatsanfang
30 Minutes und höher — Richtet sich nach dem Jahresanfang

Folgende Einschränkungen der Historischen Daten werden bei der Verarbeitung berücksichtigt:

40.000 Altbalken für Ultimate-Abonnements
30.000 Altbalken für Elite-Abonnements
25.000 Altbalken für Expert-Abonnements
20.000 Altbalken für Premium-Abonnements
10.000 Altbalken für Pro und Pro+ Abonnements
5.000 Altbalken für andere Abonnements

5. Veränderungen in den Historischen Daten, z.B. durch einen Split.

6. Das Vorhandensein der folgenden Variablen im Skript führt in der Regel zu Repainting: