La toile est cool ! - page 89

 
Nikolai Semko #:
Le fait est que lorsque vous mettez en œuvre quelque chose comme cela, vous rencontrerez inévitablement un manque catastrophique de longueur du curseur.
En règle générale, on utilise un seul curseur, et non un seul, dont la largeur peut être modifiée en faisant glisser le bouton par ses bords, ce qui change l'échelle. Mais cette approche ne résout pas le problème de la longueur du curseur, bien qu'elle soit plus pratique.

oui, je l'ai déjà rencontré ;)

j'en ai fait un long

Toute cette danse du tambourin était juste dans le but de

de voir comment et surtout à partir de quoi et pourquoi le prix bouge.

tout est clair maintenant ;))))

bien sûr, c'est magnifiquement dessiné dans le terminal, mais ce n'est pas vrai !

graphique correct dans la bande-annonce
Dossiers :
777.png  15 kb
 
Renat Akhtyamov #:

oui, je suis déjà tombé dessus ;)

a fait un long

Toute cette danse du tambourin était juste dans le but de

de voir comment cela se passe vraiment et, surtout, ce qui fait bouger le prix et pourquoi.

Eh bien, tout est clair maintenant ;))))

à mon avis, il est beaucoup plus pratique et visuel d'avoir un curseur bidimensionnel, dont la coordonnée de hauteur est responsable de l'échelle.
Quelque chose comme ça :

dans ce cas, il suffit d'un clic de souris et d'un mouvement pour accéder à n'importe quel moment de l'histoire, quelle que soit l'échelle.

 
Nikolai Semko #:

En ce qui me concerne, un curseur bidimensionnel avec une coordonnée de hauteur responsable de l'échelle est beaucoup plus pratique et visuel.
Quelque chose comme ça :

vous en avez un très cool ;)

 
Renat Akhtyamov #:

tu en as une vraiment cool ;)

Merci,
Je veux en faire un sur WebAssembly (sur Rust).

 
Nikolai Semko #:

Merci,
J'ai l'intention d'en faire un véritable sur WebAssembley (sur Rust).

Oui, c'est vrai.

L'essentiel est que vous n'ayez pas à changer quoi que ce soit.

Le délai minimum est réduit.

et je suis perplexe - comment se fait-il que les signaux soient différents sur différentes échéances au même prix ?

Qui va dans les bois, qui va dans les bois....

Les échéances ne sont même pas nécessaires par essence.

Les ticks sont nécessaires et c'est tout

 
Renat Akhtyamov #:

Oui, c'est vrai

Vous n'avez pas besoin de changer quoi que ce soit.

le délai minimum est échelonné.

et je suis perplexe - comment se fait-il que les signaux soient différents sur des périodes différentes pour le même prix ?

qui va dans la forêt, qui va dans le bois....

les délais ne sont même pas nécessaires par essence.

Il faut des tics, c'est tout.

Oui, le modèle actuel des timeframes est très peu pratique. Chaque barre de la TF senior contient un nombre différent de barres de minutes. Avec cette structure, si la TF senior est réduite en douceur à la TF junior, les graphiques ne coïncideront pas.
J'ai trouvé une solution acceptable pour moi.
À partir de M1, je forme les TF index suivants : M2, M4, M8, M16, M32, M64, M128, M256, M1024, M2048, M4096, M8192.
Dans ce cas, chaque barre de n'importe quelle période de temps est garantie de contenir le même nombre de M1.
Toutes les TF sont mises à l'échelle de la même manière et il est très facile de recalculer les TF littéralement en une seule action mathématique. Et il y a bien d'autres avantages.
Le fait que chaque barre d'une TF senior puisse avoir une densité de temps différente ne me dérange pas, car ce n'est pas la densité de temps qui est la plus importante, mais la densité de trading.
Il est tout à fait acceptable d'utiliser le nombre de barres de minutes pour mesurer la densité des transactions.
Nous pouvons aller plus loin et utiliser les ticks pour mesurer la densité des transactions.
 
Nikolai Semko #:
Oui, le modèle actuel est très peu pratique. Chaque barre de la TF senior contient un nombre différent de barres de minutes. Avec une telle structure, si la TF senior est réduite en douceur à la TF junior, les graphiques ne coïncideront pas.
J'ai trouvé une solution acceptable pour moi.
A partir de M1, je forme les index M2, M4, M8, M16, M32, M64, M128, M256, M1024, M2048, M4096, M8192.
Dans ce cas, chaque barre de n'importe quelle période de temps est garantie de contenir la même quantité de M1.
Toutes les TF sont mises à l'échelle de la même manière et il est très facile de recalculer les TF littéralement en une seule action mathématique. Et bien d'autres avantages.
Le fait que chaque barre d'une TF senior puisse avoir une densité de temps différente ne me dérange pas, car ce n'est pas la densité de temps qui est la plus importante, mais la densité de trading.
Il est tout à fait acceptable d'utiliser le nombre de barres de minutes pour mesurer la densité de négociation.
Nous pouvons aller plus loin et utiliser les ticks pour mesurer la densité des transactions.

Je n'ai pas tout à fait raison

pas mis à l'échelle, mais compressé.

Les TF disparaissent.
 
Renat Akhtyamov #:

Je n'étais pas tout à fait d'accord

pas mis à l'échelle, mais compressé.

Les TFmas disparaissent
Comme je n'utilise que M1, ce problème ne se pose pas pour moi.
Il s'agit probablement d'un problème de synchronisation de la pertinence de la formation des tableaux de TF seniors, car MQ les a tous formés (calculés) à partir de M1 également.
Ou votre erreur
 

Aidez-moi à comprendre le concept de ressource graphique et en quoi il diffère du concept d'objet graphique dans un graphe.

Par exemple, si je supprime un objet graphique créé avec Canvas à l'aide de la fonction ObjectDelete(), et qu'ensuite, dans une boucle, je crée des objets Canvas avec des noms différents, mais en utilisant la même instance de la classe Canvas... et je supprime à nouveau les objets graphiques à l'aide de la fonction ObjectDelete(). Y a-t-il un danger à cela ?

Je ne comprends pas encore très bien la différence entre ObjectDelete() et C.Destroy(), mais j'aimerais bien comprendre....

 
leon_17 je supprime un objet graphique créé avec Canvas à l'aide de la fonction ObjectDelete(), et qu'ensuite, dans une boucle, je crée des objets Canvas avec des noms différents, mais en utilisant la même instance de la classe Canvas... et je supprime à nouveau des objets graphiques à l'aide de la fonction ObjectDelete(). Y a-t-il quelque chose à redouter ?

Je ne comprends pas encore très bien la différence entre ObjectDelete() et C.Destroy(), mais j'aimerais bien comprendre....

Canvas est un objet auquel est lié un tableau de pixels. La ressource est responsable de la liaison de ce tableau de pixels (voir la fonction bool CCanvas::Create())
C'est une mauvaise pratique de supprimer et de recréer un canevas tout le temps.
C'est une bonne pratique de créer un canevas quand vous en avez besoin et de le supprimer quand vous n'en avez plus besoin, par exemple, à la fin du programme.

Une fois que vous avez créé un objet canevas, vous pouvez le nettoyer, écraser le tableau de pixels à chaque image, redimensionner le canevas et le déplacer où vous voulez.

Raison: