L'historique des tics est-il disponible sur le serveur ? - page 2

Nouveau commentaire
 
Mais pourquoi former l'historique non seulement par tranches de temps, mais aussi par plusieurs ticks ? disons 10, 100, 500, 1000, etc. Dans ce cas, il s'agit d'un graphique temporel réduit au volume. Vous ne pouvez pas nier que le volume est un indicateur très important pour l'analyse. Ce sera très clair. En outre, vous pouvez former l'historique par le nombre de ticks ou par l'indicateur de temps, selon vos besoins. Les données accumulées peuvent être partagées dans des forums - qui a collecté quoi. Je ne pense pas qu'il soit difficile de prévoir cela de manière programmatique. Pour reconstituer les données manquantes (le terminal a été fermé), vous pouvez stocker l'historique des ticks sur le serveur pendant une petite période (disons 1 à 3 jours).
 
Vous ne pouvez pas nier que le volume est un indicateur très important pour l'analyse.
Ce
serait très visuel.


Apparemment, les développeurs ont juste besoin de clouer le site web en grosses lettres dans un endroit visible : "Il n'y a pas de tiques et il n'y en aura pas ! Les discussions sur les ticks ainsi que sur les courtiers seront supprimées des forums" :o)))). Sinon, tout va tourner en rond chaque semaine. Juste les mots des malades sans aucune preuve détaillée de la nécessité de garder les tiques...
 
Pouvez-vous être plus précis sur les tiques dont il s'agit ?
Il serait intéressant de voir l'historique des tics des comptes réels.
La littérature est tellement passionnée par les graphiques qu'il faut y réfléchir à deux fois avant d'utiliser un EA pour le trading réel.
Et je n'ai vu nulle part que le courtier a mis en place les archives des ticks réels - alors je commence à penser, peut-être qu'il y a vraiment quelque chose à cacher ?
 
C'est là que vous êtes pris. Je dis spécifiquement - prouver que la modélisation intra-minute a de sérieuses divergences. Surtout par 10 points. Il suffit de prendre les données, de faire les recherches, de publier tous les résultats (y compris les dossiers historiques) et de nous clouer au mur. <br / translate="no">.
Je soutiens que la marge d'erreur dans la modélisation des minutes est de 1 à 2 points. Et cette erreur est parfaitement acceptable et normale.

Renat,
Je ne le prouverai pas car je suis absolument d'accord avec vous. De plus, je ne vais pas épingler qui que ce soit au mur. Je déclare : Je suis assez satisfait de la modélisation des tics dans le testeur. Je n'ai absolument aucun reproche à lui faire.

En même temps, je le répète une fois de plus :
La nécessité d'une histoire de tique n'a rien à voir avec la modélisation dans le testeur.

Et tout ce que je pourrais dire pour justifier sa nécessité, je l'ai dit plus haut.

solandr,
Si les utilisateurs ne sont pas proactifs et persévérants pour expliquer leurs besoins aux développeurs, tant les utilisateurs que les développeurs en pâtiront.
Si les développeurs ne font pas preuve de patience, de compréhension, mais aussi d'une approche stratégique lors du développement de leurs produits, tant les utilisateurs que les développeurs en pâtiront.
J'espère que vous comprenez cela.
 
...et aussi, nous parlons de MT5, Renat, quand est-il prévu de le sortir ?
Sera-t-il compatible avec MQL4, ou s'agira-t-il d'une nouvelle version ?
...Sera-t-il compatible avec MQL4 ou s'agira-t-il d'une nouveauté ?
 
C'est là que vous êtes pris. Je dis spécifiquement - prouver que la modélisation intra-minute a de sérieuses divergences. ... <br / translate="no">Je soutiens que l'erreur dans la modélisation des minutes est de 1 à 2 points. Et cette marge d'erreur est parfaitement acceptable et normale.

Vous ne cessez de parler de l'aspect PRIX du marché. Ici, vous avez sans doute réussi et l'erreur dans la modélisation du PRIX est insignifiante.
Cependant, le flux de cotations a d'autres paramètres qui sont TOTALEMENT détruits par la modélisation, surtout pendant les périodes de mouvements de nouvelles.
À mon avis, vous avez besoin UNIQUEMENT de l'historique des ticks à partir duquel vous pouvez obtenir TOUTES les échéances et pas seulement les échéances, mais aussi les tickframes (dans une bougie, par exemple, 10 ticks) et les graphiques cagi et les croisements et les zéros.
C'est-à-dire que TOUTES les restrictions artificielles liées aux délais sont supprimées.
 
À mon avis, nous avons besoin UNIQUEMENT de l'historique des tics à partir duquel nous pouvons obtenir TOUTES les échéances et pas seulement les échéances, mais aussi les échelles en tic (dans une bougie, par exemple, 10 tics) et les graphiques en cage et les tic-tac-toe. <br / translate="no">C'est-à-dire que TOUTES les restrictions artificielles liées aux délais sont supprimées.



Absolument d'accord avec cela. Les développeurs doivent-ils vraiment prouver que les trames de tic-tac ont le même droit d'exister que les trames de temps ? S'il est difficile de stocker UNIQUEMENT l'historique des ticks en raison d'une grande quantité de données pour une période significative, vous pouvez au moins stocker des ticks fixes, comme c'est le cas actuellement pour les périodes. C'est mon souhait et cela n'a rien à voir avec les testeurs, les conseillers experts et autres bêtises. Je négocie sur un compte réel depuis environ un an et je ne le fais que manuellement. S'il y a une sorte de mouvement de prix, il est élémentaire de négocier avec profit, mais si le prix ne fait que dériver d'avant en arrière au même endroit, aucun conseiller expert ne sera utile. Et laisser l'ordinateur prendre la décision par lui-même - Dieu nous en préserve.
Je pense donc que les échelles en tic-tac sont un reflet beaucoup plus précis de l'évolution des prix, et je me sentirais personnellement plus à l'aise avec elles. Comment cela peut-il être difficile ?
 
Il me semble que la meilleure façon de conserver l'histoire est de la stocker dans des minutes de qualité.
Vous pouvez construire n'importe quel cadre à partir d'eux (même les délais, même les X et les Y, même
à enrouler selon d'autres critères).
Ce qui est vraiment important, c'est la régularité de l'axe des graphiques principaux de MT4,
qui sont basés sur des données collectées à intervalles de temps constants...

Mais cela peut être décidé
seulement dans la prochaine version de MT ... Alors vous pouvez voir l'image au moins une fois
dans les vagues (je n'écris pas Eliot, parce qu'il ya des vagues, mais leur structure est très discutable ...).
En général, je suis en faveur d'une histoire de base de minutes de QUALITÉ.
 
Je pense que personne ne contestera que le temps n'est pas la meilleure variable pour fixer le prix, le prix dépend plus du nombre et du volume des opérations, et le volume des tick est une fonction de ces paramètres (ou quelque chose d'approchant). C'est pourquoi, pour les chercheurs, les périodes de temps sont plus intéressantes que les périodes de temps.
En tout cas, si l'on fait une simple estimation sur ceux qui se sont exprimés dans cette branche, il y a une majorité absolue de ceux qui le voudraient.
 
Si je faisais mon propre terminal =))), je ferais ça :
Sur le serveur, je ne stocke que les ticks, et je n'autorise que leur téléchargement.
Sur le client, je créerais toutes les TimeFrames (et TickFrames) nécessaires à partir de ticks.

Ainsi, pour obtenir un graphique de n'importe quel TF pendant un an, il faudrait 35,7 Mb de trafic (calculs de Yurixx).
Maintenant, MT4 aura besoin d'environ 20,763 Mo d'historique pour toutes les TF pour la même période (15,71 + 3,142 + 1,047 + 0,524 + 0,262 + 0,065 + 0,011 + 0,002).

En résumé, les avantages de l'histoire de la tique:
- L'utilisateur décide lui-même des TF qu'il souhaite et peut toujours les construire lui-même.
Contre l'histoire de la tique :
- la quantité de trafic consommé augmente de 1,7 fois (par rapport au téléchargement de toutes les TF) ;
- elle augmente la charge du processeur (pour la construction constante des TF nécessaires).


Si je fabriquais mon propre terminal, je réfléchirais bien d'abord.....
1234567
Nouveau commentaire
Raison: