Errori, bug, domande - pagina 681

[x572intraday]

Renat:
Non sembra che tu stia pensando chiaramente.

Avete paura di spendere il vostro tempo nel calcolo delle caratteristiche aggiuntive delle barre per casi molto rari (vicini allo zero %), ma pretendete allegramente che siamo noi a preparare un sacco di dati nei casi del 100%, rallentando e consumando memoria molte volte.

Alcune persone danno metodicamente dei consigli così belli da uccidersi contro il muro che è il momento di parlare di parassiti.

Gli strateghi di questo tipo sono immediatamente visibili.

Se analizzate attentamente tutti i miei post su questo e diversi precedenti, e poi giocate con l'indicatore multitemporale della marcatura grafica TA sui frattali, non vorrete più discutere con me su questo argomento, come dopo un secchio d'acqua ghiacciata. Ma il problema è che l'indicatore non è completamente ottimizzato (non riguarda questo argomento) e non è funzionalmente completo. Ecco perché spreco le mie risorse in sciocchezze, non per completarle e rilasciarle.

Ci sono molti oggetti grafici. E devi ancora pulirli... Ci sono abbastanza problemi.

[Renat Fatkhullin]

Questo è un caso particolare.

[x572intraday]

Renat:
Questo è un caso particolare.

L'autotracciamento dal vivo è voluto da poco meno di tutti coloro che fanno trading con le mani. Chi scrive MTS/ATS su oscillatori, slider e simili, lo lasci fare. Io userei questo indicatore per l'autotrading "da quella linea là", ma MQL non può vedere nessuna linea da solo. Allora potete dire addio alle risorse a tutti, anche 16 GiG vi sembreranno una beffa.

[Andrey F. Zelinsky]

Yedelkin:

Ho la sensazione che ci sarà una votazione :)

O uccidere qualcuno contro il muro :)

[x572intraday]

Tutto era un tempo privato, la prima idea nella mente dell'inventore-pioniere si annidava anche in lui solo come qualcosa di privato. Poi è diventato popolare e si è diffuso... ed è persino diventato incorporato di default come strumento di sistema. Familiare, vero?

Altrimenti, niente si sarebbe mai sviluppato in qualcosa...

[[Eliminato]]

abolk:
O uccidere qualcuno contro il muro :)

Questo è il risultato più probabile.

E ho la sensazione che la mia domanda non avrà mai una risposta e dovrò scrivere al BOD... :(

[Renat Fatkhullin]

MetaDriver:

2. L'ho visto. Quindi? Un sacco di barre mancanti? Non mi faccio illusioni neanche su questo. Ho una domanda. Per niente originale e per niente "esclusivamente privato". Vale a dire: la modalità di accesso (e visualizzazione!) alle quotazioni (comprese, sì, sì!, quelle a bassa liquidità) supportata automaticamente (!!) dal produttore del terminale, in cui tutti i buchi intra-sessione nelle quotazioni sono riempiti con schivate con i parametri {Volume=0, Open=High=Low=Close=[prezzo di chiusura della barra precedente]}. Pensi che questa modalità sia richiesta? O sono un grande originale? Sii onesto, Renat. Mettere la mano destra sul cuore sinistro.

La mia esperienza indica chiaramente che riempire gli spazi vuoti è un'assurdità e un'auto-illusione, che si disfa immediatamente una volta che si è riempita la storia.

Questo problema è stato sollevato molte volte negli ultimi 10 anni.

[Renat Fatkhullin]

x100intraday:
L'autoplotting dal vivo è voluto da un po' meno di tutti quelli che scambiano mani. Chi scrive MTS/ATS su oscillatori, slider e simili - lasciateglielo fare, io userei questo indicatore per l'autotrading "da quella linea laggiù", ma MQL stesso non vede nessuna linea, quindi devo andare in planimetria, cercare le radici dell'ipotenusa, riempire la matrice quadrata di Gann Scale e applicare un EA a quell'indicatore. Allora potete dire addio alle risorse a tutti. 16 giga saranno una beffa qui.

Cioè, volete spostare su di noi il pesante precalcolo di stati per la vostra soluzione, pensando che ne derivi la felicità.

Cioè, non apprezzate nemmeno le conseguenze del fatto che come risultato rovineremo le prestazioni del terminale il 100% del tempo e sprecheremo molta più memoria. Questo è il consiglio malizioso.

Se state sviluppando una soluzione complessa, usate metodi algoritmici per ridurre la quantità di calcoli in ogni caso , piuttosto che cercare di risolvere il problema direttamente. Utilizzare la preparazione in background delle cache con i dati necessari.

[x572intraday]

Renat:

Cioè, volete spostare su di noi il pesante pre-calcolo di stati per la vostra soluzione, pensando che ne deriverà la felicità.

Cioè, non apprezzate nemmeno le conseguenze del fatto che come risultato rovineremo le prestazioni del terminale il 100% del tempo e sprecheremo molta più memoria. Questo è un consiglio malizioso.

Se create una soluzione complessa, usate metodi algoritmici per ridurre la quantità di calcoli in ogni caso particolare , piuttosto che cercare di risolvere il problema di petto. Utilizzare la preparazione in background delle cache con i dati necessari.

Le cache dovrebbero essere situate su disco, ovviamente, e non da qualche parte... nella RAM? Intendi operazioni di lettura/scrittura di file? Ma, in primo luogo, non è più conveniente che ammassare valori exact_times[] nel database a spese del terminale. Un buon ambiente di sviluppo dovrebbe fornire a tutti i suoi utenti strumenti pronti all'uso, che ogni utente può inventare da solo, ma sforzare ogni utente con lo stesso compito in isolamento è spietato. Si tratta di specificità. Non esiste una cosa speciale e non puoi aspettartela, è un'illusione. Io stesso sono nel forum piuttosto per i suggerimenti e per portare nuove idee, e poi solo per fare domande sulle caratteristiche già costruite (si può studiare l'aiuto se si vuole). E in secondo luogo, mi viene in mente l'assurdità dell'analisi dei codificatori MQL - ricorda di tirare l'intero archivio per un file particolare, e non di tirare un singolo file selezionato con precisione. Se si fa un precalcolo dei tempi esatti degli estremi, ci vorranno senza dubbio tempo e risorse di macchina, ma non meno risorse saranno spese per la nostra analisi. Qualcosa mi dice che C lavora un po' più velocemente di MQL... Speculazione o fatto? E la cosa peggiore è che dobbiamo controllare periodicamente lo stato attuale degli oggetti visualizzati, cioè i ricalcoli parziali. Per evitarli, bisogna prendere i dati calcolati in precedenza dalla cache, ma questo è dal precedente "primo".

[x572intraday]

Dopotutto, questo è incorporato nel terminale come una caratteristica in modo che uno possa scegliere opzionalmente se il terminale calcola i tempi precisi delle barre o no. Questa è una pratica standard, lasciare che l'utente scelga tra precisione e tempismo. Tuttavia, la possibilità che i programmatori MQL credano che gli sviluppatori di terminali debbano pre-calcolare attributi aggiuntivi delle barre è strana e poco seria. Certo, possiamo anche fare molto, ma dobbiamo vedere chiaramente e distribuire i ruoli tra gli sviluppatori del terminale e i programmatori MQL cercando di essere obiettivi.