Erreurs, bugs, questions - page 680
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
Wow, comme tu es gentil. Désolé, j'ai oublié que c'était ton week-end. Et pour nous ? Peut-être serait-il préférable de publier les builds le lundi afin d'éviter de tels malentendus ? Nous n'avons pas de jours de congé. Nous (les traders, pas les programmeurs) nous soucions de la qualité de la plateforme. Et qu'est-ce que tu espères ?
Ne vous inquiétez pas, nous allons vérifier et réparer.
Pour l'instant, vous pouvez utiliser le mode tiki, comme auparavant - c'est la seule option fiable pour les tests. N'utilisez les autres méthodes que pour une évaluation approximative de la stratégie (indépendamment de ce que pense l'auteur de la stratégie).
C'est au programmeur d'analyser les données. La demande ci-dessus était purement privée et n'avait rien à voir avec nous ou le terminal.
"Je ne suis pas moi et le cheval n'est pas à moi". Classique.
Il s'agit, curieusement, de Thomas et non de Yeroma : il ne s'agit pas de notre analyse, mais de votre synthèse des TF seniors tout en conservant certains attributs précis - notamment temporels - de l'objet appelé barre. C'est tout. Il n'y a rien d'autre dont vous avez besoin pour être heureux en tant que programmeur.
Pensez seulement au nombre de routines inefficaces qui se produisent : vous, développeurs du terminal, avez pris la responsabilité de créer le TF senior à partir de M1, mais la noble entreprise s'est éteinte avec une accalmie ; nous, après votre synthèse, devrions faire l'opération inverse - l'analyse des données ! C'est quoi le jeu de "archiver-désarchiver" ! Où est le plaisir dans tout ça ? Si vous avez déjà inventé la synthèse, rendez-la aussi efficace que possible : fournissez à ses résultats des données plus informatives. Alors, faisons-le...
1. c'est au programmeur d'analyser les données. La demande ci-dessus était purement privée et n'a rien à voir avec nous ou le terminal.
2. vos questions sur les barres manquantes témoignent de votre ignorance de la situation du marché. Regardez les graphiques des actions ou des contrats à terme pour élargir vos horizons et les questions du type "il ne devrait pas y avoir de trous" disparaîtront instantanément.
3. Ce sont des mots généraux. Surtout en ce qui concerne la stratégie.
Renat, vous vous trompez lourdement sur l'exceptionnelle particularité de cette requête. Voulez-vous un vote du forum sur cette requête "exceptionnellement privée" ? Cela dissipera instantanément vos illusions.
2. je l'ai vu. Et alors ? Beaucoup de barres manquées ? Je ne me fais pas non plus d'illusions à ce sujet. J'ai une question à poser. Pas du tout original et en aucun cas "exclusivement privé". A savoir : le mode d'accès (et d'affichage !) aux cotations (y compris, oui, oui !, celles à faible liquidité) automatiquement ( !!) supporté par le fabricant du terminal, dans lequel tous les trous intra-session dans les cotations sont comblés par des esquives avec les paramètres {Volume=0, Open=High=Low=Close=[prix de clôture de la barre précédente]}. Pensez-vous que ce mode est demandé? Ou suis-je un grand original? Sois juste honnête, Renat. Mettez votre main droite sur votre cœur gauche.
3. OK. Laissons tomber la stratégie. Ce n'est que ma spéculation.
J'invite un peu de marge de manœuvre.
Quelque part dans les profondeurs de l'histoire, il existe une barre D1- théoriquement, il s'agit de 60*24=1440 barres minutes. À l'aide de CopyTime(), nous mordons à ses bords un segment de l'expression de l'histoire M1 et recherchons les extrema hauts et bas avec ArrayMinimum() et ArrayMaximum() sous la forme la plus précise et la plus volumineuse. Pour trouver l'heure exacte d'un extremum d'une barre, c'est un clin d'oeil mais qu'en est-il si nous devons en calculer des centaines ? Mais vous en avez besoin ! Après tout, personne n'a le droit de dire "hé, stop, je ne veux pas de ça !" et même de nous reprocher une mauvaise approche dans les limites des outils qui nous sont fournis. Et plus la barre spécifiée est éloignée dans l'historique, plusCopyTime() est lent à la gérer. Puis il y a cette conversion démoniaque entre l'heure de la barre et son indice ! Non, je ne suis pas en faveur de l'affichage des barres manquées, je suis plutôt d'accord avec l'idéologie de MetaQuotes, mais je ne peux m'empêcher de noter qu'une telle conversion est également gourmande en ressources, déroutante et alourdit le code. S'il y avait toujours exactement 60 barres de minutes dans une heure terminale (24 barres d'heures dans une journée, etc.), vous pourriez immédiatement sélectionner la barre d'indice requise par de simples opérations arithmétiques de multiplication, d'addition et de soustraction - vous ne la manqueriez pas, c'est certain... et pas de conversion double face.
Donc, à la question de parcourir 1440 barres à la recherche d'un extremum... Je vous le dis, c'est une activité qui n'a pas de sens. Et en parlant d'ingéniosité... - existe-t-il une alternative ?
Une seule chose m'est venue à l'esprit (et cela fait déjà un an, donc ce n'était même pas une alternative, mais la solution principale, que j'ai demandée ici, mais à laquelle personne n'a jamais répondu) : la méthode d'interpolation convient-elle pour obtenir la valeur temporelle exacte ? A savoir : des manipulations de substitution séquentielles avec des délais de plus en plus faibles jusqu'à M1? C'est-à-dire que nous devons faire desCopyTime() avec des sous-périodes d'intérêt, ce qui n'est pas un échantillon de performance, et ensuite substituer matryoshka. Dans l'idée, il est fait des dizaines de fois plus vite que la lecture unique complète de 1440 barres : en D1 nous avons 6xH4, en H4 - 4xH1, en H1 - 2xM30, en M30 - 2XM15, en M15 - 15XM1. Au maximum, dans chaque période, nous obtenons le nombre total de passages :
en D1: 6 barres H4, trouvées une +
dans H4: 4 barres H1, trouvé un +.
en H1: 2 barres M30, trouvées une +
M30: 2 barres M15, trouvées une +.
en M15: 15 barres M1, une trouvée = 29 itérations max vs 1440 !!!
Il semblerait que l'avantage soit évident. Et maintenant pensez, est-ce que le cristal et la RAM ne s'étoufferaient pas avec tous ces BDSM-CopyTime() en boucle pendant plusieurs périodes... Personnellement, je frémis rien qu'à l'idée d'y penser... Ensuite, il y a toutes ces vérifications de la disponibilité simultanée de données provenant de différents horizons temporels, qui peuvent ne jamais se produire, la synchronisation, etc... Et tout le flirt avec la sélection de multiples de TF inférieurs pour des TF supérieurs non standard - j'en ai fini de parler tranquillement. On dirait que mon codecraft a pris racine dans la mauvaise direction...
Quoi qu'il en soit, je ne sais pas ce qu'il en est pour vous, mais je n'ai plus aucun enthousiasme pour perdre du temps à échanger une quantité impressionnante de code.
Bien sûr, je sais que le shérif ne se soucie pas des problèmes des Indiens. Alors pour qui est le terminal ?
Je vous invite à réfléchir un peu.
............
..........Bien sûr, je comprends : le shérif ne se soucie pas des problèmes des Indiens. Alors pour qui est le terminal ?
C'est douloureusement familier. Et ennuyeux année après année. x100intraday, faisons un vote, pour voir combien de personnes en ont encore marre.
C'est douloureusement familier, et ça devient ennuyeux année après année. x100intraday, allez-y et faites le sondage, nous verrons combien de personnes supplémentaires prennent leur pied.
S'il est important en principe que je le fasse, donnez-moi des instructions (ici même ou en privé), mais sinon, vous feriez mieux de le faire vous-même, je suis tout à fait d'accord.
P.S. : Et je ne crois pas aux urnes. Regardez-moi : en tant que membre actif de divers forums et blogs, cependant contourne quelque chose qui ne me concerne pas ou qui n'ont tout simplement pas le temps de lire, même si c'est le mien. Et tout le monde n'a pas le droit de voter, quelle que soit la pertinence du problème pour eux. Et si le problème est totalement étranger, alors pourquoi tout ce travail supplémentaire ? Peut-être que ce n'est pas digne d'un tel raisonnement, mais je ne suis pas le seul à avoir ce problème. Le vote est quasi-objectif. Il faut toujours s'en remettre à l'objectivité, à la discrétion et à la prudence du collectif professionnel, qui prétend savoir mieux que nous, les utilisateurs, ce dont nous avons besoin et ce qui est mauvais pour nous. ...Sans parler des mésaventures comme le fait de lancer des votes enthousiastes non pas sur le principe "Poutine est le meilleur politicien aujourd'hui !" mais "il est le plus beau !".
Rendre un produit pratique (= quelque peu attrayant ?) pour une majorité statistique d'utilisateurs et supposer que cette majorité consommera automatiquement le produit en masse est une politique utopique. Le troupeau a une structure hiérarchique et suit toujours les leaders des sous-groupes. Tant que cela ne deviendra pas un axiome de votre stratégie de convivialité, vous continuerez à faire de grossières erreurs de calcul en évaluant l'attrait potentiel de vos services.
Dans le contexte de ce qui précède, il existe d'énormes ressources pour accroître l'attrait du terminal pour les masses - par exemple, pour enfin mettre en œuvre l'historique des minutes "sans trous", la possibilité de tester sur d'autres cotations, les ordres CCA, et beaucoup d'autres services "statistiquement non réclamés" qui sont d'un réel intérêt pour les leaders intellectuels dans vos propres forums (et pas seulement écrits de toutes pièces).
Dans MT4, cela fonctionnait comme suit : #import "TrendLine\\\MemoryDLL.dll".
Le plus drôle, c'est que j'ai essayé un tas d'options, dont celle-ci.
Le résultat est le même - le fichier requis n'est pas trouvé (je dois atteindre *.ex5).
Avant, cela fonctionnait comme suit
#import "\DirName\FileName.ex5"Maintenant, ça ne marche pas, ni les autres variantes.Vous avez peur de passer du temps à calculer des caractéristiques de barre supplémentaires pour des cas très rares (proches de zéro pour cent), mais vous demandez joyeusement que ce soit nous qui préparions beaucoup de données dans les cas de 100 %, ce qui ralentit et consomme beaucoup plus de mémoire.
Certains donnent méthodiquement de si beaux conseils pour se tuer contre le mur, qu'il est temps de parler des nuisibles.
Les stratèges de ce genre sont immédiatement visibles.
Tu n'as pas l'air de penser très loin.
Avez-vous peur de passer du temps à calculer vous-même les caractéristiques supplémentaires des barres pour les cas très rares(près de zéro %) ?
J'ai le sentiment qu'il y aura un vote :)