Sujet intéressant pour beaucoup : les nouveautés de MetaTrader 4 et MQL4 - de grands changements en perspective - page 50
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
Puis c'est la condescendance (attention à ce genre de choses - pire que la critique nue) :
:-)
C'est un peu tard pour moi pour boire du borjomi ou pour me racheter. Une place en enfer m'est réservée depuis longtemps.
Je ne pense pas qu'essayer de comprendre sans juger soit le plus grave de mes péchés. ;)
Il existe une telle lettre. Cependant, le gap (saut discontinu de la citation) peut se produire à n'importe quel moment, pas seulement au début de la barre. Donc, tout format "aminci" n'est pas sans péché, par définition. L'alimentation complète ne se fait qu'en ticks. Et elle pourrait être encore plus complète dans l'histoire de la coupe. J'essaie de me faire un format minute, pour l'instant j'ai trouvé ce compromis.Je peux laisser le système tel qu'il est décrit ci-dessus (sans Open, seulement {Hi-Lo-Close}), je comprends tous les inconvénients, ce n'est qu'une version de mon codage pour mon testeur. J'utiliserai les ticks bruts ou les réduirai artificiellement par n'importe quelle méthode (avec des ticks sauvegardés au format {bid-ask-time}).
Je ne pense pas que chercher à comprendre sans juger soit le plus grave de mes péchés. ;)
Penser, en termes de gravité du péché, est bien sûr plus fort. Je suis d'accord.
Je suis content que tu aies raison. Alors tu ferais mieux de te trouver un chaudron à côté du mien. Ça nous donnera beaucoup de temps pour bavarder. Pas de liberté conditionnelle.
;)
Etes-vous sûr que les barres MQ M1 sont stockées sans emballage ?
Alors comment se fait-il qu'il y ait des retards dans l'obtention de l'historique (petits mais présents), mais que la réapplication (comme dans le cache) soit plus rapide.
Apparemment, dans le fichier d'historique, les barres sont stockées comme des changements de synchrobar, ceux-là sous forme comprimée.
Donc votre compte de 52 octets est un compte de l'histoire non emballée.
Etes-vous sûr que les barres MQ M1 sont stockées sans emballage ?
Alors comment se fait-il qu'il y ait des délais pour obtenir l'historique (petits mais il y en a), mais que la réapplication (comme dans le cache) soit plus rapide.
Apparemment, dans le fichier d'historique, les barres sont stockées comme des changements de synchrobar, ceux-là sous forme comprimée.
Donc votre calcul sur les 52 octets est un calcul de l'histoire non emballée.
Je n'ai rien dit à ce sujet, et pas seulement cela - je suis sûr qu'il y a des emballages. Le format n'est pas déclaré au public, et je n'ai pas essayé de le "craquer".
Donc tout est correct, j'ai décrit uniquement le format déballé. C'est tiré de la documentation.
Je n'ai rien dit à ce sujet, non seulement ça, mais je suis sûr que c'est emballé. Le format n'est pas annoncé publiquement et je n'ai pas essayé de le "craquer".
C'est donc vrai, je n'ai que le format non emballé décrit. C'est tiré de la documentation.
C'est exact, mais vous essayez de montrer que le nouveau format sera économe, tout en comparant le format actuel non emballé et le nouveau format partiellement emballé.
Je ne compare pas l'économie, vous avez imaginé, seulement l'informativité. Pas d'économie, mon format non emballé est plus == 88 octets {Open, High, Low, Close} et == 72 octets {High, Low, Close}.
Tu n'aurais pas dû avoir le cancer à cause de la pierre. J'aurais suggéré de doubler l'informativité au lieu de 52 octets 88.
La même chose depuis le début que celle suggérée par Hrenfx.
Pourquoi existe-t-il un format contenant autant de données ? C'est-à-dire qu'il est nécessaire de définir les limites de ce filtre tick (ce format), lorsqu'il ne diffère pas du résultat de l'historique tick pur.
À première vue, un simple filtre tick HighBid+LowAsk n'est pas beaucoup plus mauvais que le filtre intelligent (en fonction de la quantité de données).
Close-data n'est bon que pour la synchronisation multidevises.
Il est peut-être plus facile de passer à une période plus courte au lieu de faire cela. Par exemple, S20 ne nécessite que 48 octets pour la même minute au format HighBid+LowAsk (peut-être même moins, si 4 octets par prix sont plus que suffisants). Dans mon testeur, je fais tout via long int - très rapide). Et en termes de précision, 100% battra votre filtre minute de 88 octets.
P.S. La fonction Error(Freq, DataSize) = Full - Freq * DataSize tend vers zéro, lorsque la fréquence augmente,
où Erreur est la perte d'information.
Full - informations complètes sur le marché.
Freq * DataSize est une fonction de "multiplication" : la quantité d'information qui peut être récupérée avec la fréquence de quantification Freq, et le contenu en information(DataSize) pour chaque terme de quantification.