Erreurs, bugs, questions - page 257
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
Ça n'en a pas l'air.
Il s'avère qu'il n'y a eu que 2 (sur 45) transactions perdantes, toutes deux à l'achat.
Peut-être que je cherche au mauvais endroit ?
Marqué en rouge : Les positions courtes sont 5 sur 45. Supposons que 40 soit 95%. Question - Pourquoi 5 = 100%, il est logique de supposer - 5%.
Bien qu'il me semble que dans ce cas, ce devrait être 5 (11,11%) et 40 (88,89%).
Essayez de vider le cache. J'ai essayé différentes options, différents navigateurs - l'ajout a réussi.
Vous insérez une image directement dans un commentaire et non en tant qu'atach, n'est-ce pas ?
Marqué en rouge : Les positions courtes sont 5 sur 45. Disons que 40 est 95%. Question - Pourquoi 5 = 100%, il est logique de supposer 5%.
Pourtant, il me semble qu'il devrait y avoir 5 (11,11 %) et 40 (88,89 %) transactions.
Un total de 45 échanges :
Nous avons ici les résultats suivants
5 opérations de vente - 5, et 100% d'entre elles ont été rentables (sans perte) (c'est-à-dire que toutes les opérations ont été rentables).
Transactions d'achat - 40, 38 d'entre elles sont rentables, c'est-à-dire 38*100%/40=95%.
Plus d'informations sur
Affaires rentables - 43 sur 45, soit 43*100%/45 = 95,56%.
Transactions à perte - 2 sur 45, soit 2*100%/45 = 4,44%.
Un total de 45 échanges :
Le nombre total de transactions que nous avons
Ventes de contrats - 5, dont les contrats gagnants (et non perdants) - 100 % (c'est-à-dire qu'ils ont tous été rentables).
Transactions d'achat - 40, 38 d'entre elles sont rentables, c'est-à-dire 38*100%/40=95%.
Plus d'informations sur
Affaires rentables - 43 sur 45, soit 43*100%/45 = 95,56%.
Transactions à perte - 2 sur 45, soit 2*100%/45 = 4,44%.
J'ai remarqué cet effet. Lorsque l'on ajoute l'indicateur au graphique(dans une fenêtre séparée), le graphique principal en chandeliers cesse de se mettre à jour (le prix se fige), alors que dans la fenêtre avec les cotations tout est OK - le prix passe du rouge au vert. Bien que l'indicateur ait été ajouté uniquement à la fenêtre d'un symbole, le prix se fige également dans l'autre fenêtre. L'initialisation et le calcul de l'indicateur sont à l'intérieur du corps : if(prev_calculé==0). Les cours de clôture ne commençant pas le jour précédent participent au calcul (le cours de clôture actuel ne participe pas). Une fois le calcul de l'indicateur terminé, le prix commence à se déplacer et à changer de manière synchrone avec la fenêtre.
Vous pouvez le voir sur la photo :
J'ai remarqué cet effet. Lorsque l'on ajoute l'indicateur au graphique(dans une fenêtre séparée), le graphique principal en chandeliers cesse de se mettre à jour (le prix se fige), alors que dans la fenêtre avec les cotations tout est OK - le prix passe du rouge au vert. Bien que l'indicateur ait été ajouté uniquement à la fenêtre d'un symbole, le prix se fige également dans l'autre fenêtre. L'initialisation et le calcul de l'indicateur sont à l'intérieur du corps : if(prev_calculé==0). Les cours de clôture ne commençant pas le jour précédent participent au calcul (le cours de clôture actuel ne participe pas). Une fois le calcul de l'indicateur terminé, le prix commence à se déplacer et à changer de manière synchrone avec la fenêtre.
Vous pouvez le voir sur la photo :
Le premier calcul s'avère très gourmand en ressources. Vérifiez-le, peut-être que le code de l'indicateur n'est pas écrit de la manière la plus optimale.
Le premier calcul s'avère très gourmand en ressources. Vérifiez si le code de l'indicateur n'est pas écrit de la manière la plus optimale.
Je voulais dire qu'il est possible de séparer la mise à jour des cotations dans le graphique en chandelier dans un flux de programme séparé et le chargement des calculs des indicateurs dans un autre flux.
La mise à jour des cotations sur le graphique n'est qu'un affichage des données de la base de données du terminal, qui est également utilisée pour calculer les indicateurs. Pour économiser des ressources, les données de base des terminaux sont transmises à l'indicateur comme données d'entrée, c'est-à-dire qu'elles ne peuvent pas être modifiées avant le calcul de l'indicateur.
Cher alexvd, malheureusement l'Indicateur a maintenant plus de 3000 lignes de code composé d'environ plus de 20 classes et il est assez difficile d'optimiser le code (plusieurs centaines de milliards d'opérations de calcul dans les boucles), alors que ce nombre peut augmenter jusqu'à 10000 environ. Je voulais dire qu'il est possible de séparer d'une manière ou d'une autre la mise à jour des cotations dans le graphique en chandelier dans un fil de programme séparé et le chargement des calculs des indicateurs dans un fil séparé. Pour être franc, lorsque j'ai commencé mon travail, je ne m'attendais pas à ce que le problème de performances se pose de manière aussi urgente sur un ordinateur de bureau, alors que je souhaite également utiliser un petit ordinateur portable.
Essayez d'optimiser les performances de l'indicateur, le nombre d'objets et de lignes n'est pas important. Il est très probablement possible de faire fonctionner l'indicateur existant (avec 3000 lignes) avec la vitesse nécessaire.
Une variante intéressante est de mettre tous les calculs gourmands en ressources dans un timer (si cela semble possible), alors ces calculs ne seront pas effectués à chaque tick.
Et j'aimerais optimiser le boîtier de la calculatrice autant que possible (dans des limites raisonnables).
Essayez d'optimiser l'indicateur, le nombre d'objets et de lignes n'est pas important. Il est très probablement possible de faire fonctionner l'indicateur existant (avec 3000 lignes) avec la vitesse nécessaire.
Une variante intéressante consiste à placer tous les calculs gourmands en ressources dans une minuterie (si possible), afin que ces calculs ne soient pas effectués à chaque tic-tac.
Et le bloc calculateur doit être optimisé autant que possible (dans des limites raisonnables).
En principe, il est possible d'optimiser un peu le travail, car certaines données identiques sont calculées dans des objets de classes différentes, c'est-à-dire pas une seule fois. Mais nous sommes ici confrontés à un autre problème, à savoir l'abandon du concept de nombreuses boîtes noires, dont chacune peut être déboguée et faire l'objet d'une confiance totale (c'est-à-dire que chaque objet est une unité totalement autonome, et si le calcul de certaines données intermédiaires, qui sont identiques dans différents objets, est déplacé en dehors des objets, l'autonomie sera perdue, ce qui permettra de déboguer chaque classe séparément. Dans ce cas, la structuration du programme sera perdue, c'est-à-dire que je ne pourrai pas comprendre ce que j'ai écrit et que la moindre erreur sera impossible à détecter. La vitesse de débogage augmentera également de façon spectaculaire, car je devrai exécuter l'ensemble de l'algorithme au lieu d'une partie seulement. C'est ainsi que le nombre d'objets influence la vitesse.
C'est pourquoi je pense qu'une optimisation similaire peut être essayée dans la phase finale, lorsque l'indicateur est complètement créé, débogué et testé, mais malheureusement c'est encore loin (je travaille à la phase initiale depuis environ 4 mois maintenant, depuis que j'ai finalement réalisé que je suis prêt à l'essayer). Dans les livres d'économétrie et de mathématiques, tout est éparpillé en fragments dans différents livres (il n'y a pas de présentation matérielle pratiquement unifiée dans les détails), les auteurs ont des erreurs et des divergences dans les termes et les algorithmes, que les débutants ne trouvent qu'en se référant aux dictionnaires encyclopédiques, l'information théorique entre en conflit avec la possibilité de sa réalisation pratique, c'est-à-dire la réalisation sous forme de méthodes numériques, et les méthodes numériques elles-mêmes, à leur tour, posent des exigences à la fonctionnalité de l'environnement logiciel), le processus est long, fastidieux et visqueux.
Selon la logique de calcul, elle doit se produire après la formation de chaque bougie, elle devait donc à l'origine être placée dans le corps de la fonction "is new bar", mais le fait que son temps puisse dépasser cet intervalle m'a fait la placer dans le corps de la fonction if(prev_calculated==0) afin qu'elle ne se produise qu'une seule fois au stade du débogage. Je vais réfléchir à votre suggestion de minuterie - merci.