Erreurs, bugs, questions - page 689
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
Alex, pourquoi ne prennent-ils pas la multidevise comme modèle de base et laissent ceux qui n'en ont pas besoin supplier les DC de raccourcir leur histoire en supprimant les barres synchro.
Si j'avais voulu utiliser le terminal comme un MQ à monnaie unique, j'aurais manqué le mode multidevises et le problème serait venu du fait que je l'ai positionné comme un MQ multidevises, d'où tous les problèmes qui ont suivi.
qu'est-ce que les modèles ou les modèles d'essai ont à voir avec ça ?
L'intérêt de la plateforme est de recevoir et de stocker clairement les informations initiales dans les terminaux dans la même quantité que celle reçue par le serveur.
Les développeurs peuvent ne pas donner d'informations impartiales ! Il existe autant d'informations sur les tiques qu'il en existe.
Si le modèle de test multidevises implique un bar à chaque minute, ce n'est pas un modèle du serveur, c'est un modèle du testeur.
Si le modèle de construction des indicateurs implique la présence d'une barre à chaque minute, il ne s'agit pas d'un modèle de fonctionnement du serveur mais d'un modèle de fonctionnement du testeur.
Vous n'avez pas à supplier les développeurs de modifier le serveur pour qu'il corresponde à leurs modèles de perception ou de test de l'histoire, ce n'est pas constructif.
Si vous avez besoin de l'historique des minutes manquantes, vous devez demander à vos sociétés de courtage d'ajouter les barres de chaque minute manquante à leur historique, avec un seul volume.
Demandez à votre courtier de ne pas utiliser la béquille Metaquotes ? La même béquille s'applique aux célibataires.
Avez-vous besoin que le serveur stocke l'heure de début de la barre des minutes non pas à :00 secondes mais à l'heure d'arrivée du premier tick, par exemple à :05 ou :24 ?
Si c'est tout ce dont vous avez besoin et que cela résout de nombreux problèmes de test - le terminal et la qualité de votre testeur s'amélioreront-ils beaucoup ? Un tel décalage de plusieurs secondes est-il critique pour les tests multidevises ?
N'oubliez pas que le testeur modélise tous les prix d'une barre en utilisant le volume en tick. Gagnerez-vous beaucoup si le premier tic arrive comme il l'a fait, et que tous les autres n'arrivent pas du tout comme dans la vie réelle ?
Si ce décalage n'a aucun effet sur les ticks suivants, pourquoi ce décalage ? Pour le plaisir de la première coche correcte ?
Il me semble que l'absence d'un test sur l'historique réel des tics - prenant en compte le temps réel du premier tic et modélisant les suivants - est un avantage imaginaire.
Qu'est-ce que les modèles ou les modèles d'essai ont à voir avec cela ?
L'intérêt de la plateforme est d'accepter et de stocker clairement les informations originales dans les terminaux dans la quantité qu'elles sont apparues et sont arrivées sur le serveur.
Les développeurs ne sont pas autorisés à donner quoi que ce soit ! La quantité d'informations sur les tics est la même que la quantité reçue - ni plus, ni moins.
Si le modèle de test multi-devises implique qu'il y a une barre à chaque minute, ce n'est pas un modèle du serveur, c'est un modèle du testeur.
Si le modèle des indicateurs de construction implique la présence de la barre à chaque minute, il ne s'agit pas d'un modèle de serveur, mais du modèle de l'indicateur
N'allez pas supplier les développeurs de modifier le serveur pour l'adapter à leur perception de l'histoire ou à leurs modèles de test, ce n'est pas constructif.
Si vous avez besoin de l'historique des minutes manquantes, alors vous devez le demander - à vos DCs, qu'ils ajoutent les barres de chaque minute manquante à leur historique, avec des volumes unitaires.
Nous truquons les faits pour les adapter au cours de la pensée :)
Le serveur transmet des ticks, où voyez-vous l'historique des ticks?
D'autre part, le terminal reçoit l'historique, qui est stocké par le serveur, mais pourquoi est-il considéré comme correct de stocker l'historique sur le serveur dans ce format et non dans une barre de synchronisation ?
Pourquoi le serveur lui-même n'a pas de générateur de fréquence ?
Pourquoi est-il correct de découper les barres en fonction du temps, mais l'introduction d'un générateur de fréquence ne l'est plus ???
Débarrassons-nous complètement du temps et passons aux croix et aux zéros. Il n'y a pratiquement aucune notion de temps là-bas.
Voulez-vous que le serveur enregistre l'heure de début de la barre des minutes non pas à la seconde :00, mais au moment du premier tick, par exemple à la seconde :05 ou :24 ?
Non, il ne s'agit pas de ça. La seule chose à faire est de faire correspondre le prix d'ouverture de la barre au prix qui était sur le compte réel au moment de l'ouverture de la minute. C'est-à-dire que le testeur ne doit pas mentir en montrant le prix d'ouverture de la barre à l'ouverture minute.
Un tel décalage de plusieurs secondes est-il crucial pour les tests des conseillers experts multidevises ?
Oui, car cela provoque une désynchronisation importante. Par exemple, il crée une situation d'arbitrage quasi constante entre plusieurs symboles connexes aux prix d'ouverture.
N'oubliez pas que le testeur modélise tous les prix d'une barre en utilisant le volume du tick. Combien gagnerez-vous si le premier tic arrive comme il l'a fait et que tous les autres ne ressemblent pas du tout à ce qu'ils étaient en réalité ?
Beaucoup plus qu'avant - la synchronisation se fera non seulement entre les prix de clôture, mais aussi entre les prix d'ouverture. De plus, les barres multidevises seront synchronisées, ce qui libérera une énorme quantité de ressources informatiques lors de l'optimisation, qui sont désormais consacrées à la même opération à chaque passage - la synchronisation.
Il me semble que sans un test sur l'historique réel des tick - pour prendre en compte le temps réel du premier tick et simuler les suivants - c'est un bénéfice imaginaire.
La tâche de stockage de l'historique multidevises est très similaire à celle du stockage de vidéos. Vous devez enregistrer une trame de synchronisation valide et sauvegarder les modifications à partir de celle-ci.
Actuellement, il n'y a pas de cadre synchro du tout, il n'y a que des lignes synchro. Chaque ligne (paire de devises) stocke ses changements et même les lignes n'ont pas de point de synchronisation.
Nous ne pouvons pas dire avec certitude que le prix était exactement à ce moment-là (ouverture du bar).
Puisque l'ouverture de la barre était à xx:yy:00 et que le tick d'ouverture était à xx:yy:12
Puisque l'heure d'ouverture de la barre était à xx:yy:00 et que le tick d'ouverture était à xx:yy:12
Pour le conserver de cette manière, vous devez déployer beaucoup d'efforts pour convaincre les développeurs que c'est la bonne chose à faire et que tout le monde en profitera.
Mais c'est faisable (je parle de l'aspect technique). Il suffit de les convaincre de réécrire le moteur côté serveur (ainsi que celui du terminal) pour stocker et traiter les barres :)
Dans cette situation, la résistance sera plus importante (80 %) lors de la première étape de la persuasion. Et après cela, c'est aux programmateurs de décider.
Que Veles et Ganesh les aident
Vous ne pouvez pas dire de manière fiable qu'à ce moment-là (ouverture du bar) le prix était exactement là.
Parce que l'heure d'ouverture du bar était à xx:yy:00 et le tick d'ouverture était à xx:yy:12
Vous pouvez le faire si vous ne ciblez que les prix de clôture. Mais pour ce faire, vous devez suivre l'événement de clôture de la minute (et non de la barre), en prenant Close[1] comme prix actuel.
Ces solutions de contournement sont des béquilles complètement artificielles que les développeurs utilisent, mais c'est une solution détournée.
Même si les développeurs changent la situation, le prix Ask simulé donnera toujours une désynchronisation, tant avec l'analyse réelle qu'avec l'analyse multidevise dans le testeur.
Il l'est, car il donne lieu à une grave désynchronisation. Par exemple, il crée une situation d'arbitrage quasi constante entre plusieurs symboles liés entre eux aux prix d'ouverture.
... Qui n'existe pas vraiment, mais le testeur crée l'illusion dans le testeur que l'arbitrage existe.
N'est-ce pas ?
... qui n'existe pas vraiment, mais le testeur lui donne l'illusion que l'arbitrage existe.
N'est-ce pas ?
C'est vrai. Il n'y a pas d'arbitrage dans la vie réelle, et le testeur montre des prix d'arbitrage sur des données historiques apparemment précises (non modélisées) - les prix d'ouverture.
Ce n'est pas bon...
Ici, j'ai toujours senti dans mon cerveau qu'il fallait éviter les analyses multidevises, sous peine de recevoir un râteau dans le front. Il semble que je l'ai évité pour une raison.