Test des "CopyTicks". - page 23
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
Il est optimal de télécharger une fois ce dont vous avez besoin au plus profond de vous-même, puis de n'en télécharger de nouveaux qu'en quelques microsecondes depuis le cache voisin.
Si vous faites des requêtes profondes à chaque fois avec un échec sur le disque, alors bien sûr c'est votre propre faute.
Pouvez-vous me montrer le code de la meilleure façon d'obtenir l'historique des tics pour la première semaine de septembre ?
Rédigez-le vous-même, ce n'est pas une tâche difficile.
Recherchez les dates exactes et enregistrez-les dans un tableau local. Il n'y a pas d'optimalité lorsque l'on travaille en dehors du cache. L'optimisation n'a de sens que lorsque vous téléchargez les 4096 derniers ticks du cache.
Rédigez-le vous-même, ce n'est pas une tâche difficile.
Faites une requête sur les dates exactes et stockez-les dans un tableau local.
De cette façon, vous ne pouvez pas savoir à l'avance combien de ticks il y a eu sur l'intervalle requis. Il n'y a aucun moyen de déterminer le paramètre de comptage. Voici le problème.
Pour pomper TOUTE l'histoire depuis début septembre, en fixant le compte = trillion - vous pouvez, bien sûr. Ensuite, utilisez la recherche binaire pour trouver la date de fin dans le tableau et tronquez-la.
Mais ce trilliard n'est pas du tout une approche technique. Soit nous devons surcharger la fonction avec from, to. Ou l'accès à l'index de la base de données.
L'optimisation n'a de sens que lors du téléchargement des 4096 derniers ticks du cache.
De la référence :
Sortie rapide : le terminal stocke pour chaque symbole 4096 derniers ticks en cache pour un accès rapide (pour les symboles avec une pile en cours - 65536 ticks).
Nous préparerons des améliorations pour CopyTicks dans la prochaine version :
Nous préparerons des améliorations pour CopyTicks dans la prochaine version :
Merci !
À propos de l'historique entièrement chargé de & à, probablement, dira zéro GetLastError.
Notez qu'aujourd'hui (et avec l'introduction des améliorations que vous avez décrites), il est extrêmement difficile d'obtenir une coche qui était avant l'heure de départ. Par conséquent, je propose de faire le compte et le négatif - une demande de ticks non seulement au futur (vers la droite), mais aussi au passé (comme à partir de == 0).
Il sera alors toujours pratique et optimal (votre mise en œuvre) d'interroger l'historique précédent.
Merci !
Un historique entièrement téléchargé de & à serait probablement indiqué par un GetLastError nul.
Notez que maintenant (et avec l'introduction des améliorations que vous avez indiquées) il est extrêmement difficile d'obtenir une coche qui était avant l'heure de départ. Par conséquent, je propose de faire le compte et le négatif - une demande de ticks non seulement au futur (vers la droite), mais aussi au passé (comme à partir de == 0).
Il sera alors toujours pratique et optimal (votre mise en œuvre) d'interroger l'historique précédent.
Il est préférable de rendre les surcharges de CopyTicks() identiques à celles des autres fonctions Copy...().
Ensuite, nous devons abandonner le comptage et le départ par défaut.
Pourquoi ? En utilisant CopyBuffer comme exemple, nous avons maintenant ceci :
intindicator_handle,// poignée d'indicateur
intbuffer_num,// numéro de la mémoire tampon de l'indicateur
datetimestart_time,//date
intcount,// combiencopy
doublebuffer[]// tableau, où les données seront copiées
);
Il y a un compte et un départ (start_time).
Vous suggérez d'ajouter ceci :
intindicator_handle,// poignée d'indicateur
intbuffer_num,// numéro du tampon de l'indicateur
datetimestart_time,// à partir de quelle date
datetimestop_time,// jusqu'à quelle date
doublebuffer[]// tableau, où les données seront copiées
);
Donc on peut copier dans les deux sens, non ? Seulement, au lieu de datetime - ulong (en microsecondes).
J'ajouterai cette surcharge à d'autres fins dans le futur :
intCopyBuffer(
intindicator_handle,// poignée d'indicateur
intbuffer_num,// numéro de tampon de l'indicateur
intstart_pos,//où nous commençons
intcount,// combien nous en copions
doublebuffer[]// tableau qui copiera les données
) ;
C'est tout.
Nous devrons alors abandonner le comptage et le départ par défaut.
Je ne l'ai pas lu attentivement au début... Oui, je dois le faire. Et alors ? Si les développeurs étendent le cache - il sera plus lent uniquement lors du chargement d'un historique de tics assez important, et souvent ce n'est pas nécessaire de le faire. Et pour le chargement en temps réel, il ne sera pas affecté (il sera pris dans le cache).
Je pense qu'il est beaucoup plus important de charger de date à date, que d'essayer de sauvegarder les paramètres par défaut.