Wer will eine Strategie? Lose und kostenlos) - Seite 58

Neuer Kommentar
 
1. ich kann die Indikatoren so umschreiben, dass float durch double ersetzt wird.
2. protected static float fMicron = 0.000075f; // Koeffizient für den Vergleich zweier Floats
3. der Indikator Base Constructor:

/// <summary>
/// The default constructor
/// </summary>
public Indicator()
{
    sIndicatorName  = string. Empty;
    bSeparatedChart = false;
    bIsDescreteValues = false;
    afSpecValue     = new float[] { };
    fMinValue       = float. MaxValue;
    fMaxValue       = float. MinValue;
    bIsCalculated   = false;
    parameters      = new IndicatorParam();
    component       = new IndicatorComp[] { };
}




4. der Grundpreis:



/// <summary>
/// Calculates the base price.
/// </summary>
/// <param name="price">The base price type.</param>
/// <returns>Base price.</returns>
protected static float[] Price( BasePrice price)
{
    float[] afPrice = new float[Bars];

    switch( price)
    {
        case BasePrice.Open:
            afPrice = Open;
            break;
        case BasePrice.High:
            afPrice = High;
            break;
        case BasePrice.Low:
            afPrice = Low;
            break;
        case BasePrice.Close:
            afPrice = Close;
            break;
        case BasePrice. Median:
            for (int iBar = 0; iBar < Bars; iBar++)
                afPrice[ iBar] = (Low[ iBar] + High[ iBar]) / 2;
            break;
        case BasePrice. Typical:
            for (int iBar = 0; iBar < Bars; iBar++)
                afPrice[ iBar] = (Low[ iBar] + High[ iBar] + Close[ iBar]) / 3;
            break;
        case BasePrice. Weighted:
            for (int iBar = 0; iBar < Bars; iBar++)
                afPrice[ iBar] = (Low[ iBar] + High[ iBar] + 2 * Close[ iBar]) / 4;
            break;
        default:
            break;
    }
    return afPrice;
}

6. Ich habe eine funktionierende NET <-> MT Brücke. Seine metter der Zeit zu machen FSB Handel durch MT. Natürlich wird es nur für Demo-Konten sein, bis es "felsenfest" ist.

 

Ich glaube, der Aroon-Indikator verwendet nur: bIsDescreteValues = true;


Was den RSI betrifft, so erinnere ich mich, dass ich mich über die Formel gewundert habe. Das war vor 5-6 Jahren. Ich glaube, ich habe diese Formel aus einem bekannten TA-Buch verwendet. Ich weiß nicht mehr genau, welche.

 

"Vorherigen Balkenwert verwenden"

Ich persönlich bin der Meinung, dass dies eines der wichtigsten Merkmale der FSB ist.


        /// <summary>
        /// Sets the "Use previous bar value" checkbox
        /// </summary>
        /// <returns>Is any Changes</returns>
        public bool SetUsePrevBarValueCheckBox(int iSlot)
        {
            bool isChanged = false;

            for (int iParam = 0; iParam < Slot[ iSlot]. IndParam. CheckParam. Length; iParam++)
            {
                if ( Slot[ iSlot]. IndParam. CheckParam[ iParam]. Caption == "Use previous bar value")
                {
                    bool bOrigChecked = Slot[ iSlot]. IndParam. CheckParam[ iParam]. Checked;
                    bool bChecked = true;

                    // Entry slot
                    if ( Slot[ iSlot]. SlotType == SlotTypes.Open)
                    {
                        bChecked = true;
                    }

                    // Open filter slot
                    else if ( Slot[ iSlot]. SlotType == SlotTypes. OpenFilter)
                    {
                        bChecked = EntryExecutionTime != TimeExecution. Closing;
                    }

                    // Close slot
                    else if ( Slot[ iSlot]. SlotType == SlotTypes.Close)
                    {
                        bChecked = true;
                    }

                    // Close filter slot
                    else if ( Slot[ iSlot]. SlotType == SlotTypes. CloseFilter)
                    {
                        bChecked = false;
                    }

                    if ( bChecked)
                    {
                        for (int iPar = 0; iPar < Slot[ iSlot]. IndParam. ListParam. Length; iPar++)
                        {
                            if ( Slot[ iSlot]. IndParam. ListParam[ iPar]. Caption == "Base price" &&
                                Slot[ iSlot]. IndParam. ListParam[ iPar]. Text    == "Open")
                            {
                                bChecked = false;
                            }
                        }
                    }

                    if ( bChecked != bOrigChecked)
                    {
                        isChanged = true;
                        Slot[ iSlot]. IndParam. CheckParam[ iParam]. Checked = bChecked;
                    }
                }
            }

            return isChanged;
        }
 

Um die Indikatorwerte in ihrer vollen Genauigkeit zu sehen, drücken Sie F12 im Chartfenster.


Eine weitere Möglichkeit ist die Verwendung der "Befehlskonsole". ind xxxx zeigt die Indikatoren für Takt xxxx




Ich beschäftige mich nicht intensiv mit MT-Formeln. Wahrscheinlich unterscheiden sie sich nicht allzu sehr. Hier sind die Standardwerte für den FSB RSI und den MT RSI.







___________________--

Bearbeiten:

Ich habe versucht, den RSI ohne diese zusätzliche Glättung zu berechnen:

            for (int iBar = 1; iBar < Bars; iBar++)
            {
                if ( afBasePrice[ iBar] > afBasePrice[ iBar - 1]) afPos[ iBar] = afBasePrice[ iBar] - afBasePrice[ iBar - 1];
                if ( afBasePrice[ iBar] < afBasePrice[ iBar - 1]) afNeg[ iBar] = afBasePrice[ iBar - 1] - afBasePrice[ iBar];
            }

            float[] afPosMA = MovingAverage( iPeriod, 0, maMethod, afPos);
            float[] afNegMA = MovingAverage( iPeriod, 0, maMethod, afNeg);

            //for (int iBar = iFirstBar; iBar < Bars; iBar++)
            //{
            //    afPosMA[iBar] = (afPosMA[iBar - 1] * (iPeriod - 1) + afPos[iBar]) / iPeriod;
            //    afNegMA[iBar] = (afNegMA[iBar - 1] * (iPeriod - 1) + afNeg[iBar]) / iPeriod;
            //}

            for (int iBar = iFirstBar; iBar < Bars; iBar++)
            {
                if ( afNegMA[ iBar] == 0)
                    afRSI[ iBar] = 100;
                else
                    afRSI[ iBar] = 100 - (100 / (1 + afPosMA[ iBar] / afNegMA[ iBar]));
            }


Aber in diesem Fall springt der RSI-Wert für 2009.3.24 auf 74.800.



----------------------


Danke, Stellarator, für die guten Worte!

Ich werde den Forex Strategy Builder nicht aufgeben, und das nur wegen Leuten wie Ihnen. Auch im Gegenteil bin ich offen für Diskussionen, um FSb robuster und benutzerfreundlicher zu machen.

In dieser Richtung denke ich, dass ich MT-Indikatoren in FSB hinzufügen kann. So etwas wie der MT-Kompatibilitätsmodus:)

MT_MACD, MT_RSI, ... Diese müssen die gleichen Parameter haben wie die MT-Standardparameter.


Wir müssen eine Lösung für die Eintritts- und Austrittspunkte bei Bar-Eröffnung und Bar-Schluss finden. Sie sind für die Integration von FSB -> MT unerlässlich.


 
Stellarator >> :

.........Kombinieren Sie sie (zwei Puffer) zu einem (ich dachte an... Es kann nicht nur 1/0 (das in eine Bitmaske umgewandelt werden könnte), sondern auch Preisschilder geben.) Wahrscheinlich werde ich etwas mit den Indikatorwerten selbst machen müssen... Wir werden sehen... Wenn ich gehe...

Warum kann es nicht funktionieren(?).

Seit langem verwende ich einen einzigen icustom-Aufruf, um mehrere Werte aus verschiedenen Indikatorpuffern zu holen. Es ist zu verschwenderisch, diese Funktion mehrmals im Code zu verwenden, besonders während der Optimierung und sogar bei "schweren" Indikatoren. In der Tat ist alles, was wir brauchen (höchstens), um die Handelsrichtung und das Niveau der SL & TP zu erhalten..... das Problem ist durch einfache Arithmetik gelöst.

Hier ist ein Fragment des Indikatorcodes mit nur einem zusätzlichen Puffer (Signal):

// в самом кончике start такой фрагмент

      
   if ( Direction[0] !=0)
      {
      if ( Direction[0] > 0) Signal[0]= Set_TP[0]/Point*1000000 + Set_SL[0]/Point;
      if ( Direction[0] < 0) Signal[0]=-( Set_TP[0]/Point*1000000 + Set_SL[0]/Point);
      }
   return(0);

Und hier ist die umgekehrte Umwandlung im Code des Expert Advisors:

int start()
  {
   // Получение значений из буфера индикатора в последней фазе формирования бара
   if (TimeCurrent() > (Time[0]+ CP60)
      {
      Signal=iCustom(NULL, 0, "_iK_tay_v01M1", Discret,6,0)
      }     

   if(Time[0] != prevtime)
      { 
      Calcul();
      //if (Tral !=0) CalcLevel();
      prevtime = Time[0];
      }
   else return;

.........

void Calcul()
  {
   OpenSell=0; OpenBuy=0; CloseBuy=0; CloseSell=0;
   
   if( Signal > 0) 
      {
      OpenBuy=1; CloseSell=1;
      TP=NormalizeDouble ( Signal*Point/1000000, Digits-1);      
      SL=( Signal- TP/Point*1000000)*Point;   
      }
   if( Signal < 0) 
      {
      CloseBuy=1; OpenSell=1;
      TP=NormalizeDouble (MathAbs( Signal)*Point/1000000, Digits-1);      
      SL=(MathAbs( Signal)- TP/Point*1000000)*Point;   
      }   
   return;
  }

So erhalten wir 3 Werte des Indikators (Richtung, TP und SL) mit einem einzigen Aufruf des Indikators. Die erzielten Ergebnisse können nach Belieben weiterbearbeitet werden :)

Ich hoffe, Sie verstehen das Prinzip.

 

Guten Morgen zusammen!


Miroslav_Popov писал(а) >>

1. Ich kann die Indikatoren so umschreiben, dass float durch double ersetzt wird.

Miroslav - das ist wichtig! Einige der Gründe habe ich bereits in meinen Beiträgen genannt. Aber ich bin mir auch über den Arbeitsaufwand im Klaren... Und dass Sie jetzt (höchstwahrscheinlich) an der Brücke arbeiten, die Sie suchen, oder an etwas Wesentlichem.


Aber die Zeit muss gefunden werden. Meine Vorhersage ist nicht mehr als eine gewisse Anzahl von Stunden (innerhalb eines Tages). Denn es geht nicht nur darum, bei der Deklaration von Variablen das eine durch das andere zu ersetzen (was zumindest eine visuelle Kontrolle und eine visuelle Korrektur "der Schönheit halber" nach sich zieht, wenn Variablen z. B. mit Tabulatoren beschrieben werden usw.) :) - obwohl es sich nicht um eine grundsätzliche Frage handelt).

Zunächst einmal kann es durchaus Fälle geben, in denen absichtlich eine Pufferfunktion verwendet wird (um eine Verringerung der Genauigkeit zu erzwingen). Sie müssen den gesamten Code hier sehen.

Zweitens stellt sich die Frage des Vergleichs solcher ("neuen") Zahlen und ihrer Zuordnung zu FSB (dazu weiter unten in Abschnitt 2).

Kürzer - wir müssen den gesamten Code sorgfältig durchgehen und zumindest über mögliche Nachteile nachdenken, die mit dem Übergang von der realen zur doppelten Mathematik verbunden sind.


Miroslav_Popov schrieb (a) >>.

2. protected static float fMicron = 0.000075f; // Koeffizient für den Vergleich zweier Floats


(und unten):

Um die Indikatorwerte in ihrer vollen Genauigkeit zu sehen, drücken Sie F12 im Chartfenster.

Und genau das ist eines der Probleme! Warum 0,000075? Und nicht 0,00005? Oder 0,000001? (wie ich es getan habe).

Ein erweitertes Problem (für die, die es interessiert) und eine Frage:

Wie Sie wissen, sollte der Vergleich zweier reeller Zahlen auf Gleichheit niemals mit solchen Konstruktionen durchgeführt werden:

double Value1, Value2;

if (Value1 == Value2) {
  // Some useful code there
}

Der Grund dafür ist, dass nach den Ergebnissen einiger Berechnungen (insbesondere bei Variationen von Multiplizieren/Dividieren) die Werte dieser Variablen zwar visuell ähnlich sein können (z. B. 1,0 und 1,0), aber tatsächlich NICHT gleich sind. (1,000001 und 1,000000, in der Tat). Diese Eigenschaft ergibt sich aus einer gewissen Diskretion der Darstellung von reellen Zahlen in Computern und einer gewissen (endlichen) Diskretion (Genauigkeit) der Berechnung. Im Allgemeinen erfolgt der Vergleich der Gleichheit durch Variationen eines klassischen Themas (das Miroslav übrigens verwendet):

if (Math.Abs(afIndValue[iCurrBar] - afIndValue[iBaseBar]) < fMicron) {
  // Some code there
}

Dies ist der "klassische" Vergleich zweier reeller Zahlen auf Gleichheit mit einer endlichen Genauigkeit, in diesem Fall definiert durch fMicron.


Und hier liegt eines der möglichen Probleme. Wie, wer und für welche Fälle sollte der Wert dieses fMicron bestimmt werden? Ist sie immer eine gute Konstante, wie die von Miroslav (die Frage nach dem Wert wird ebenfalls noch diskutiert)?


Im Allgemeinen bin ich für die folgende Theorie, auch wenn sie nicht besonders interessant ist:

1. Im Allgemeinen gibt es zwei Arten des Vergleichs solcher Variablen, für Gleichheit und für Ungleichheit (<, >).

2. Es gibt zwei Arten von Variablen: Variablen mit garantierter fester Genauigkeit (Preise, Partien usw.) und abstrakte Werte ohne bestimmte Genauigkeit (wie Indikatorwerte).

Bei Ungleichheit werden Variablen (beliebigen Typs) (im Allgemeinen) "Kopf an Kopf" verglichen (if (Wert1 < Wert2) { ...}). Wenn es notwendig ist, die Genauigkeit einzuschränken (was eher selten der Fall ist), können Sie eine Konstruktion wie die von Miroslav verwenden:

if (afIndValue[iBaseBar] < afIndValue[iCurrBar] - fMicron) {
  // Some code there
}

4) Für die Gleichheit wird das Problem jedoch je nach den betreffenden Daten (normalerweise) unterschiedlich angegangen.

4.1 Wenn wir zwei Zahlen mit fester Genauigkeit vergleichen müssen (z.B. zwei Preiswerte, um zu entscheiden, ob die Bestellung geändert werden soll oder nicht (um ein "Kein Ergebnis" zu vermeiden)), dann machen wir das normalerweise so (auch "klassisch"):

int ComparePriceInt(double Value1, double Value2) {
   Value1 -= Value2;
   Value2 = Point / 2.0;
   if ( Value1 > Value2)
      return(1);
   if ( Value1 < - Value2)
      return(-1);
   return(0);
}

Die Funktion ist in unserem Fall überflüssig, aber das ist nicht der Punkt. Das Schlüsselkonstrukt darin ist Point / 2.0. Es ist dieses fMicron, das uns die erforderliche, korrekte und ausreichende Rechengenauigkeit gibt... IN DIESEM SPEZIELLEN FALL! Wenn zwei Preise verglichen werden (mit denselben Ziffern und folglich demselben Punkt ), d. h. im Fall von (Punkt = 0,0001), zum Beispiel

fMicron = 0,00005

und den Vergleich von 1,2345 (Auftragspreis) mit 1,23451 (Indikatorwert) - wir erhalten Gleichheit, und 1,2345 mit 1,23456 - Ungleichheit... Raten Sie mal, was im letzten Fall passiert, wenn fMicron = 0,000075? ;) Sie könnten natürlich die Variablen auf eine (niedrigere) Genauigkeit vornormormieren. Aber das ist nicht unsere Methode :D...

Noch einmal - die Wahl dieses Parameters ist wichtig, und für jeden Fall "ein bisschen einzigartig" :)1


Ich würde das folgende Paradigma vorschlagen:

1. Variablen mit fester Genauigkeit werden mit einem berechneten fMicron-Wert verglichen (Punkt / 2, z. B. für den Preisfall)

2. Die Werte von Indikatoren und anderen ähnlichen "unendlich genauen Kleinigkeiten" :) werden mit der fMicron-Konstante verglichen, die dem Mindestwert von Point, den verwendeten Instrumenten, geteilt durch 10, entspricht. D.h. bei Geräten, bei denen Digits 4 nicht überschreitet, ist fMicron = 0,00001, bei Digits = 5 ist fMicron = 0,000001 und so weiter.

Miroslav - Expertenmeinung erforderlich :)?!


Nun eine Frage an die Öffentlichkeit:

WIE in allen Arten von DataWindow (in MT oder in FSB (Indikator-Charts)) - Indikatorwerte immer mit einer festen Genauigkeit (Digits = 4) angezeigt werden? Warum nicht 3 Dezimalstellen? Oder 5, 6, 7, ...? :)?! Nein, wirklich?

Miroslav hatte eine "verborgene Eigenschaft? ;)) - Ich meine F12! Und was soll man bei MT drücken?

Und ganz allgemein: Wer hat diese Konstante definiert? (4 Dezimalstellen).

Ich vermute, dass sie bei den meisten Instrumenten fast direkt mit der Dimension der eingehenden Notierungen (1,2345) zusammenhängt (jemand hat sie gerade eingegeben). Aber es ist kein Geheimnis, dass viele Maklerfirmen zu größeren Werten übergehen (z. B. 5). Warum also nicht die Indikatorwerte in der Dimensionalität anzeigen, die mit der Dimension der Instrumentennotierungen (Ziffern) übereinstimmt?

Oder vielleicht "verstehe" ich prinzipiell etwas an dem Thema nicht (bitte - kann mir das jemand erklären, vielleicht ist es "notwendig", weil...)!


Miroslav_Popov schrieb (a) >>.

3. der Indikator Base Constructor:

4. der Grundpreis:

Miroslav, ich habe den Code auf der Source-Seite sehr gut verstanden :). Ich verstehe gut, was protected static float[] Price( BasePrice price) tut. Wenn dies ein Hinweis auf die Schwerfälligkeit meines Codes ist - ich antworte, dass ich mich absichtlich geweigert habe, zusätzliche Puffer für die Speicherung zu verwenden (im allgemeinen Fall - entweder Kopien von Preispuffern oder berechnete Kopien von ihnen (typisch, etc.)). Und es wird Platz gespart, und wo es alle möglichen Typicals gibt, müssen sie IMMER berechnet werden!


Hier müssen wir den entscheidenden Unterschied in der Berechnung der Indikatorwerte in FSB und MT erwähnen:

1. Erstens, zumindest im Moment - Kurse, die in FSB geladen werden, sind statisch, es hat sie einmal geladen, berechnet EINMAL die erforderlichen Indikatorwerte für den gesamten Bereich von Bars und dann nur "fährt" durch sie, emuliert das Verhalten des Handelsroboters. Noch einmal: Die Indikatorwerte werden nur einmal berechnet, und zwar BEVOR die Virtualisierung des Handelsroboters ausgeführt wird. Dies erklärt vor allem die Geschwindigkeit der Emulation von Handelsgeschäften. Aber die Notierungen im MT kommen ständig und der native Strategietester sieht nicht in die Zukunft, d.h. wir müssen die Indikatorwerte jedes Mal neu berechnen. Und wenn ich nur den Ansatz von Miroslav verwende (Berechnung des gesamten Puffers)... Ich werde mit faulen Eiern beworfen werden :). Daher ist bei der Verwendung von IndicatorCounted() besondere Vorsicht geboten! Die Indikatoren werden jeweils mit fast maximaler Geschwindigkeit berechnet (ob alle Balken gezählt werden müssen oder nur einer). Irgendwo können einige Dinge noch optimiert werden, aber in aller Ruhe...

2. Daher ist es überflüssig, jedes Mal (wenn ein neuer Tick kommt) Kurswerte in zusätzlichen Puffern zu erzeugen. Sie müssen sie ohnehin alle berechnen, also lassen Sie die Funktionen (den gleichen MovingAverage usw.) dies selbst tun. Das spart Platz, vereinfacht die Logik (es muss nicht jedes Mal analysiert werden, welche Balken in diesen Puffern neu berechnet werden sollen) und spart Geschwindigkeit (im Allgemeinen sogar etwas mehr). "Für mich sieht es so aus" (c) Winnie the Pooh


Wenn wir noch einmal über meine Umwandlung von Indikatoren diskutieren, ist es vielleicht wichtig, dass ich die Logik der Funktionen (und der Indikatoren selbst) vollständig beibehalte, sie aber für einen bestimmten Anwendungsfall in MT leicht modifiziere. Ich speichere auch die Reihenfolge und die Namen der Parameter für die Steuerung des Indikators selbst.

Leute, schaut euch doch mal den Quellcode an. Ich habe versucht, "nett" zu sein :).


Die endgültige Idee meiner Umstellung ist die folgende. Wir haben zum Beispiel einen Eröffnungspunkt der Position und drei Indikatoren für zusätzliche Logik. Der Code für die Auftragserteilung wird folgendermaßen aussehen (natürlich nur grob):

if ( IsSignal(iCustom(NULL, 0, "fsbIndicator1", SLOT_TYPE_LC, Param2, Param3, ..., 0, 0))
    && IsSignal(iCustom(NULL, 0, "fsbIndicator2", SLOT_TYPE_LC, Param2, Param3, ..., 0, 0))
    && IsSignal(iCustom(NULL, 0, "fsbIndicator3", SLOT_TYPE_LC, Param2, Param3, ..., 0, 0)) )
{    
// Открываем длинную позицию (предпоследний 0 в значениях индикаторов - указатель на буфер логики длинных позиций (1, соотв. - на буфер логики коротких))
    // Если у нас значение POP берется из еще одного индикатора, то это значение берется аналогично, только меняется логика поведения индикатора:
    // iCustom(NULL, 0, "fsbIndicator", SLOT_TYPE_POP, Param2, Param3, ..., 0, 0)
}

Etwa so. Sie füttern iCustom mit Ihren Parameterwerten und warten, bis sie alle ein Signal geben. Das ist alles. Es gibt keine Analyse der Indikatorwerte selbst... Und wozu?

Sieht nett aus... oder nicht :)?

 

Über die Indikatoren:

Über (Aroon und bIsDescreteValues = true;) berücksichtigt werden.


Über RSI...

Miroslav - die Konstruktion, die Sie suchen, hat Sie verwirrt :). Seien Sie nicht zu faul, noch einmal Kommentare einzufügen und den Indikator CORRECTLY WORKED zu verwenden, um "passende" Werte zu erhalten :). Ich möchte Sie daran erinnern, dass die klassische Formel zur Berechnung des RSI auf der exponentiellen Variante des MA (speziell geglättet) basiert. Geben Sie also diesen Glättungsmodus (geglättet) in den Indikatorparametern an... und Sie werden von den Ergebnissen "angenehm überrascht" sein :) (standardmäßig wird Simple verwendet, was zu einer Diskrepanz mit den Klassikern führt)! Ich kann das oben beschriebene Verfahren nicht selbst durchführen - aber ich bin mir zu 100 % sicher, was ich sage. Überzeugen Sie mich :)?

Als Ergebnis der Tests haben wir den folgenden Vorschlag, den erforderlichen Code zu entfernen und den Parameter maMethod in allen Indikatoren, die RSI (bzw. RSI selbst) verwenden, auf den Standardwert von Smoothed zu setzen. Dass die Nutzer standardmäßig keine solchen Fragen haben. Aber dadurch machen wir die Auswahl dieses Parameters in den Indikatoren ARBEITSFÄHIG! (zum Beispiel habe ich RSI MA Oscillator, die, basierend auf dem Ergebnis der RSI-Berechnungen, auch mit dem aktuellen Verhalten des RSI selbst konvertiert - es spielt keine Rolle, was in den entsprechenden Parameter angegeben ist)

 
Miroslav_Popov >> :

"Vorherigen Balkenwert verwenden"

Ich persönlich bin der Meinung, dass dies eines der wichtigsten Merkmale der FSB ist.

OH, JA!

Das ist wirklich eines der wichtigsten Merkmale der FSB. Und ich habe versucht, die Korrektheit der Indikatorlogik in Anbetracht dieser Funktion sorgfältig zu prüfen.

Vielen Dank für den Code, der die Berechnung des "Standardwerts" zeigt! Ich werde es in Betracht ziehen...

 
rider >> :

Warum es nicht funktionieren kann(?).

Seit langem verwende ich einen einzigen icustom-Aufruf, um mehrere Werte aus verschiedenen Indikatorpuffern abzurufen. Es ist zu verschwenderisch, diese Funktion mehrmals im Code zu verwenden, insbesondere während der Optimierung und selbst bei "schweren" Indizes. In der Tat ist alles, was wir brauchen (höchstens), um eine Handelsrichtung und SL & TP..... Ebenen das Problem durch einfache Arithmetik gelöst ist.

...

Das Prinzip ist, so hoffe ich, klar.




:), Sie werden es verstehen (ich habe meine Aussage absichtlich vergröbert), ich weiß um das Problem mit dem Zusammenfassen von Werten in einen Parameter :). Und danke für den zitierten Code (kurze Frage - gab es jemals Unterschiede zwischen den ursprünglichen Werten und den "nachträglich erweiterten"?)

Die entscheidende Frage ist... IST ES IN DIESEM SPEZIELLEN FALL NOTWENDIG.

Dafür kann es zwei Gründe geben:

1. 1... Der Zweck der zusätzlichen Puffer Nutzung (es ist wichtig für mich) - Indikatoren haben nicht so viele von ihnen. Ich habe genug davon, ABER FÜR den Moment (es sieht so aus, als müsste ich Ishimoku schon benutzen - und alles wird klar :)))

2. Die Geschwindigkeit des Aufrufs des Indikators aus seinem Code (Ihr Beispiel). Meine Antwort lautet: Nicht unbedingt! Ich erkläre dies mit aller Verantwortung. Motivation:

Bei jedem neuen Tick müssen Sie ohnehin in den Indikator schauen (müssen). Oder? (z. B. um Preise zu nehmen oder etwas anderes). Auch wenn nicht bei jeder Zecke, aber wenn Sie es brauchen. Der Haupthinweis ist vielleicht, dass ein mehrfacher Aufruf von iCustom innerhalb einer Iteration des EA zu einer mehrfachen Neuberechnung des Indikators führt? Ich bin gezwungen, Ihnen davon abzuraten! Der entscheidende Punkt ist "eine Begrenzung auf eine Iteration des Expert Advisors". Innerhalb dieses Bereichs wird der Indikator also nur EINMAL (beim ersten Aufruf) berechnet! Ich erkläre dies mit 100%igem Vertrauen. Alle nachfolgenden Aufrufe starten() es überhaupt nicht, sondern entnehmen nur die notwendigen Werte aus den notwendigen Puffern. Die Bedingung ist 100%, wenn die Eingabeparameter unverändert bleiben (außer Puffer und Offset). Die Regel gilt für Berechnungen innerhalb der Grenzen eines Werkzeugs. Aber ich denke, das Prinzip gilt auch dann, wenn sich iCustom auf andere TFs und Tools bezieht.


Wie auch immer, ich werde mir den Ishimoku heute Abend ansehen und dann entscheiden, ob ich zwei Puffer für die Logik verwenden werde... oder eine :)

 

Wie auch immer, ich sehe euch alle heute Abend (bin zur Arbeit gegangen).

Über das Problem. 

We have to find solution to Bar Opening and Bar closing entry/exit points. They are vital for FSB -> MT integration.

Ich werde darüber nachdenken.


Aber höchstwahrscheinlich (angesichts des Mangels an Signalen von MT zu diesem Thema) - der obige Code (Vorlage auf der vorherigen Seite) ist mehr oder weniger optimal (kann ein wenig Feinabstimmung benötigen... Ich werde versuchen, das Problem am Abend zu "vertiefen")

1...51525354555657585960616263646566
Neuer Kommentar
Grund der Beschwerde: