Erreurs, bugs, questions - page 688

 

Réponse concernant les écarts négatifs.

Dans le processus de génération des ticks, la pertinence de tous les spreads est vérifiée. Lors de la formation des conditions de la barre OHLC pour la période testée, un contrôle similaire n'a pas été effectué. Les écarts négatifs sont présents dans l'histoire par erreur. Nous allons le réparer. Nous allons également insérer le contrôle dans le mode "par prix d'ouverture".

 
papaklass:

Messieurs, est-ce que quelqu'un a fait fonctionner le multidevise en mode de visualisation du prix d'ouverture en référence à d'autres TF ?

Voici le graphique quotidien :

Et quelle stratégie peut-on tester sur ce graphique ?



Honnêtement, je ne comprends rien à la photo ci-jointe. La seule chose qui soit claire, c'est que l'auteur n'est pas satisfait de quelque chose. Mais vous avez besoin d'être compris.
 
papaklass:

C'est tout.

Tant que vous ne verrez pas l'absence de conclusions directes dans vos messages, vous surprendrez constamment les autres.

Cependant, je pense que c'est un comportement tout à fait délibéré.

 
papaklass:

PS : J'essaierai de ne plus vous distraire de l'affaire en cours.

Tu n'as pas marqué un point, tu as poussé trois personnes à poser plus de questions.

C'est exactement ce que j'ai souligné "c'est un comportement délibéré de votre part".

Et ta dernière réponse le confirme exactement - au lieu d'une conclusion claire sur une capture d'écran insignifiante tu es allé jouer le jeu "joue avec moi, travaille, réfléchis au problème que je t'ai posé, et j'aurai l'occasion de te critiquer tant tu es déraisonnable pour ton incompréhension".

Vous comprenez maintenant ? Nous ne sommes pas des enfants pour jouer le cirque devant nous, en jouant l'offensé.

 
Renat:
Laissez tomber le sujet - aucun changement n'est en vue sur ce front de sitôt.

Renat, bon après-midi !

En principe, je suis d'accord avec vous. Pas d'offres dans la profondeur de marché = pas de marqueurs uniques sur le graphique des prix (respectivement, pas de barres dans le regroupement de l'historique temporel).

D'autre part, je ne comprends pas très bien votre position qui consiste à ne pas vouloir améliorer le terminal (algorithme plus clair, ou autre).

La synchronisation de l'historique est l'un des piliers fondamentaux du trading robotisé. Distraits par la vérification des données historiques, nous, les programmeurs, sommes obligés de nous détourner de l'analyse technique et de passer beaucoup de temps intellectuel (codage) et CPU/consommateur (exécution du programme/attente humaine) sur une routine insignifiante. On vous a déjà proposé une solution plutôt élégante, à mon avis de profane, qui est la suivante :

1. Ne nuit pas aux indicateurs déjà existants.

2. Cela réduira le temps d'écriture d'un code (spécifique).

3. Réduira le temps d'exécution du code (spécifique).

4. Cela n'alourdira pas le terminal de manière significative (les barres vides seront calculées et placées dans la base de données une fois, lors du téléchargement de l'historique).

J'ai utilisé le terme "spécifique" à dessein. Parce que, selon vous, c'est ~0% des cas. C'est seulement ~0% des cas jusqu'à présent.

Les arguments en faveur de la nécessité de tels barreaux dans l'histoire vous sont donnés.

Veuillez fournir les contre-arguments.


P.S.

Je m'excuse de m'immiscer dans la conversation. C'est juste que moi aussi, je suis une personne d'intérêt.

 
voix_kas:

Renat, bon après-midi !

Malheureusement, la question est complètement close.

Il existe de nombreux contre-arguments critiques et je crains que les commerçants n'en soient pas conscients.

 
Renat:

Malheureusement, la question est complètement close.

Il existe de nombreux contre-arguments critiques et je crains que les commerçants n'en soient pas conscients.

Alors éclairez-nous, ce n'est pas par simple curiosité que les gens veulent des barres de synchro.

À mon avis, avec l'état actuel est la deuxième compression irréversible de l'information (et en fait IMHO cette compression est moins utile que nuisible).

Le premier irréversible se produit lorsque les tiques forment des barres.

Tout cela est acceptable dans le cadre d'une négociation en une seule devise, mais puisque le terminal est multidevises, ayez la gentillesse de vous y conformer.

La principale différence entre l'analyse multidevise et l'analyse monodevise est que cette dernière considère que les changements dans toutes les devises sont interdépendants, c'est-à-dire qu'il s'agit d'un processus unique.

Alors que dans l'approche de la monnaie unique, tout est indépendant, même si cela se produit en même temps.

Même si nous supposons que votre approche est correcte (pas de tick ni de barre), mais que nous la passons à travers le prisme du tick multi-devises, nous arriverons à la nécessité de la synchronisation.

Je pense que cette discussion devrait être déplacée vers "Souhaits pour MT5".

ZZZY by the way dans le sujet de souhaite cette demande sur la première page il y a plus de 2 ans

MetaDriver 2009.11.20 00:59

ZZZZY Renat, il s'avère que vous 2 ans ne peuvent pas "raisonnablement" expliquer pourquoi une telle chose comme la synchronisation ne sera pas mis en œuvre. Intelligible - pour que les personnes pensantes soient d'accord avec vous et vous laissent tranquille.

 
voix_kas:

Les arguments en faveur de la nécessité de tels barreaux dans l'histoire vous ont été donnés.

Si vous avez des sauts et des ajouts d'esquives et de ticks qui n'ont pas eu lieu, allez voir vos sociétés de courtage.

Le travail des développeurs ne consiste pas à créerdes barres pour lesquelles aucune donnée n'est entrée dans la plateforme.

La tâche du développeur est de fournir des données exactes et non déformées du fournisseur de devis à la plate-forme et aux terminaux.

Tout le reste - ce sont d'autres questions et les développeurs ne s'occuperont pas et ne devraient pas s'occuper de telles choses, qui ne sont pas dans la compétence du noyau de la plate-forme d'information et de commerce.


Votre société de courtage peut ajouter les barres de minutes manquantes. N'hésitez pas à les contacter sur leur support technique et à leur demander de l'aide.

Les développeurs ne gâcheront pas l'histoire réelle de base par leur intervention forcée dans celle-ci.

Une fois de plus, demandez une telle opération à vos sociétés de courtage.

 
sergeev:

Si vous avez un problème avec les omissions et les ajouts d'esquives et de tics, demandez à vos sociétés de courtage.

Le travail des développeurs ne consiste pas à créerdes barres pour lesquelles aucune donnée n'est entrée dans la plateforme.

La tâche du développeur est de fournir des données exactes et non déformées du fournisseur de devis à la plate-forme et aux terminaux.

Tout le reste est un autre type de question et les développeurs ne s'occuperont pas et ne devraient pas s'occuper de ce genre de choses, qui ne sont pas du ressort de la plate-forme d'information et de négociation de base.


Votre société de courtage peut ajouter les barres de minutes manquantes. N'hésitez pas à les contacter sur leur support technique et à leur demander de l'aide.

Les promoteurs ne gâcheront pas l'histoire réelle de base par leur intervention forcée.

Une fois de plus, demandez une telle opération à vos sociétés de courtage.

Alex, pourquoi ne pas utiliser le modèle multidevises comme base et laisser ceux qui n'en ont pas besoin demander aux sociétés de courtage de réduire l'historique en supprimant les barres synchro.

Le problème est que MQ a positionné le terminal comme une base multi-devises, sans événement multi-devises, d'où tous les problèmes ultérieurs.

 
Vous vous rendez compte que dans le testeur, l'heure d'ouverture de la barre ne correspond pas à l'arrivée du premier tick dans la vie réelle ! Au moment où la barre s'est ouverte dans le testeur, le prix était en fait (99%) très différent dans le réel - le prix de clôture de la barre précédente. <br/ translate="no">.
Et le prix d'ouverture de la barre correspond réellement au prix qui était au moment où la minute a été formée, comme le rapporte heureusement le testeur ?
La tâche est simple, faire en sorte que le testeur donne le moins d'imprécisions possible. En ce moment, le testeur ment presque toujours en disant que le prix au moment de la formation de la minute est égal au prix d'ouverture de la barre. C'est la raison pour laquelle l'arbitrage se produit toujours aux prix ouverts dans le testeur, alors qu'il n'y a pas d'arbitrage aux prix fermés. Et, en conséquence de l'utilisation du modèle poétique de formation des barres, TC devra dépenser ses ressources informatiques pour synchroniser plusieurs FI sur les prix de clôture des barres. Les développeurs économisent sur les matchs pour laisser les utilisateurs gaspiller beaucoup de ressources informatiques sur une synchronisation stupide à chaque fois qu'ils s'exécutent dans le testeur. Ils ne vous permettent pas d'effectuer cette synchronisation avant d'exécuter l'optimisation.

Demander au courtier de ne pas utiliser la béquille Metaquotes ? La même béquille s'applique aux paires de devises individuelles.

Tout n'est pas sous le contrôle d'un courtier. Par exemple, le courtier peut facilement diffuser le symbole Ask (et même de manière synchrone avec le symbole Bid) afin qu'il y ait aussi l'historique des Ask. Mais cela n'incitera toujours pas le testeur à en tenir compte.