Erreurs, bugs, questions - page 673
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
Renat, zéro - merci beaucoup pour votre attention au sujet et votre réponse constructive !
Suivant.
1. à propos de x64
Renat:
L'option la plus correcte est de passer à la version x64.
...
Bien sûr, si quelqu'un va appeler des centaines d'indicateurs en mode d'analyse du marché sans les décharger, il devrait passer directement à la version 64 bits + installer de la mémoire supplémentaire.
C'est étrange de faire des tests massifs en restant sur x32 en ce moment. Tout ordinateur x64 décent doté de 16 Go de mémoire (sans cartes graphiques ni fanatisme des écrans) peut être acheté pour 15 000 roubles.
Passer à x64 est en tout cas la bonne solution. Mais. L'un n'exclut pas l'autre. Même mes 16gigs (je les ai), je ne veux pas les gaspiller pour des données inutiles. J'ai d'autres choses à travailler en parallèle - MSVS, Matlab, etc., sur lesquelles je veux aussi calculer des tâches volumineuses. Je suis heureux que vous compreniez cela et que vous soyez prêt à chercher des moyens d'économiser de l'argent.
2. sur un début fixe de l'histoire :
Renat:
Nous voulons nous-mêmes réduire la consommation de ressources. Peut-être que la solution pourrait être une fonction IndicatorMaxDepth(uint len), qui n'agira que sur les indicateurs créés dans cet EA.
Mais le problème est qu'au cours des tests, les tampons des indicateurs en mode accumulation vont croître en même temps que l'historique et il n'y aura pas de sauvegarde.
Tout à fait (presque) d'accord. Clause de non-responsabilité : Dans de nombreux cas, l'optimisation est effectuée sur un petit morceau de la dernière histoire. Dans ce cas, les économies peuvent être très importantes. Pourtant, je considère que l'option est relativement fonctionnelle - surtout si vous avez un bon travail ou des estimations sur la mise en œuvre. Pour moi, par exemple, l'option ne me semble pas tout à fait complète - beaucoup de travail, et le résultat n'est pas radical. Une demi-solution.
3. Voici le yaz ! :
Renat:
Ledécoupage de l 'historique de l'indicateur en rltime, tout en maintenant la profondeur définie , est truffé de beaux pépins et mettra directement hors d'état de nu ire les programmeurs qui calculent/se sont habitués au synchronisme des barres du graphique et du tampon de l'indicateur.
Non ! Il n'y a pas de problème si les barres du graphique se comportent de la même manière, c'est-à-dire de manière synchrone. En d'autres termes, si les tampons en anneau (même s'ils sont de tailles différentes) toujours utiliser (de force) le drapeau AsSeries - aucun problème massif n'est attendu pour l'utilisateur.
// Dans ce cas, il serait pratique de faire en sorte que tous les tampons d'historique présentés à l'utilisateur soient des indicateurs (c'est-à-dire circulaires, avec AsSeries=true).
Dans cette variante :
(1) il existe une représentation interne des tableaux d'indicateurs et de prix (de votre côté) : indexation de gauche à droite (AsSeries==false), les tailles ne concernent pas l'utilisateur, et de fait"l'entrée est interdite".
Et (2) il y a un côté utilisateur - tous les tampons sont circulaires (dans l'implémentation, l'utilisateur voit un tableau linéaire virtuel), l'indexation se fait de droite à gauche (AsSeries==true) et la taille est fixée par l'utilisateur.
Quel est le toit de l'utilisateur ici ? Aucun. Lorsqu'il est hors de portée - réponse standard Array hors de portée.
Il n'y a que vous qui avez des difficultés (pas petites, pour être honnête). Mais ! Vu l'universalité du dispositif - vous ne devez faire des efforts qu'une seule fois. Et pour tuer dans l'œuf tous les "jolis pépins", au moment du débogage bêta. Après cela - bonheur universel et construction très économique .
Nous allons procéder à la révision du cache indicateur, qui utilise désormais le principe d'efficacité maximale contre le principe d'économie de mémoire. Nous essaierons de décharger immédiatement les indicateurs qui ont été rejetés, au lieu de les garder en mémoire pendant un certain temps, comme c'est le cas actuellement. Cela permettra d'appeler des centaines d'indicateurs à la suite avec un déchargement direct via IndicatorRelease.
3. Voilà le yazel ! :
Non ! Il ne le fera pas - si les barres du graphique se comportent de la même manière - de manière synchrone. En d'autres termes, si des tampons en anneau (même s'ils sont de taille différente) toujours utiliser (de force) le drapeau AsSeries - des problèmes massifs ne sont pas attendus pour l'utilisateur.
// Dans ce cas, il serait pratique de rendre tous les tampons historiques fournis à l'utilisateur - indicatifs (c'est-à-dire circulaires, avec AsSeries=true).
Dans cette variante :
(1) il existe une représentation interne des tableaux d'indicateurs et de prix (de votre côté) : indexation de gauche à droite (AsSeries==false), les tailles ne concernent pas l'utilisateur, et de fait"l'entrée est interdite".
Et (2) il y a un côté utilisateur - tous les tampons sont circulaires (dans l'implémentation. l'utilisateur voit un tableau linéaire virtuel), l'indexation est de droite à gauche (AsSeries==true) et la taille est fixée par l'utilisateur.
Quel est le toit de l'utilisateur ici ? Aucun. Lorsque l'utilisateur est hors de portée - réaction standard Array hors de portée.
Il n'y a que vous qui avez des difficultés (pas petites, pour être honnête). Mais ! Vu l'universalité du dispositif - vous ne devez vous fatiguer qu'une seule fois. Et tous les "petits défauts" doivent être étouffés dans l'œuf pendant le débogage de la version bêta. Après cela, tout le monde est content et la construction est très économique .
Bonne idée, je suis d'accord. Mais cela n'annule pas la mise en œuvre du schéma d'anneau, cela le complète simplement de manière agréable.Permettez-moi de décrire les conditions du test :
En raison de la sous-cotation automatique de l'indicateur, nous
Je vais décrire les conditions du test :
En raison de la sous-cotation automatique de l'indicateur nous :
1.
Oui, c'est tolérable. Cela ne provoquera guère de mécontentement de masse, au contraire, l'économie sera très attractive. Personne n'interdit de gaspiller la mémoire en installant une énorme MaxBar.
// Mais les indicateurs sont défaillants en raison du saut de barres ! C'est là que le mécontentement est justifié !
// Donc tu tolères même ça... :) Eh bien, nous devons... :(
2.
Eh bien, non et non ! Le système circulaire est exactement ce qui permet de réaliser d'énormes économies sur la copie des équipes d'histoire. En fait, lorsqu'on décale d'une barre (N barres), on doit copier exactement une valeur (N valeurs). Les coûts(pour l'utilisateur) de la virtualisation de l'index sont négligeables. En fait, ils sont même difficiles à détecter dans les tests de stress(le reste de la division est calculé par le processeur pendant un cycle d'horloge + le décalage du début de la mémoire tampon virtuelle à chaque déplacement dans l'histoire prend quelques cycles d'horloge supplémentaires). Il n'y a donc pratiquement aucune perte de vitesse. Il est impossible de détecter ce ralentissement, il est si petit. Et dans le contexte d'une énorme économie de mémoire, ces pertes sont incommensurables avec le gain.
3.
Ehhh, un visage...
Pour une raison quelconque, il y a tant de danse et de cris à propos des indicateurs qui s'étouffent sur les barres illimitées, mais pas un mot sur les objets graphiques qui dansent. Essayez de construire, par exemple, un super gros Pitchfork d'Andrews sur Unlimited (sur MN1, par exemple), puis limitez le nombre de barres dans les paramètres du terminal, passez à des timeframes bas et revenez aux points d'ancrage. Certains d'entre eux auront un retard considérable par rapport aux extrema (alors que les fourches des trois points se trouvent exclusivement dans la zone des vraies barres M1, sans dépasser la limite des fausses barres provenant d'horizons temporels plus élevés). Et pourquoi ça ? Apparemment, parce que nous ne disposions pas de suffisamment de données historiques sur M1 pour calculer la valeur M1 exacte de certains points d'autolimitation. Mais qu'est-ce que les données historiques ont à voir avec cela ? Ils étaient peut-être suffisants, mais les barres affichées dans la vitrine ne l'étaient pas, d'où les décalages. C'est-à-dire que certains points "ne savent pas vraiment où ils se trouvent".
J'aimerais que quelqu'un vérifie par lui-même, ou peut-être suis-je le seul à avoir un tel gâchis...
J'ai remarqué une bizarrerie !
Au moment de la formation d'une nouvelle barre, si vous lisez les valeurs d'ouverture et de fermeture des barres précédentes (par exemple 10 barres précédentes) et que vous les obtenez à nouveau 5 secondes plus tard, certaines de ces valeurs sont différentes. Si vous les obtenez alors qu'une nouvelle barre est en train de se former, tout va bien, mais dans les premières secondes, pour une raison quelconque, ces valeurs sont différentes.
J'espère l'avoir expliqué clairement.
Pouvez-vous me dire si avant de lire les valeurs des barres d'ouverture et de fermeture du début d'une nouvelle barre, il doit y avoir un délai de plus de 5 secondes ?
Voici un exemple de fonctionnement :
En haut, le déclenchement est correct après un délai, en bas, immédiatement après une nouvelle barre avec une erreur, et à droite, le repère pour la 6ème ligne.
Le problème est peut-être non synchronisé, une nouvelle barre doit de préférence être suivie par tous les outils utilisés.
Oui, vous aviez raison, merci !
De même, l'opéra.