Leinwand ist cool! - Seite 89

 
Nikolai Semko #:
Der Punkt ist, dass Sie bei der Implementierung von so etwas unweigerlich auf einen katastrophalen Mangel an Schiebereglerlänge stoßen werden.
In der Regel wird dies in einem einzigen Schieberegler implementiert, nicht in einem, dessen Breite durch Ziehen der Schaltfläche an den Rändern geändert werden kann, wodurch sich der Maßstab ändert. Diese Vorgehensweise löst das Problem der Schiebereglerlänge jedoch nicht, obwohl sie bequemer ist.

ja, das ist mir auch schon begegnet ;)

einen langen Schieberegler gemacht

Das ganze Tamburintanzen war nur dazu da, um

zu sehen, wie wirklich und vor allem wovon und warum sich der Preis bewegt.

jetzt ist alles klar ;))))

natürlich ist es im Terminal schön gezeichnet, aber es ist nicht wahr!

korrekter Chart im Trailer
Dateien:
777.png  15 kb
 
Renat Akhtyamov #:

ja, bin schon darauf gestoßen ;)

machte eine lange

Das ganze Tamburin-Tanzen war nur dazu da, um

um zu sehen, wie es wirklich läuft und vor allem, was den Preis in die Höhe treibt und warum.

Nun, jetzt ist alles klar ;))))

Meiner Meinung nach ist es viel praktischer und anschaulicher, einen zweidimensionalen Schieberegler zu haben, dessen Höhenkoordinate für die Skala verantwortlich ist.
Etwa so:

In diesem Fall braucht man nur einen Mausklick mit Bewegung, um zu einem beliebigen Zeitpunkt des gesamten Verlaufs mit beliebigem Maßstab zu gelangen.

 
Nikolai Semko #:

Für mich ist ein zweidimensionaler Schieberegler mit einer Höhenkoordinate, die für die Skalierung verantwortlich ist, viel praktischer und anschaulicher.
Etwa so:

du hast einen sehr coolen ;)

 
Renat Akhtyamov #:

du hast ein wirklich cooles Ding ;)

Danke,
Ich möchte ein vollwertiges auf WebAssembly (auf Rust) zu machen.

 
Nikolai Semko #:

Danke,
Ich möchte eine vollwertige Version davon auf WebAssembley (auf Rust) machen.

Ja, genau.

Die Hauptsache ist, dass man nichts umstellen muss.

Der minimale Zeitrahmen ist skaliert.

und ich bin verwirrt - wie kommt es, dass die Signale auf verschiedenen Zeitrahmen zum gleichen Preis unterschiedlich sind?

Wer geht in den Wald, wer geht in den Wald....

Timeframes sind im Grunde genommen nicht einmal notwendig.

Ticks werden benötigt und das ist alles

 
Renat Akhtyamov #:

Ja

Sie müssen nichts umstellen.

der Mindestzeitrahmen ist skaliert.

und ich bin verwirrt - wie kommt es, dass die Signale auf verschiedenen Zeitrahmen zum gleichen Preis unterschiedlich sind?

Wer geht in den Wald, wer geht in den Wald....

Zeitrahmen sind im Grunde genommen nicht einmal notwendig.

Man braucht Ticks, das ist alles.

Ja, das derzeitige Modell der Timeframes ist sehr unpraktisch. Jeder Balken des Senior TF enthält eine unterschiedliche Anzahl von Minutenbalken. Bei dieser Struktur stimmen die Charts nicht überein, wenn der Senior-TF nahtlos auf den Junior-TF reduziert wird.
Ich habe für mich eine akzeptable Lösung gefunden.
Aus M1 bilde ich die folgenden Index-TFs M2, M4, M8, M16, M32, M64, M128, M256, M1024, M2048, M4096, M8192.
In diesem Fall ist gewährleistet, dass jeder Balken eines beliebigen Zeitrahmens die gleiche Anzahl von M1 enthält.
Alle TFs sind gleich skaliert und eine sehr einfache TF-Neuberechnung erfolgt buchstäblich in einer einzigen mathematischen Aktion. Und es gibt noch viele weitere Vorteile.
Die Tatsache, dass jeder Balken einer übergeordneten TF eine unterschiedliche Zeitdichte haben kann, stört mich nicht, denn es ist nicht die Zeitdichte, die wichtiger ist, sondern die Handelsdichte.
Es ist durchaus akzeptabel, die Anzahl der Minutenbalken zur Messung der Handelsdichte zu verwenden.
Wir können noch weiter gehen und Ticks zur Messung der Handelsdichte verwenden.
 
Nikolai Semko #:
Ja, das derzeitige Zeitrahmenmodell ist sehr unpraktisch. Jeder Balken des Senior TF enthält eine unterschiedliche Anzahl von Minutenbalken. Bei einer solchen Struktur stimmen die Diagramme nicht überein, wenn der Senior-TF reibungslos auf den Junior-TF reduziert wird.
Ich habe für mich eine akzeptable Lösung gefunden.
Aus M1 bilde ich die folgenden Index-TFs M2, M4, M8, M16, M32, M64, M128, M256, M1024, M2048, M4096, M8192.
In diesem Fall ist gewährleistet, dass jeder Balken eines beliebigen Zeitrahmens die gleiche Menge an M1 enthält.
Alle TFs sind gleich skaliert und eine sehr einfache TF-Neuberechnung erfolgt buchstäblich in einer einzigen mathematischen Aktion. Und eine Menge anderer Vorteile.
Die Tatsache, dass jeder Balken eines älteren TFs eine unterschiedliche Zeitdichte haben kann, stört mich nicht, denn es ist nicht die Zeitdichte, die wichtiger ist, sondern die Handelsdichte.
Es ist durchaus akzeptabel, die Anzahl der Minutenbalken zur Messung der Handelsdichte zu verwenden.
Wir können noch weiter gehen und Ticks zur Messung der Handelsdichte verwenden.

Ich bin nicht ganz richtig

nicht skaliert, sondern komprimiert.

Die TFs verschwinden.
 
Renat Akhtyamov #:

Ich war nicht ganz richtig

nicht skaliert, sondern komprimiert.

TFmas verschwinden
Da ich nur M1 verwende, gibt es dieses Problem bei mir nicht.
Höchstwahrscheinlich handelt es sich um ein Problem der Synchronisation der Relevanz der Bildung von Arrays älterer TFs, da MQ sie alle auch aus M1 gebildet (berechnet) hat.
Oder Ihr Fehler
 

Helfen Sie mir, das Konzept einer grafischen Ressource zu verstehen und wie es sich von dem Konzept eines grafischen Objekts in einem Diagramm unterscheidet.

Wenn ich zum Beispiel ein grafisches Objekt, das mit Canvas erstellt wurde, mit der Funktion ObjectDelete() lösche, und dann in einer Schleife immer wieder Canvas-Objekte mit unterschiedlichen Namen, aber mit derselben Instanz der Canvas-Klasse erstelle... und dann wieder grafische Objekte mit ObjectDelete() löschen. Besteht hier überhaupt eine Gefahr?

Ich verstehe den Unterschied zwischen ObjectDelete() und C.Destroy() noch nicht ganz, aber ich würde es gerne verstehen....

 
leon_17 ich zum Beispiel ein grafisches Objekt, das mit Canvas erstellt wurde, mit der Funktion ObjectDelete() lösche, und dann in einer Schleife immer wieder Canvas-Objekte mit unterschiedlichen Namen, aber mit derselben Instanz der Canvas-Klasse erstelle... und wieder mit ObjectDelete() grafische Objekte löschen. Ist das überhaupt mit etwas verbunden?

Ich verstehe nur den Unterschied zwischen ObjectDelete() und C.Destroy() noch nicht ganz, aber ich würde es gerne verstehen....

Canvas ist ein Objekt, an das ein Array von Pixeln gebunden ist. Die Ressource ist für die Bindung dieses Arrays von Pixeln verantwortlich (siehe die bool-Funktion CCanvas::Create())
Es ist eine schlechte Praxis, eine Leinwand ständig zu löschen und neu zu erstellen.
Es ist eine gute Praxis, eine Leinwand zu erstellen, wenn man sie braucht, und sie zu löschen, wenn man sie nicht mehr braucht, zum Beispiel am Ende des Programms.

Sobald Sie ein Canvas-Objekt erstellt haben, können Sie es aufräumen, das Pixel-Array bei jedem Bild überschreiben, die Größe der Leinwand ändern und sie an einen beliebigen Ort verschieben.

Grund der Beschwerde: