L'Apprentissage Automatique dans le trading : théorie, modèles, pratique et trading algo - page 199
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
Commentez ensuite, dans l'ordre du littéralisme, comment pour une distribution continue uniforme la densité au point extrême est positive et l'intégrale est nulle : https://en.wikipedia.org/wiki/Uniform_distribution_(continu)
Revenons à la déclaration initiale concernant les erreurs R dans l'article.
Notre avis reste le même : il y a des erreurs et elles sont dues à une négligence dans la mise en œuvre.
Le fait est que @Quantum est une implémentation pure et une vérification complète de l'analogue de la bibliothèque mathématique R dans MQL5.
Ce n'est pas le raisonnement d'un théoricien. Et il s'applique à écrire des tests unitaires qui garantissent que la bibliothèque est correcte.
Il ne faut pas supposer a priori que tout est correct dans R. Au contraire, je dirais que même s'il existe une implémentation C++ des fonctions, tout est assez primitif. Et en termes de vitesse, vous pouvez voir que la bibliothèque MQL5 dans le code source sur notre compilateur gagne par 3 fois en moyenne.
Nous avons pris la peine de tout revérifier et avons trouvé des erreurs évidentes. Ces erreurs ont été confirmées :
Regardez les dates des publications, s'il vous plaît. Vous verrez comment le travail se déroule avec les conseils des scientifiques.
D'ailleurs, ce serait une erreur de ne pas considérer @Quantum comme un scientifique.
Cher Renat !
J'ai les questions suivantes concernant vos derniers messages, qui sont pour moi des questions de principe :
1. A en juger par la date de publication de votre article, il s'agit de l'année 2003. Naturellement, R, comme tout autre système logiciel, comporte des erreurs et une liste de correctifs est toujours publiée lors de sa sortie. En même temps, R a toujours souligné que le faible niveau de bogues dû au nombre extrêmement élevé d'utilisateurs est une vertu de R. Et ici, depuis 2003, un bug dans l'algorithme a été détecté au niveau de la publication et il n'a pas été corrigé. Ce n'est pas clair pour moi.
Avez-vous fait une demande à R sur cette question ?
2. j'aimerais voir le code par lequel les performances de R et MQL5 ont été comparées.
Je vous en remercie d'avance.
Cher Renat !
J'ai les questions suivantes concernant vos derniers posts, qui sont fondamentaux pour moi :
1. A en juger par la date de publication de l'article, il s'agit de 2003. Naturellement, R, comme tout autre système logiciel, comporte des erreurs et une liste de correctifs est toujours publiée lors de sa sortie. En même temps, R a toujours souligné que le faible niveau de bogues dû au nombre extrêmement élevé d'utilisateurs est une vertu de R. Et ici, depuis 2003, un bug dans l'algorithme a été détecté au niveau de la publication et il n'a pas été corrigé. Ce n'est pas clair pour moi.
C'est élémentaire et absolument clair.
Tout le monde fait des erreurs - c'est ce que font les développeurs. Nous faisons une tonne d'erreurs et nous ne nous décourageons pas.
Cette erreur dans R provient simplement d'une négligence et d'une confiance dans une fonction de base qui a perturbé les autres. Il sera corrigé.
Avez-vous fait une demande à R sur cette question ?
Nous avons effectué des tests, examiné tout en détail lors de l'écriture de la bibliothèque, comparé constamment MQL5 - Wolfram Alpha - R, montré nos résultats et sommes prêts à en répondre publiquement. Bien sûr, nous avons joint trois gros scripts avec des tests unitaires et un benchmark à notre paquetage mathématique (qui se trouve dans le code source).
Je suis sûr que @Quantum écrira un rapport de bug dans R. L'article mis à jour a été publié il y a quelques heures seulement.
J'aimerais voir le code comparant les performances de R et de MQL5.
Le code du benchmark pour MQL5 se trouve dans \Scripts\UnitTests\Stat\TestStatBenchmark.mq5 et le code R se trouve à la fin de l'article Distributions statistiques dans MQL5 - prendre le meilleur de R et le rendre plus rapide, voir "Annexe. Résultats du calcul de la ligne de temps des fonctions statistiques".
Assurez-vous de mettre à niveau vers MetaTrader 5 build 1467 en vous connectant au serveur MetaQuotes-Demo, s'il vous plaît. C'est dans cette version bêta que nous avons inclus la nouvelle bibliothèque et tous les scripts de test.
C'est élémentaire et tout à fait compréhensible.
Tout le monde fait des erreurs - c'est la nature des développeurs. Nous faisons une tonne d'erreurs et nous ne nous décourageons pas.
Cette erreur dans R est juste due à la négligence et à la confiance dans une fonction de base qui a fait foirer les autres. Il sera corrigé.
Nous avons effectué des tests, examiné tout en détail lors de l'écriture de la bibliothèque, comparé constamment les résultats entre MQL5 - Wolfram Alpha - R, montré nos résultats et sommes prêts à en répondre publiquement. Bien sûr, nous avons joint trois gros scripts avec des tests unitaires et un benchmark à notre paquet mathématique (qui se trouve dans le code source).
Je suis sûr que @Quantum écrira un rapport de bug dans R. L'article mis à jour a été publié il y a quelques heures seulement.
Le code du benchmark dans MQL5 se trouve dans \Scripts\UnitTests\Stat\TestStatBenchmark.mq5 et le code dans R se trouve à la fin de l'article Distributions statistiques dans MQL5 - prendre le meilleur de R et le rendre plus rapide dans "Appendix". Résultats du calcul du temps pour les fonctions statistiques".
Assurez-vous de mettre à niveau vers MetaTrader 5 build 1467 en vous connectant au serveur MetaQuotes-Demo, s'il vous plaît. C'est dans cette version bêta que nous avons inclus la nouvelle bibliothèque et tous les scripts de test.
Je ne peux pas encore me faire une opinion sur la comparaison des performances. Et c'est une question de principe.
Le fait est que R est un environnement idéal pour le développement - un interprète en un mot. Mais le code qui existe pendant le développement est très différent du code de travail - par le nombre de lignes plusieurs fois. Le code de travail, quant à lui, est très bref et très volumineux. Par conséquent, nous devrions comparer sur toutes les fonctions des paquets, qui ont un sens lors de la prise de décisions commerciales, par exemple, randomforest, qui utilisent des algorithmes de calcul capacitifs, des opérations de matrice, le chargement de tous les cœurs.....
PS.
Vous utilisez une version obsolète de R. Vous devez prendre la version R 3.3.1 (2016-06-21) du site MRAN - Microsofn R Open. Il est obligatoire d'installer MKL lors de cette opération. Microsoft a affirmé dans la version de R mentionnée qu'il était capable d'augmenter la vitesse d'exécution de certains paquets et fonctions jusqu'à 50 ( !) fois.
Je ne peux pas encore me faire une opinion sur la comparaison des performances. Et c'est une question de principe.
Le fait est que R est un environnement idéal pour le développement - un interprète en un mot. Mais le code qui existe pendant le développement est très différent du code de travail - par le nombre de lignes plusieurs fois. Le code de travail, quant à lui, est très bref et très volumineux. C'est pourquoi nous devrions comparer toutes les fonctions des paquets, qui ont un sens lors de la prise de décisions de trading, par exemple, randomforest, qui utilise des algorithmes de grande capacité de calcul, des opérations matricielles, le chargement de tous les cœurs.....
Nous traduisons méthodiquement les fonctionnalités de R en MQL5. Et de telle manière que l'essence des appels de fonction s'avère très similaire.
Voici un exemple de la correspondance de l'article :
Uniforme
Nous essayons de faire en sorte que le code provenant de R soit presque identique en taille et en temps à celui écrit dans MQL5.
Demain, nous publierons la bibliothèque graphique en version bêta et ferons la démonstration de morceaux de code de taille égale en R et MQL5, accompagnés d'images.
Je doute que la version standard de R puisse soudainement accélérer - le code ne change pas beaucoup. Il est clair que certaines fonctions peuvent être accélérées, notamment les fonctions matricielles. Et votre déclaration confirme mon opinion selon laquelle le code de R est plutôt mal écrit en termes de performances.
Si vous lisez l'article, vous verrez que nous avons obtenu des accélérations allant jusqu'à 46x, même pour les fonctions de base, sans multithreading ni MKL :
Les calculs ont été effectués sur un processeur Intel Core i7-4790, 3,6 Ghz, 16 Go de RAM, Windows 10 x64. Résultats du temps de calcul en microsecondes
Temps de calcul du PDF (µs)
Temps de calcul du PDF (µs)
R/MQL5
Temps de calcul du CDF (µs)
Temps de calcul du CDF (µs)
R/MQL5
temps de quantile (µs)
temps de calcul du quantile (µs)
R/MQL5
temps de génération des nombres aléatoires (µs)
temps de génération des nombres aléatoires (μs)
R/MQL5
Mais la version spécifiée sera testée bien sûr. Tant pour la vitesse que pour les performances.
Vous avez tort au sujet de la "mauvaise réponse"
...
Par exemple, la documentation MQL donne un exemple sur l'arcsine et indique que arcsine(2) = infini. Ce n'est pas exact. Exactement : arcsinus(2) = NaN, c'est-à-dire aucune valeur numérique, arcsinus(1) = Inf, mais les cotations manquantes pendant le trading = NA, c'est-à-dire qu'elles devraient être (ou pourraient être pendant le week-end) et ne le sont pas.
Je l'ai écrit avec un peu d'ironie sur les mauvaises réponses. J'aurais dû ajouter un smiley... En fait, j'ai ajouté à la fin que ce n'est pas un bug dans les deux cas, car le comportement du compilateur et de l'interpréteur dans les zones de fonctions non définies dépend entièrement de l'architecture du système et des développeurs. Dans ce cas, il est préférable de rendre nan, bien sûr.
Je veux dire, n'appelez pas une fonction avec des paramètres pour lesquels elle n'est pas définie et comparez ensuite les résultats avec une autre bibliothèque, sinon vous pouvez trouver des centaines de "bugs".
Au fait, c'est un exemple intéressant avec arcsinus.
mql -
MathArcsin(1) = MathArcsin(2) = -nan(ind)
Wolfram -
Arcsin(1) = Pi/2
Arcsin(2) = quelque chose de complexe. Il n'y a pas de solution avec un résultat valable.
R -
asin(1) = Pi/2
asin(2) = nan (la réponse est pour les nombres réels)
asin(2+0i) = quelque chose de complexe, comme dans wolfram
wiki dit que asin(1) est toujours défini(https://en.wikipedia.org/wiki/Inverse_trigonometric_functions), vous pouvez écrire un rapport de bug à servicedesk.
Mais asin(2) est une région indéfinissable, elle est OK et correspond partout.
Et encore une fois à propos du dernier post - la division par 0 en mathématiques simples est impossible, il est donc logique que le script mql se plante avec une erreur, pas de bugs ici. Mais il est très étrange de voir une telle minutie dans la précision des résultats jusqu'à 16 décimales, et de renvoyer nan ou Inf lorsqu'on divise par zéro pour une raison quelconque. Imho besoin de retourner Inf et de ne pas tourmenter les développeurs avec des crashs soudains de leurs scripts.
Pour désactiver le contrôle de la division de la valeur réelle, utilisez le paramètre FpNoZeroCheckOnDivision=1 dans la section [Experts] du fichier metaeditor.ini.
Si ce paramètre est présent, le code suivant produira l'infographie
Bien entendu, la présence de ce paramètre ne vous sauvera pas d'une erreur de compilation lors de la division par une constante de 0,0.
'0.0' - division by zero in the constant expression s1.mq5 8 12
Renat, ce transfert de certaines fonctions de R vers mql était-il vraiment la surprise dont vous parliez ?
Non.
La surprise n'a pas de sens, nous ferons tout dans MQL5 et MetaTrader 5.
Si ce paramètre est présent, le code suivant donnera inf