L'apprentissage automatique dans la négociation : théorie, modèles, pratique et algo-trading - page 197
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
je me demandais juste - est-ce que vous prenez seulement les valeurs de prix et les différents indicateurs des prix comme prédicteurs ici ? et est-ce que quelqu'un utilise les volumes réels et les indicateurs des volumes ?
Je travaille avec des prix, sans volume.
J'ai essayé d'utiliser les volumes et leurs indicateurs, mais cela n'a pas fonctionné. Il n'existe pas de volumes réels sur le marché des changes, mais il existe des ticks, qui semblent correspondre un peu aux volumes réels, c'est-à-dire qu'en principe vous pouvez les essayer. Mais le problème est que l'historique des barres et des ticks du courtier contient des volumes de tick"pas tels". Si le symbole se trouve sur la place du marché dans le terminal en fonctionnement - il existe un historique correct des volumes de tick pour ce symbole. Si le symbole est retiré du wotch ou si le terminal est fermé - les volumes en tick pour ces barres seront pris tels qu'indiqués par le courtier. Et ces deux valeurs, "tapé par le terminal" et "reçu du courtier" sont complètement différentes, parfois dix fois. Maintenant, je dois faire fonctionner le terminal pendant quelques mois pour obtenir les volumes réels en ticks, pas ceux que le courtier me donne, puis je peux essayer de les utiliser à nouveau.
Je travaille avec des prix, sans volume.
J'ai essayé d'utiliser les volumes et leurs indicateurs, mais cela n'a pas fonctionné. Il n'existe pas de volumes réels sur le marché des changes, mais il existe des ticks, qui semblent correspondre un peu aux volumes réels, c'est-à-dire qu'en principe vous pouvez les essayer. Mais le problème est que l'historique des barres et des ticks du courtier contient des volumes de tick"pas tels". Si le symbole se trouve sur la place du marché dans le terminal en fonctionnement - il existe un historique correct des volumes de tick pour ce symbole. Si le symbole est retiré du wotch ou si le terminal est fermé - les volumes en tick pour ces barres seront pris tels qu'indiqués par le courtier. Et ces deux valeurs, "tapé par le terminal" et "reçu du courtier" sont complètement différentes, parfois dix fois. Je dois maintenant faire fonctionner le terminal pendant quelques mois pour obtenir les volumes réels en ticks et non ceux des courtiers, puis je pourrai essayer de les utiliser à nouveau.
Pour des informations sur le langage R et le nouveau MetaTrader 5 build 1467 :
Distributions statistiques dans MQL5 - prenez le meilleur de R et rendez-le plus rapide
Un grand nombre de nouvelles fonctions mathématiques et statistiques similaires à celles de R seront ajoutées dans les prochaines versions. Cela permettra plus de calculs et de visualisation directement dans MetaTrader 5.Vous pouvez mettre à jour la version 1467 à partir du serveur MetaQuotes-Demo.
Cher Renat !
Permettez-moi de répondre au commentaire sur le point 6. Les erreurs de calcul détectées dans R dans le lien cité :Distributions statistiques dans MQL5 - prendre le meilleur de R et le rendre plus rapide
La vérification a été effectuée pour la fonction Gamma. Nous laissons la vérification du reste des fonctions à votre propre responsabilité.
Au nom du département Data Science, représenté par le manager et deux statisticiens (je peux vous informer sur PM) nous vous informons que la densité de la distribution gamma au point zéro n'est pas réduite à zéro, à proprement parler.
R estime en effet que la densité au point zéro est de 1 :
x <- seq(0, 20, 0.5) #support
plot(k, dgamma(x = x, shape = 1, scale = 1, log = FALSE)) #PDF plot
print(dgamma(x = 0.000001, shape = 1, scale = 1, log = FALSE)) #limiting to zero
Cependant, on peut voir que lorsque x tend vers zéro, la densité s'approche de l'unité.
En outre, selon :
https://en.wikipedia.org/wiki/Gamma_distribution
pour x = 0, alpha = 1, beta = 1, le numérateur donne une valeur indéterminée, ce qui fait entrer toute la fraction dans l'incertitude.
Nous affirmons qu'à proprement parler, la densité gamma de la distribution au point zéro est indéfinie. Et en prenant la limite à droite, la densité est égale à un.
A la lumière de ces éléments, nous pensons que la formulation de l'affirmation "erreurs de calcul dans R" n'est pas correcte. Plus précisément, c'est une question de convention : ce qui doit être considéré comme égal à l'expression zéro à la puissance zéro. L'égalisation de la densité de la distribution gamma à zéro au point zéro ne semble pas être une pratique conditionnelle.
Sv.
Alexey
Déclarer que, strictement parlant, la densité de la distribution gamma au point zéro est indéfinie. Et lorsque la limite de droite est prise, la densité est égale à un.
A la lumière de ces éléments, nous pensons que la formulation de l'affirmation "erreurs de calcul dans R" n'est pas correcte. Plus précisément, c'est une question de convention : que d'assimiler l'expression zéro à la puissance de zéro. Assimiler la densité de la distribution gamma à zéro au point zéro ne semble pas être une pratique conditionnelle.
Si la densité (pdf) est non nulle, alors l'intégrale (cdf) en ce point doit également être non nulle, sinon le zéro n'est pas possible.
Mais cdf=0. C'est difficile à expliquer.
A x=0, la fdp est nulle par définition :
Wolfram Alpha:
Pour les distributions chi-carré non centrales et centrales :
Si la densité (pdf) est non nulle, alors l'intégrale (cdf) en ce point doit également être non nulle, sinon il n'y a pas de zéro.
Mais cdf=0. C'est difficile à expliquer.
A x=0, pdf est nul par définition :
Wolfram Alpha:
Pour les distributions chi-carré non centrales et centrales :
Vous feriez mieux de nous dire vous-même ce qu'est 0 ^ alpha - 1, lorsque alpha = 1.
L'intégrale n'est pas non plus définie ici..... Mais à la limite, elle est proche de zéro. Question de conventions...
print(pgamma(q = 0.000001, shape = 1, scale = 1, log = FALSE, lower.tail = F)) #right side
print(pgamma(q = 0.000001, shape = 1, scale = 1, log = FALSE, lower.tail = T)) #left side
et est-ce que quelqu'un utilise des volumes réels et des indicateurs de volume ?
pour que la limite soit définie, il faut qu'elle soit la même pour les approches gauche et droite, mais ce n'est pas le cas :
http://www.wolframalpha.com/input/?i=Limit%5BPDF%5BGammaDistribution%5B1,1%5D,x%5D,+x-%3E0%5D
pour que la limite soit définie, il faut qu'elle soit la même pour les approches gauche et droite, mais ce n'est pas le cas :
http://www.wolframalpha.com/input/?i=Limit%5BPDF%5BGammaDistribution%5B1,1%5D,x%5D,+x-%3E0%5D
Il n'y en a qu'un seul à droite et c'est le 1...
Ce que Wolfram dit 0 n'est pas la vérité en dernier ressort. Je veux dire que le mot "erreur" dans le libellé est redondant...
J'ai trouvé une autre erreur dans R. R ne divise pas correctement par 0.
Voici le script :
//| test.mq5 |
//| Copyright 2016, MetaQuotes Software Corp. |
//| https://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright "Copyright 2016, MetaQuotes Software Corp."
#property link "https://www.mql5.com"
#property version "1.00"
#property script_show_inputs
input double div = 0.0;
//+------------------------------------------------------------------+
//| Script program start function |
//+------------------------------------------------------------------+
void OnStart()
{
//---
Print(1.0/div);
}
//+------------------------------------------------------------------+
La réponse correcte, en mql, est.
division par zéro dans 'test.mq5' (20,13)
avec arrêt du script
Incorrect, en R :
> 1/0
Inf
avec poursuite du script
Je veux dire la même chose qu'Alexey - le comportement des programmes dans des conditions non définies peut être différent, et ce n'est pas une erreur. C'est ainsi que l'architecture est censée être, c'est ainsi que le résultat sera.
Une autre observation intéressante. On ne peut pas diviser par zéro. Et tu ne peux pas enlever la racine d'un nombre négatif. Je me souviens qu'à l'université, tout cela était possible, mais il ne s'agit plus de cela maintenant, en mathématiques simples, on ne peut pas faire les deux.
Pourquoi si je divise par 0 dans mql alors cela casse tout le script et le casse, mais si j'extrais une racine d'un nombre négatif alors j'obtiens "-nan(ind)" sans casser le script, et ce "-nan(ind)" peut être utilisé pour faire d'autres calculs (il cassera tous les autres calculs) ? C'est là que je m'attendrais à un comportement identique du script mql dans les deux cas.