Nikolai Semko #: Il punto è che quando si implementa una cosa del genere, è inevitabile che si verifichi una catastrofica mancanza di lunghezza del cursore.
Di norma, questo viene implementato in un singolo cursore e non in uno solo, la cui larghezza può essere modificata trascinando il pulsante dai suoi bordi, cambiando così la scala. Ma questo approccio non risolve il problema della lunghezza del cursore, anche se è più comodo.
Sì, l'ho già incontrato ;)
ne ho fatto uno lungo
Tutto questo ballare il tamburello era solo allo scopo di
vedere come realmente e soprattutto da cosa e perché si muove il prezzo.
ora è tutto chiaro ;))))
naturalmente è splendidamente disegnato nel terminale, ma non è vero!
Tutto questo ballare il tamburello era solo allo scopo di
vedere come va veramente e, soprattutto, cosa fa andare il prezzo e perché.
Beh, ora è tutto chiaro ;))))
A mio parere, è molto più comodo e visivo avere un cursore bidimensionale, la cui coordinata di altezza è responsabile della scala. Qualcosa del genere:
in questo caso basta un solo clic del mouse con movimento per arrivare a qualsiasi momento dell'intera storia con qualsiasi scala.
Per quanto mi riguarda, un cursore bidimensionale con una coordinata di altezza responsabile della scala è molto più comodo e visivo. Qualcosa del genere:
E sono perplesso: come mai i segnali sono diversi su diversi timeframe allo stesso prezzo?
chi va nella foresta, chi va nel bosco....
i timeframe non sono nemmeno necessari in sostanza.
Servono i ticchettii, tutto qui.
Sì, il modello attuale dei timeframe è molto scomodo. Ogni barra del TF senior contiene un numero diverso di barre di minuti. Con questa struttura, se il TF senior si riduce dolcemente a quello junior, i grafici non coincideranno.
Ho trovato una soluzione accettabile per me stesso.
A partire da M1 formano i seguenti TF indice M2, M4, M8, M16, M32, M64, M128, M256, M1024, M2048 , M4096, M8192.
In questo caso, ogni barra di qualsiasi timeframe è garantita per contenere lo stesso numero di M1.
Tutti i TF sono scalati allo stesso modo e il ricalcolo dei TF è molto semplice, letteralmente in un'unica azione matematica. E ci sono molti altri vantaggi.
Il fatto che ogni barra di un TF senior possa avere una densità temporale diversa non mi preoccupa, perché non è la densità temporale a essere più importante, ma la densità di trading.
È abbastanza accettabile utilizzare il numero di barre al minuto per misurare la densità di trading.
Possiamo andare oltre e utilizzare i tick per misurare la densità di trading.
Nikolai Semko #: Sì, l'attuale modello di timeframe è molto scomodo. Ogni barra del TF senior contiene un numero diverso di barre dei minuti. Con una struttura di questo tipo, se il TF senior viene ridotto senza problemi a quello junior, i grafici non coincideranno.
Ho trovato una soluzione accettabile per me stesso.
A partire da M1 ho formato i seguenti TF indice M2, M4, M8, M16, M32, M64, M128, M256, M1024, M2048 , M4096, M8192.
In questo caso, ogni barra di qualsiasi timeframe è garantita per contenere la stessa quantità di M1.
Tutti i TF sono scalati allo stesso modo e il ricalcolo dei TF è molto semplice, letteralmente in un'unica azione matematica. E molti altri vantaggi.
Il fatto che ogni barra di un TF senior possa avere una densità temporale diversa non mi preoccupa, perché non è la densità temporale a essere più importante, ma la densità di trading.
È abbastanza accettabile utilizzare il numero di barre al minuto per misurare la densità di trading.
Possiamo andare oltre e utilizzare i tick per misurare la densità di trading.
Poiché uso solo M1, questo problema non esiste per me.
Molto probabilmente si tratta di un problema di sincronizzazione della rilevanza della formazione degli array di TF senior, perché MQ li ha tutti formati (calcolati) anche da M1.
Aiutatemi a capire il concetto di risorsa grafica e come si differenzia dal concetto di oggetto grafico in un grafico.
Per esempio, se cancello un oggetto grafico creato con Canvas usando la funzione ObjectDelete(), e poi in un ciclo creo oggetti Canvas con nomi diversi ancora e ancora, ma usando la stessa istanza della classe Canvas... e cancellare nuovamente gli oggetti grafici usando ObjectDelete(). C'è qualche pericolo in tutto questo?
Non ho ancora capito bene la differenza tra ObjectDelete() e C.Destroy(), ma mi piacerebbe capirla....
leon_17 cancello un oggetto grafico creato con Canvas usando la funzione ObjectDelete(), e poi in un ciclo creo oggetti Canvas con nomi diversi ancora e ancora, ma usando la stessa istanza della classe Canvas... e di nuovo cancellerò gli oggetti grafici usando ObjectDelete(). C'è qualcosa che non va?
Non ho ancora capito bene la differenza tra ObjectDelete() e C.Destroy(), ma mi piacerebbe capirla....
Canvas è un oggetto a cui è legato un array di pixel. La risorsa è responsabile del legame di questo array di pixel (si veda la funzione bool CCanvas::Create()) È una cattiva pratica cancellare e ricreare una tela in continuazione. È una buona pratica creare una tela quando se ne ha bisogno e cancellarla quando non serve più, per esempio alla fine del programma.
Una volta creato un oggetto canvas, è possibile ripulirlo, sovrascrivere l'array di pixel a ogni fotogramma, ridimensionare il canvas e spostarlo dove si vuole.
Il punto è che quando si implementa una cosa del genere, è inevitabile che si verifichi una catastrofica mancanza di lunghezza del cursore.
Sì, l'ho già incontrato ;)
ne ho fatto uno lungo
Tutto questo ballare il tamburello era solo allo scopo di
vedere come realmente e soprattutto da cosa e perché si muove il prezzo.
ora è tutto chiaro ;))))
naturalmente è splendidamente disegnato nel terminale, ma non è vero!
grafico corretto nel trailerGià, mi ci sono imbattuto ;)
ha fatto un lungo
Tutto questo ballare il tamburello era solo allo scopo di
vedere come va veramente e, soprattutto, cosa fa andare il prezzo e perché.
Beh, ora è tutto chiaro ;))))
A mio parere, è molto più comodo e visivo avere un cursore bidimensionale, la cui coordinata di altezza è responsabile della scala.

Qualcosa del genere:
in questo caso basta un solo clic del mouse con movimento per arrivare a qualsiasi momento dell'intera storia con qualsiasi scala.
Per quanto mi riguarda, un cursore bidimensionale con una coordinata di altezza responsabile della scala è molto più comodo e visivo.
Qualcosa del genere:
ne hai uno molto bello ;)
ne hai uno davvero bello ;)
Grazie,
Voglio farne uno completo su WebAssembly (su Rust).
Grazie,
Voglio farne uno completo su WebAssembley (su Rust).
Sì.
La cosa principale è che non devi cambiare nulla.
Il tempo minimo è scalato.
E sono perplesso: com'è possibile che i segnali siano diversi su diversi timeframe allo stesso prezzo?
Chi va nel bosco, chi va nel bosco....
I timeframe non sono nemmeno necessari in sostanza.
Sono necessari i tick e basta
Sì
Non è necessario cambiare nulla.
il tempo minimo è scalato.
E sono perplesso: come mai i segnali sono diversi su diversi timeframe allo stesso prezzo?
chi va nella foresta, chi va nel bosco....
i timeframe non sono nemmeno necessari in sostanza.
Servono i ticchettii, tutto qui.
Sì, l'attuale modello di timeframe è molto scomodo. Ogni barra del TF senior contiene un numero diverso di barre dei minuti. Con una struttura di questo tipo, se il TF senior viene ridotto senza problemi a quello junior, i grafici non coincideranno.
Non ho capito bene
non scalato, ma compresso.
I TF scompaiono.Non ero del tutto a posto
non scalato, ma compresso.
I TFmas scompaionoAiutatemi a capire il concetto di risorsa grafica e come si differenzia dal concetto di oggetto grafico in un grafico.
Per esempio, se cancello un oggetto grafico creato con Canvas usando la funzione ObjectDelete(), e poi in un ciclo creo oggetti Canvas con nomi diversi ancora e ancora, ma usando la stessa istanza della classe Canvas... e cancellare nuovamente gli oggetti grafici usando ObjectDelete(). C'è qualche pericolo in tutto questo?
Non ho ancora capito bene la differenza tra ObjectDelete() e C.Destroy(), ma mi piacerebbe capirla....
Non ho ancora capito bene la differenza tra ObjectDelete() e C.Destroy(), ma mi piacerebbe capirla....
Canvas è un oggetto a cui è legato un array di pixel. La risorsa è responsabile del legame di questo array di pixel (si veda la funzione bool CCanvas::Create())
È una cattiva pratica cancellare e ricreare una tela in continuazione.
È una buona pratica creare una tela quando se ne ha bisogno e cancellarla quando non serve più, per esempio alla fine del programma.
Una volta creato un oggetto canvas, è possibile ripulirlo, sovrascrivere l'array di pixel a ogni fotogramma, ridimensionare il canvas e spostarlo dove si vuole.