Servicedesk : paresse, autisme ou refus d'admettre ses erreurs ? Compléter les graphiques avec des bougies non natives. - page 10

 
Rosh:
Vous n'avez pas compris ou même essayé. Qu'est-ce qu'un jour de congé a à voir avec ça ? Au minimum, tirez le numéro de la semaine à partir de la date - tout cela doit-il être expliqué ?

Il n'y a pas besoin d'expliquer, j'ai travaillé sur cet algorithme et j'ai résolu le problème,

C'est pourquoi je dis que MQ devrait fournir une fonction pratique permettant aux utilisateurs de masse de récupérer ces informations.

Et la meilleure façon de le faire n'est pas la recherche binaire, mais l'écriture de dates de collage dans les fichiers d'historique eux-mêmes.

 
Rosh:

J'ai vu une image similaire non seulement sur le serveur MQ. La raison pour laquelle votre serveur a besoin d'un tel mélange n'est pas claire ? C'est un exemple, un échantillon.

Si vous imaginez que les courtiers vont commencer à tout faire correctement(téléchargement de l'historique), quoi, le problème va disparaître ? Après tout, il est clair que l'histoire profonde sous forme de minutes est moins accessible que les grandes. Et ça ne fera pas mal du tout.

 
Urain:

C'est pourquoi je soutiens que pour l'utilisateur de masse, c'est à MQ de fournir une fonction pratique pour récupérer ces informations.

L'utilisateur de masse ne s'en soucie pas du tout. Et dans de rares cas, vous pouvez tout résoudre vous-même en utilisant MQL5.
 
Urain: et la meilleure façon de le faire n'est pas de procéder à une recherche binaire, mais d'écrire les dates de collage dans les fichiers d'historique eux-mêmes.
"La route de l'enfer est pavée de bonnes intentions".
 
220Volt:

Si l'on imagine que les courtiers commencent à faire les choses correctement (téléchargement de l'historique), quoi, le problème disparaît ? Après tout, il est clair que l'histoire profonde, sous forme de détails, est moins accessible que la grande histoire. Et ça ne ferait pas de mal du tout.

Il n'y a pas de réel problème, il est purement théorique et n'apparaît que si vous essayez d'obtenir des minutes de nativité.

Les courtiers doivent juste avoir des cotations minute correctes au moins pour les 5-10 dernières années et c'est tout.

 
220Volt:

J'ai vu une image similaire non seulement sur le serveur MQ.

Parce que c'est pareil.

Si on imagine que les courtiers commencent à faire les choses correctement (téléchargement de l'historique), quoi, le problème disparaît ?

bien sûr.

pas de "gaucher" dans le procès-verbal - pas de problème.

 
C'est tout, j'arrête, je n'ai pas le temps de perdre ma vie à améliorer votre terminal.
 

Je n'ai pas du tout besoin d'historique avant l'EURUSD, donc je ne regarde même pas en dessous de 2005.

MQ a le meilleur historique, regardez l'historique des autres sociétés de courtage.

J'ai testé 10 de leurs plus réputés, ce n'est pas de l'histoire, c'est juste des conneries, c'est difficile de comprendre comment ils sont testés là-bas.

 
Renat:
Je n'admets pas l'existence d'un problème, mais j'explique point par point qu'il n'y en a pas.
Comment pourrait-il en être autrement si les fonctions ne fonctionnent pas ?
 
sergeev:

points de stitching ? où le stocker ? comment le contrôler manuellement ? comment remplir le fichier historique ?


Je parle d'une solution de la part des développeurs... l'utilisateur ne peut faire aucune des choses que j'ai décrites...

sergeev:


Anton, les barres sont TOUTES des barres minutes. tout l'historique est stocké sur le serveur uniquement sous forme de barres minutes. les autres TF sont construites sur la base de barres minutes lorsqu'elles sont chargées dans le terminal.

Le fait que vous voyez une barre journalière dans les minutes jusqu'à 99 signifie que cette barre est "journalière" dans les barres de minutes. C'est là. Vous voyez ?

Si vous voulez savoir s'il s'agit réellement d'une barre quotidienne ou si c'est une barre DAILY entrée dans les barres minutes, vous pouvez le faire en ajoutant ce paramètre...