Qui veut une stratégie ? Lots et gratuitement) - page 58

Nouveau commentaire
 
1. je peux réécrire les indicateurs afin de remplacer float par double.
2. protected static float fMicron = 0.000075f ; // Coef utilisé lorsque nous comparons deux floats
3. le constructeur de la base d'indicateurs :

/// <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. Prix de base :



/// <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. J'ai réussi à faire fonctionner le pont NET <-> MT. Son mètre de temps pour faire du trading FSB par MT. Bien sûr, il sera réservé aux comptes de démonstration jusqu'à ce qu'il devienne "solide comme le roc".

 

Comme je pense que l'indicateur Aroon utilise seulement : bIsDescreteValues = true ;


A propos du RSI, je me souviens que je m'interrogeais sur la formule. C'était il y a 5-6 ans. Je pense que j'ai utilisé cette formule d'un livre populaire de TA. Je ne me souviens pas exactement lequel.

 

"Utiliser la valeur précédente de la barre"

Je pense personnellement que c'est l'une des caractéristiques les plus importantes de FSB.


        /// <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;
        }
 

Pour voir les valeurs de l'indicateur dans toute leur précision, appuyez sur F12 dans la fenêtre du graphique.


Une autre option consiste à utiliser la "Console de commande". ind xxxx montre les indicateurs de la barre xxxx.




Je ne creuse pas profondément dans les formules de MT. Ils ne sont probablement pas très différents. Voici le FSB RSI et le MT RSI par défaut.







___________________--

Edit :

J'ai essayé de calculer le RSI sans ce lissage supplémentaire :

            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]));
            }


Mais dans ce cas, la valeur RSI pour 2009.3.24 saute à 74.800.



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


Merci à Stellarator pour ses bons mots !

Je n'abandonnerai pas Forex Strategy Builder, et ce uniquement à cause de personnes comme vous. Même en face, je suis ouvert à la discussion afin de rendre FSb plus robuste et plus convivial.

Dans cette direction, je pense que je peux ajouter des indicateurs MT dans FSB. Quelque chose comme le mode de compatibilité MT:)

MT_MACD, MT_RSI, ... Ceux-ci doivent avoir les mêmes paramètres que ceux de la norme MT.


Nous devons trouver une solution aux points d' entrée et de sortie de l'ouverture et de la fermeture des barres. Ils sont essentiels pour l'intégration FSB -> MT.


 
Stellarator >> :

.........Combinez-les (deux tampons) en un seul (je pensais... Il peut y avoir non seulement 1/0 (qui pourrait être transformé en bitmask), mais aussi des étiquettes de prix). Il est probable que je doive faire quelque chose avec les valeurs des indicateurs eux-mêmes... Nous verrons bien... Comme je vais...

Pourquoi cela ne fonctionne-t-il pas ( ?).

Depuis longtemps, j'utilise un seul appel icustom pour obtenir plusieurs valeurs de différents tampons d'indicateurs, c'est trop de gaspillage d'utiliser cette fonction plusieurs fois dans le code, surtout pendant l'optimisation, et même avec des indicateurs "lourds". En fait, tout ce dont nous avons besoin (au maximum) est d'obtenir la direction du trade et le niveau de SL & TP..... le problème est résolu par une simple arithmétique.

Voici un fragment du code de l'indicateur avec un seul tampon supplémentaire (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);

Et voici la conversion inverse dans le code de l'Expert Advisor :

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;
  }

Ainsi, nous obtenons 3 valeurs de l'indicateur (direction, TP et SL) avec un seul appel de l'indicateur. Les résultats obtenus peuvent être manipulés comme vous le souhaitez :)

J'espère que vous comprenez le principe.

 

Bonjour à tous !


Miroslav_Popov писал(а) >>

1. Je peux réécrire les indicateurs afin de remplacer float par double.

Miroslav - c'est important ! J'ai déjà donné certaines des raisons dans mes posts. Mais je suis bien conscient du travail que cela implique aussi... Et que maintenant (très probablement) vous travaillez sur le pont que vous recherchez ou quelque chose de substantiel.


Mais il faut trouver le temps. Ma prédiction ne dépasse pas un certain nombre d'heures (dans la journée). Car il ne s'agit pas seulement de remplacer l'un par l'autre lors de la déclaration des variables (ce qui impliquera aussi au moins un contrôle visuel et une correction visuelle "pour la beauté" (lorsque les variables sont décrites avec des tabulations, par exemple, etc.) :) - bien que ce ne soit pas une question de principe).

Tout d'abord, il peut y avoir des cas où le flottement est utilisé à dessein (pour forcer une diminution de la précision). Vous devez voir le code entier ici.

Deuxièmement, il s'agit de comparer ces ("nouveaux") chiffres et leur mise en correspondance avec le FSB (voir ci-dessous, section 2).

Plus court - nous devrons parcourir soigneusement tout le code et au moins réfléchir aux inconvénients éventuels liés au passage des mathématiques réelles aux mathématiques doubles.


Miroslav_Popov a écrit (a) >>.

2. protected static float fMicron = 0.000075f ; // Coef utilisé lorsque nous comparons deux floats


(et ci-dessous) :

Pour voir les valeurs de l'indicateur dans toute leur précision, appuyez sur F12 dans la fenêtre du graphique.

Et c'est l'un des problèmes ! Pourquoi 0,000075 ? Et pas 0,00005 ? Ou 0,000001 ? (comme je l'ai fait).

Un problème étendu (pour ceux que cela intéresse) et une question :

Comme vous le savez, la comparaison de deux nombres réels pour l'égalité ne devrait jamais être faite par de telles constructions :

double Value1, Value2;

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

En effet, après les résultats de certains calculs (notamment les variations de multiplier/diviser), les valeurs de ces variables peuvent être visuellement similaires (1,0 et 1,0, par exemple), mais en réalité PAS les mêmes. (1,000001 et 1,000000, en fait). Cette propriété découle d'une certaine discrétisation de la représentation des nombres réels dans les ordinateurs et d'une certaine discrétisation (précision) (finie) du calcul. En général, la comparaison pour l'égalité se fait par des variations sur un thème classique (que Miroslav utilise d'ailleurs) :

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

Il s'agit de la comparaison "classique" de deux nombres réels pour l'égalité avec une certaine précision finie, définie par fMicron, dans ce cas.


Et c'est là que réside l'un des problèmes potentiels. Comment, qui et pour quels cas déterminer la valeur de ce même fMicron ? S'agit-il toujours d'une bonne constante, comme celle de Miroslav (la question de la valeur est toujours en discussion, elle aussi) ?


En général, si ce n'est pour ajouter de l'intrigue - je suis un partisan de la théorie suivante :

1. En général, il existe deux types de comparaison de ces variables, pour l'égalité et pour l'inégalité (<, >).

2. Il existe deux types de variables proprement dites: les variables à précision fixe garantie (prix, lots, etc.) et les valeurs abstraites sans précision définie (comme les valeurs indicatrices).

Pour l'inégalité, les variables (de tout type) sont comparées (en général) "tête à tête" (if (Value1 < Value2) { ...}). S'il est nécessaire de limiter la précision (ce qui est assez rare), vous pouvez utiliser une construction comme celle de Miroslav :

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

Pour l'égalité, cependant, le problème est (généralement) abordé différemment, en fonction des données en question.

4.1 Si nous devons comparer deux nombres avec une précision fixe (par exemple, deux valeurs de prix pour décider de modifier ou non l'ordre (pour éviter d'obtenir un "Pas de résultat")), nous procédons généralement de cette manière (également "classique") :

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

La fonction est redondante dans notre cas, mais là n'est pas la question. La construction clé est Point / 2.0. C'est ce fMicron qui nous donne la précision de calcul requise, correcte et suffisante... DANS CE CAS PRÉCIS! Lorsque deux prix sont comparés (avec les mêmes chiffres et, par conséquent, le même point ), c'est-à-dire dans le cas de (Point = 0.0001), par exemple

fMicron = 0,00005

et en comparant 1.2345 (prix de l'ordre) avec 1.23451 (valeur de l'indicateur) - nous obtenons une égalité, et 1.2345 avec 1.23456 - une inégalité... Devinez ce qui se passe dans le dernier cas lorsque fMicron = 0.000075 ? ;) Vous pourriez, bien sûr, prénormaliser les variables à une précision (inférieure). Mais ce n'est pas notre méthode :D...

Encore une fois - le choix de ce paramètre est important, et pour chaque cas "un peu unique" :)1


Je suggère le paradigme suivant:

1. Les variables à précision fixe sont comparées à une valeur fMicron calculée (Point / 2, par exemple pour le cas du prix)

2. Les valeurs des indicateurs et autres trucs similaires "infiniment précis" :), sont comparées à la constante fMicron égale à la valeur minimale du point, des instruments utilisés, divisée par 10. C'est-à-dire que dans le cas d'instruments où les chiffres ne dépassent pas 4 - fMicron = 0,00001, si les chiffres = 5, fMicron = 0,000001 et ainsi de suite.

Miroslav - avis d'expert requis :) ?!


Maintenant une question pour le public :

WHY dans toutes sortes de DataWindow (dans MT ou dans FSB (Indicator Charts)) - les valeurs de l'indicateur sont toujours affichées avec une précision fixe (chiffres = 4) ? Et pourquoi pas 3 décimales ? Ou 5, 6, 7, ... ? :) ?! Non, vraiment ?

Miroslav avait une "caractéristique cachée" ;)) - Je veux dire F12! Et dans MT, sur quoi appuyer ?

Et en général, eh bien, qui a défini cette constante ? (4 décimales).

Je pense qu'elle est presque directement liée à la dimension des cotations entrantes (1,2345), pour la plupart des instruments (quelqu'un vient de la remplir). Mais ce n'est pas un secret que de nombreuses sociétés de courtage passent à des valeurs plus grandes (5 par exemple). Pourquoi ne pas afficher les valeurs de l'indicateur dans la dimension qui coïncide avec la dimension des cotations de l'instrument (chiffres) ?

Ou peut-être que je ne "comprends" pas quelque chose en principe dans le sujet (s'il vous plaît - que quelqu'un m'explique, peut-être que c'est "nécessaire" parce que...) !


Miroslav_Popov a écrit (a) >>.

3. le constructeur de la base d'indicateurs :

4. Prix de base :

Miroslav, j'ai très bien compris le code de la page Source :). Je comprends bien ce que fait la fonction protected static float[] Price( BasePrice price). Si cela est un indice de la lourdeur de mon code - je réponds que j'ai intentionnellement refusé d'utiliser des tampons supplémentaires pour le stockage (dans le cas général - soit des copies des tampons de prix, soit des copies calculées de ceux-ci (Typique, etc.)). Et on gagne de la place, et là où il y a toutes sortes de typiques, il faut TOUJOURS les calculer !


Il convient ici de mentionner la différence essentielle dans l'approche du calcul des valeurs de l'indicateur dans le FSB et le MT :

1. Tout d'abord, du moins pour le moment, les cotations qui sont chargées dans FSB sont statiques, il les a une fois chargées, a calculé UNE fois les valeurs d'indicateur requises pour toute la gamme de barres et ensuite juste "conduit" par eux, émulant le comportement du robot de trading. Une fois encore, les valeurs des indicateurs ne sont calculées qu' une seule fois, AVANT d'exécuter la virtualisation du robot de trading. Cela explique notamment la rapidité de l'émulation des transactions commerciales. Mais les cotations dans MT arrivent tout le temps et le testeur de stratégie natif ne voit pas l'avenir, c'est-à-dire que nous devons calculer les valeurs de l'indicateur à chaque fois. Et si j'utilise simplement l'approche de Miroslav (calcul du tampon entier)... On me jettera des œufs pourris :). Par conséquent, une attention particulière est accordée à l'utilisation de IndicatorCounted() ! Les indicateurs sont calculés à la vitesse maximale possible dans chaque cas (si toutes les barres doivent être comptées, ou seulement une). Quelque part, certaines choses peuvent encore être optimisées, mais à votre guise...

2. Par conséquent, à chaque fois (lorsqu'un nouveau tick arrive), il est redondant de générer des valeurs de prix dans des tampons supplémentaires. Vous devez de toute façon les calculer tous, alors laissez les fonctions (la même MovingAverage, etc.) le faire elles-mêmes. Cela permet d'économiser de l'espace, de simplifier la logique (il n'est pas nécessaire d'analyser à chaque fois quelles barres recalculer dans ces tampons), de gagner en rapidité (même un peu plus, dans le cas général). "C'est ce qu'il me semble" (c) Winnie l'ourson


Si nous devons discuter à nouveau de mes conversions d'indicateurs, l'important est peut-être que je préserve complètement la logique des fonctions (et des indicateurs eux-mêmes), mais que je la modifie légèrement pour un cas d'utilisation spécifique dans MT. J'enregistre également l'ordre et les noms des paramètres pour contrôler l'indicateur lui-même.

Les gars, regardez le code source, cependant. J'ai essayé de faire "bien" :).


L'idée finale de ma conversion est la suivante. Par exemple, nous avons un point d'ouverture de la position et trois indicateurs pour une logique supplémentaire. Voici à quoi ressemblera le code pour le passage des commandes (en gros, bien sûr) :

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)
}

Quelque chose comme ça. Vous alimentez iCustom avec les valeurs de vos paramètres et attendez qu'ils donnent tous un signal. C'est tout. Il n'y a pas d'analyse des valeurs des indicateurs eux-mêmes... Pour quoi faire ?

Ça a l'air sympa... ou pas :) ?

 

A propos des indicateurs :

Environ (Aroon et bIsDescreteValues = true ;) pris en compte.


À propos de RSI...

Miroslav - la construction que vous recherchez vous a dérouté :). Ne soyez pas paresseux, mettez une fois de plus des commentaires autour et utilisez l'indicateur CORRECTEMENT TRAVAILLÉ pour obtenir des valeurs "correspondantes" :). Je vous rappelle que la formule classique de calcul du RSI est basée sur la variété exponentielle de la MA (lissée, plus précisément). Il faut donc spécifier ce mode de lissage (lissé) dans les paramètres de l'indicateur... et vous serez "agréablement surpris" par les résultats :) (par défaut, je vous le rappelle, Simple est utilisé, ce qui donne une divergence par rapport au classique) ! Je ne peux pas faire la procédure ci-dessus moi-même - mais je suis sûr à 100% de ce que je dis. Convainquez-moi :) ?

À la suite des tests, nous avons la suggestion suivante : supprimer le code requis et donner une valeur par défaut au paramètre maMethod dans Smoothed pour tous les indicateurs qui utilisent le RSI (et le RSI lui-même, respectivement). Que par défaut, les utilisateurs n'auraient pas de telles questions. Mais en faisant cela, nous rendrons la sélection de ce paramètre dans les indicateurs TRAVAILLABLES ! (par exemple, j'ai converti l'oscillateur RSI MA, qui, basé sur le résultat des calculs RSI, également, avec le comportement actuel du RSI lui-même - peu importe ce qui est spécifié dans le paramètre approprié)

 
Miroslav_Popov >> :

"Utiliser la valeur précédente de la barre"

Je pense personnellement que c'est l'une des caractéristiques les plus importantes de FSB.

OH, OUI !

C'est vraiment l'une des caractéristiques les plus importantes du FSB. Et j'ai essayé d'accorder une attention particulière à la vérification de l'exactitude de la logique des indicateurs, compte tenu de cette fonctionnalité.

Merci pour le code montrant le calcul de la valeur "par défaut" ! Je le prendrai en compte...

 
rider >> :

Pourquoi ça ne peut pas marcher ( ?).

Depuis longtemps, j'utilise un seul appel à icustom pour obtenir plusieurs valeurs de différents tampons d'indicateurs, c'est trop de gaspillage d'utiliser cette fonction plusieurs fois dans le code, surtout pendant l'optimisation, et même avec des indices "lourds". En fait, tout ce dont nous avons besoin (au maximum) est d'obtenir une direction de trading et des niveaux SL & TP..... le problème est résolu par une simple arithmétique.

...

Le principe, je l'espère, est clair.




Je connais le problème du regroupement des valeurs en un seul paramètre :), vous y arriverez (j'ai intentionnellement rendu ma déclaration plus grossière). Et merci pour le code cité (petite question - y a-t-il déjà eu des différences entre les valeurs originales et les valeurs "élargies par la suite" ? tout le même double...)

La question clé est... EST-IL NÉCESSAIRE DANS CE CAS PARTICULIER.

Il peut y avoir deux raisons :

1. 1... Le but de l'utilisation d'un tampon supplémentaire (c'est important pour moi) - les indicateurs n'en ont pas tant que ça. J'en ai assez MAIS POUR l'instant (il semble que je doive déjà utiliser Ishimoku - et tout deviendra clair :)))

2. La vitesse d'appel de l'indicateur depuis son code (votre exemple). Ma réponse est : Pas essentiel ! Je le déclare en toute responsabilité. Motivation :

À chaque nouveau tic-tac - vous devrez de toute façon (devoir) examiner l'indicateur. N'est-ce pas ? (par exemple - pour prendre des prix ou autre chose) Même si ce n'est pas à chaque tic, mais quand vous en avez besoin. L'indice principal, peut-être, est qu'un appel multiple de iCustom dans une itération de l'EA conduit à un recalcul multiple de l'indicateur ? Je suis obligé de vous dissuader ! Le point clé est "une limite d'une itération du conseiller expert". Ainsi, à l'intérieur de cette fourchette, l'indicateur est calculé UNE fois (à son premier appel) ! Je le déclare avec une confiance absolue. Tous les appels ultérieurs ne le lancent pas du tout, mais prennent seulement les valeurs nécessaires dans les tampons nécessaires. La condition est de 100% si les paramètres d'entrée restent inchangés (sauf pour le tampon et le décalage). La règle est valable pour les calculs dans les limites d'un seul outil. Mais je pense que le principe est valable même lorsque iCustom fait référence à d'autres TF et outils.


Quoi qu'il en soit, je vais jeter un coup d'oeil à l'Ishimoku ce soir et décider si je vais utiliser deux tampons pour la logique... ou un :)

 

Quoi qu'il en soit, je vous vois tous ce soir (je suis allé travailler).

A propos du problème. 

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

Je vais y réfléchir.


Mais le plus probable (étant donné l'absence de signaux de MT sur ce sujet) - le code ci-dessus (modèle sur la page précédente) est plus ou moins optimal (peut nécessiter un petit réglage... J'essaierai d'"approfondir" le problème dans la soirée).

1...51525354555657585960616263646566
Nouveau commentaire