AlexSTAL: Pour être honnête, ce n'est pas comme ça...
C'est une sorte de respect pour les autres. Vous n'avez pas besoin de comprendre les codecs et les logiciels de codage. Mais vous pouvez créer une simple archive ZIP (cela prend une seconde) et réduire le trafic au centuple. Il y a un test bêta gratuit de MT5, n'est-ce pas ?
hrenfx: OFFTOP : cette vidéo occupe 216 MB. Envisagez de le précompresser (au moins avec un simple archiveur). Vous trouverez ci-joint un exemple de compression (sans perte) de la même vidéo (400x). Il existe de nombreux codecs de compression sans perte, dont beaucoup sont parfaitement compris par les services de vidéo en ligne.
MSU Screen Capture Lossless Codec MSU Graphics & Media Lab (Video Group) Идеи, реализация: Дмитрий Попов News: [13.02.2007] Версия 1.2. [02.04.2006] Версия 1.1. [24.03.2006] Версия 1.0. Скачать! (v1.2) Изменения в версии 1.2: Изменения в версии 1.1: Добавлена поддержка "force key frames". Теперь кодек работает не только в RGB24...
fellow: Comment obtenir timeDate à partir d'un numéro de barre ?
intCopyTime(
string symbol_name, // имя символаENUM_TIMEFRAMES timeframe, // периодint start_pos, // откуда начнем int count, // сколько копируемdatetime time_array[] // массив для копирования времени открытия
);
Veuillez expliquer comment il est possible qu'une transaction dont le volume est supérieur à celui de la position et dont le type est opposé ait une direction non pas "in/out" mais "out".
la dernière colonne est le volume de la position, l'avant-dernier type de position. L'avant-dernière donne a diminué la position et la dernière donne dans cette partie de la table devrait être
La dernière donne dans cette partie du tableau devrait être "in/out" car elle est plus grande que la position et a le type opposé. Mais dans le rapport, c'est "out".
2010.10.04 00:01:00
vendre
sur
0.1
83.292
0
0
1
0
1
0.1
2010.10.04 03:49:00
vendre
sur
0.1
83.785
0
0
1
1
1
0.2
2010.10.05 16:57:00
acheter
sur
0.1
83.123
0
0
1
2
1
0.1
2010.10.05 16:57:00
acheter
out
0.2
83.136
96.83
96.83
1
3
-1
0
2010.10.07 09:20:00
acheter
sur
0.1
82.633
0
96.83
2
0
0
0.1
2010.10.07 09:39:00
acheter
sur
0.1
82.37
0
96.83
2
1
0
0.2
2010.10.07 14:59:00
acheter
sur
0.1
82.216
0
96.83
2
2
0
0.3
2010.10.08 14:30:00
acheter
sur
0.1
82.074
0
96.83
2
3
0
0.4
2010.10.08 14:30:00
acheter
sur
0.1
82.072
0
96.83
2
4
0
0.5
2010.10.08 15:25:00
acheter
sur
0.1
81.869
0
96.83
2
5
0
0.6
2010.10.08 15:25:00
acheter
sur
0.1
81.921
0
96.83
2
6
0
0.7
2010.10.08 15:25:00
acheter
sur
0.1
81.812
0
96.83
2
7
0
0.8
2010.10.08 15:30:00
acheter
sur
0.1
81.755
0
96.83
2
8
0
0.9
2010.10.11 00:00:00
acheter
sur
0.1
81.58
0
96.83
2
9
0
1
2010.10.11 00:00:00
acheter
sur
0.1
81.58
0
96.83
2
10
0
1.1
2010.10.11 00:00:00
acheter
sur
0.1
81.56
0
96.83
2
11
0
1.2
2010.10.11 00:00:00
acheter
sur
0.1
81.57
0
96.83
2
12
0
1.3
2010.10.11 02:54:00
vendre
sur
0.1
82.09
0
96.83
2
13
0
1.2
2010.10.11 02:54:00
vendre
out
1.4
82.09
137.04
233.87
2
14
Le rapport lui-même est dans l'atacha.
Il s'avère que l'algorithme entier ne fonctionne pas correctement à cause de cette erreur. C'est la même chose sur la ligne 4.
Veuillez expliquer comment il est possible qu'une transaction avec un volume plus important que la position et le type opposé ait la direction non pas "in/out" mais "out".
la dernière colonne est le volume de la position, l'avant-dernier type de position. L'avant-dernière donne a diminué la position et la dernière donne dans cette partie de la table devrait être
La dernière donne dans cette partie du tableau devrait être "in/out" car elle est plus grande que la position et a le type opposé. Mais dans le rapport, c'est "out".
Le rapport lui-même est atacha.
Il semble que l'algorithme entier ne fonctionne pas correctement à cause de cette erreur. Il en va de même pour la quatrième ligne.
Apparemment, nous devrons changer l'algorithme parce qu'il n'y a pas de transactions "in/out" dans les rapports du championnat.
Je pense que MQ ne devrait toujours pas avoir sauvegardé l'historique des positions, juste deux colonnes volume et niveau de moyenne, mais tout devient beaucoup plus facile.
Par conséquent, toute erreur dans le rétablissement du volume et du niveau de la position est critique.
Oui, en effet, je ne les ai pas tous parcourus :o), merci. Alors c'est une sorte de bug. J'ai échantillonné à la fois manuellement et algorithmiquement selon le rapport de Manov, et c'est un bug dans les deux cas. Je vais vérifier le vôtre, si ce n'est pas un bug, alors c'est le rapport de Manov.
Pour être honnête, ce n'est pas comme ça...
OFFTOP : cette vidéo occupe 216 MB. Envisagez de le précompresser (au moins avec un simple archiveur). Vous trouverez ci-joint un exemple de compression (sans perte) de la même vidéo (400x). Il existe de nombreux codecs de compression sans perte, dont beaucoup sont parfaitement compris par les services de vidéo en ligne.
manque un codec au fichier.
Il s'agissait donc d'un simple exemple hors sujet, et non d'une incitation à l'action.
MSU Screen Capture Lossless Codec
Comment obtenir timeDate à partir d'un numéro de barre ?
Veuillez expliquer comment il est possible qu'une transaction dont le volume est supérieur à celui de la position et dont le type est opposé ait une direction non pas "in/out" mais "out".
la dernière colonne est le volume de la position, l'avant-dernier type de position. L'avant-dernière donne a diminué la position et la dernière donne dans cette partie de la table devrait être
La dernière donne dans cette partie du tableau devrait être "in/out" car elle est plus grande que la position et a le type opposé. Mais dans le rapport, c'est "out".
Le rapport lui-même est dans l'atacha.
Il s'avère que l'algorithme entier ne fonctionne pas correctement à cause de cette erreur. C'est la même chose sur la ligne 4.
Veuillez expliquer comment il est possible qu'une transaction avec un volume plus important que la position et le type opposé ait la direction non pas "in/out" mais "out".
la dernière colonne est le volume de la position, l'avant-dernier type de position. L'avant-dernière donne a diminué la position et la dernière donne dans cette partie de la table devrait être
La dernière donne dans cette partie du tableau devrait être "in/out" car elle est plus grande que la position et a le type opposé. Mais dans le rapport, c'est "out".
Le rapport lui-même est atacha.Il semble que l'algorithme entier ne fonctionne pas correctement à cause de cette erreur. Il en va de même pour la quatrième ligne.
Apparemment, nous devrons changer l'algorithme parce qu'il n'y a pas de transactions "in/out" dans les rapports du championnat.
Je pense que MQ ne devrait toujours pas avoir sauvegardé l'historique des positions, juste deux colonnes volume et niveau de moyenne, mais tout devient beaucoup plus facile.
Par conséquent, toute erreur dans le rétablissement du volume et du niveau de la position est critique.
il n'y a pas du tout d'opérations "entrée/sortie" dans les rapports du championnat.
Pourquoi pas ? J'en ai eu plusieurs : https://championship.mql5.com/2010/ru/users/Yedelkin/history_deals
Pourquoi pas ? J'en ai eu un paquet : https://championship.mql5.com/2010/ru/users/Yedelkin/history_deals
Toujours un bug dans le rapport, regardez attentivement vos 3 premiers trades. Le troisième métier devrait être "in/out".
Désolé, pas le rapport, mais l'affichage de l'investisseur historique dans le terminal.