CopyTicksRange () ne fonctionne pas correctement dans MQL5. a - page 5
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
Oui, je lis les descriptions des fonctions jusqu'au bout, et si j'ai des doutes, je consulte également les forums. Le concept de rapidité est différent pour chacun. La dynamique est plus lente par définition, car il y a une redistribution constante de la mémoire. Le deuxième inconvénient est la fragmentation - parfois vous faites une erreur avec la dynamique et alors la mémoire n'est pas suffisante pour fermer le terminal :))).
Le ping n'a rien à voir avec ça, après le premier téléchargement, les ticks sont déjà donnés par la base, en théorie, bien sûr :) On m'a appris que le programme doit être accéléré par l'optimisation, mais pas par la base matérielle - c'est automatique. Et quelle différence cela fait-il, quel est le lien - aujourd'hui c'est l'un, demain un autre - cela ne dépend pas de l'algorithme.
J'ai mon propre courtier, c'est pourquoi je travaille avec eux depuis plus d'un an. Ma tâche consiste maintenant à maîtriser les mathématiques sur les ticks, et non le trading ou le freelancing.
Encore une fois, pour les malvoyants :
De la référence
Функция CopyTicksRange() предназначена для запроса тиков из строго указанного диапазона, например, за конкретный день истории.Depuis
La fonction CopyTicksRange() est destinée à demander les ticks d'une plage strictement spécifiée, par exemple pour un jour particulier de l'historique.
La fonction CopyTicksRange() ne récupère pas les ticks de la plage strictement spécifiée "2021.01.29 23:57:00:000, 2021.01.31 23:59:00:000". Renvoie les ticks d'une gamme complètement différente.
Veuillez fournir des mesures pour cette réclamation. J'accorde une place importante aux questions de performance chez les conseillers au combat.
Voici un exemple de code. J'ai écrit à la hâte, il peut y avoir des erreurs. Mesures pour les options suivantes :
1) le plus laid, lorsque le tableau s'agrandit au besoin
2) légèrement optimisé - lorsqu'il est étendu à la portion prévue
3) un peu plus optimisé - se dilate avec une marge de plusieurs portions
4) la mémoire statique, qui sera évidemment toujours nulle
Il est clair que si vous allouez dynamiquement une énorme quantité de mémoire pour tout dans le monde, alors la vitesse sera comme en statique, mais cela arrive rarement
Sur les baies à expansion dynamique, le pire est la fragmentation de la mémoire, qui engloutira tout au cours du processus. Eh bien, le temps toujours croissant pour la prochaine extension - parce que. dans une mémoire très fragmentée, il faut plus de temps pour rechercher une pièce appropriée
résultats en microsecondes. La forte augmentation du temps requis dans la première colonne vers la fin est probablement due au fait que le terminal alloue probablement de la mémoire pour les tableaux en petits blocs, optimise un peu pour nous. Mais lorsque le tableau devient plus grand que le bloc, il commence bêtement à chercher la première pièce vide appropriée. Je me tords beaucoup plus loin, ça devient très long là… plusieurs secondes. Et il n'y avait qu'environ 1 000 000 de cellules
Voici un exemple de code. J'ai écrit à la hâte, il peut y avoir des erreurs. Mesures pour les options suivantes :
1) le plus laid, lorsque le tableau s'agrandit au besoin
2) légèrement optimisé - lorsqu'il est étendu à la portion prévue
3) un peu plus optimisé - se dilate avec une marge de plusieurs portions
4) la mémoire statique, qui sera évidemment toujours nulle
Il est clair que si vous allouez dynamiquement une énorme quantité de mémoire pour tout dans le monde, alors la vitesse sera comme en statique, mais cela arrive rarement
Sur les baies à expansion dynamique, le pire est la fragmentation de la mémoire, qui engloutira tout au cours du processus. Eh bien, le temps toujours croissant pour la prochaine extension - parce que. dans une mémoire très fragmentée, il faut plus de temps pour rechercher une pièce appropriée
résultats en microsecondes. La forte augmentation du temps requis dans la première colonne vers la fin est probablement due au fait que le terminal alloue probablement de la mémoire pour les tableaux en petits blocs, optimise un peu pour nous. Mais lorsque le tableau devient plus grand que le bloc, il commence bêtement à chercher la première pièce vide appropriée. Je me tords beaucoup plus loin, ça devient très long là… plusieurs secondes. Et il n'y avait qu'environ 1 000 000 de cellules
Et c'est comme ça que je l'obtiens
La vérité un peu corrigée
Et si vous initialisez des tableaux
alors alors
il a été testé pendant deux ans !
Quel têtu ! Lisez ce qu'ils ont écrit ci-dessus - CopyTicks a les mêmes problèmes. Si vous aimez chercher des moyens de faire fonctionner une fonction boguée ou trouver des solutions de contournement boguées, alors ne vous donnez pas la peine - il ne s'agit pas de cela.
En deux ans, vous auriez pu comprendre que si une fonction ne fonctionne pas comme vous le souhaitez et que les développeurs le savent et ne la corrigent pas, cela ne s'appelle pas un bug...
Levez le pouce, programmeurs cool et instruits.........
INT_MAX = 2147483647
en fait, vous avez immédiatement arraché un morceau de mémoire INT_MAX* sizeof(double) et ensuite travailler comme avec static
vous auriez pu écrire
double d[INT_MAX] ; - ce serait la même chose pour vous que
la seule différence sera dans le fonctionnement de la fonction ArraySize() alors que la totalité de la mémoire sera chiée en une seule fois.
Corrigé, il sera en version bêta aujourd'hui.
Merci beaucoup. Je vais pomper de joie :) la solution de contournement était très gourmande en ressources.
Corrigé, il sera en version bêta aujourd'hui.