Un sotto-laboratorio per riempire le FAQ (domande frequenti). Aiutiamo i compagni! - pagina 14

Nuovo commento
 
TheXpert:
E la cosa giusta da fare, imho, è sempre chiedere al terminale le informazioni più aggiornate.

Lo stato degli ordini (array) viene interrogato esattamente quando devono essere gestiti.

Non sto sostenendo che possiamo farne a meno, e che non abbiamo bisogno di ottenere una masiew in anticipo. E analizzare immediatamente lo stato degli ordini su richiesta dopo OrderSelect e filtrare quelli indesiderati per mago, simbolo, ecc.

Ma voi sostenete che la matrice dei biglietti è un UG. Giustificare il perché.

-------------

Taras ha suggerito l'opzione "ultra" quando tutte le informazioni sull'ordine sono scritte nell'array. Posso solo essere d'accordo con questo nella posizione che tutte queste informazioni non sono necessarie. E nella versione semplificata, per la maggior parte, sono necessari solo i biglietti.

 
TheXpert:
Non lo suggerirei. Il più delle volte, una serie di biglietti non è affatto necessaria. E la cosa giusta da fare, imho, è chiedere sempre al terminale le informazioni più aggiornate possibili.
In un array si ottengono informazioni, vivendo condizionatamente 1 tick. Di quali altre informazioni "fresche" avete bisogno? Io uso la mia pratica, quando ho 2-4 conti multicurrency (intendo la demo) che non permettono di "disturbare il server" per cose inutili.

E in generale, questo è il tuo e il mio punto di vista personale. E l'utente deve sempre avere il diritto di scegliere - quali argomenti sono più sensati. ;)

P.S. E ho dato solo la MIA risposta alla domanda posta nelle FAQ. :)

 

OK, IMHO UG perché IMHO è corretto avere le informazioni più aggiornate sugli ordini. E IMHO si può fare a meno di una serie di ordini il 95% delle volte.

Se vuoi, aggiungi pure, io stavo solo dando la mia opinione.

 

Mettiamola così:

- In termini di convenienza e di astrazione del modello, è meglio usare gli array.
- Per accelerare il lavoro - senza array.

La rilevanza dell' informazione non c'entra niente. In entrambe le varianti - con o senza array - la rilevanza è al 100% fresca

 
sergeev:

-------------

Taras ha suggerito l'opzione "ultra", dove tutte le informazioni sull'ordine sono scritte nell'array. Posso essere d'accordo con questo solo nella posizione che tutte queste informazioni non sono necessarie. E nella variante semplificata sono necessari per lo più solo i biglietti.

Alexey! Sono lontano dal pensare che introducendo questa domanda nelle FAQ (Ottenere un array di biglietti di ordini "propri"), tu intendessi circa "la posizione che tutte queste informazioni non sono necessarie" - come giocare?!
O ho frainteso qualcosa?
 
TarasBY:
Alexey! Sono lontano dal pensare che introducendo questa domanda nelle FAQ (Ottenere un array di biglietti di ordini "propri"), intendevi la "posizione che tutte queste informazioni non sono necessarie" - come giocare con?
O ho capito male qualcosa?

Per qualche ragione, hai incluso tutte le proprietà nel concetto di "il tuo biglietto" oltre al biglietto.

Ma ho sicuramente fatto il tuo suggerimento come estensione della funzione "solo un biglietto".

C'è anche una necessità frequente, specialmente quando si analizzano e si confrontano i dati storici degli ordini.

 
sergeev:


Mettiamola così:

- In termini di convenienza e di astrazione del modello, è meglio usare gli array.
- Per accelerare il lavoro - senza array.

La rilevanza dell' informazione non c'entra niente. In entrambe le varianti - con o senza array - la rilevanza è al 100% fresca

Non sarei troppo frettoloso con la seconda ("per accelerare il lavoro - senza array").
La semplice logica suggerisce che un accesso extra al server per "informazioni fresche" è tempo extra. E non può competere in tempo con il recupero delle stesse informazioni dall'array.
C'è un esperto di velocità del codice - Victor (Vinin), la sua opinione sarebbe interessante!
 
TarasBY:
Per quanto riguarda il secondo ("nessun array per accelerare il lavoro"), non sarei troppo precipitoso per essere categorico.
La semplice logica impone che un accesso extra al server per "informazioni fresche" è tempo extra. E non può competere in tempo con il recupero delle stesse informazioni dall'array.
C'è un esperto di prestazioni del codice Victor (Vinin), la sua opinione sarebbe interessante!

Ancora una volta, quando si lavora con le proprietà degli ordini, non c'è nessun server da contattare!

Nel trading, la regola più importante è la pertinenza (per non trasformarsi nell'UG di cui ha scritto TheXpert).
Quindi, se si fa riferimento all'elenco degli ordini ad ogni funzione e si crea di nuovo un array, questo causerà sicuramente un rallentamento. Causerà il riempimento dell'array.

Quindi, si può risparmiare solo sull'attualizzazione dell'array e su OrdeSelect ripetuto (già sul biglietto).

Se avete 1-2 ordini di lavoro, l'array non è critico, ma se ne avete 50-100, è già significativo.

 
Dirò di più: in base al mio concetto già espresso di "riduzione del carico del server" (lo chiamerei più precisamente "ottimizzazione della velocità del codice"), ottengo tutti i prezzi in un array separato (se ne ho bisogno per diversi strumenti) all'inizio di Start(). E se devo fare un'operazione di trading, faccio RefreshRates().

Non sto imponendo questo approccio a nessuno, semplicemente vedo la logica dietro di esso e uso questo principio nei miei progetti.

P.S. Questo non è per iniziare una disputa su questo argomento, è semplicemente un argomento a quanto sopra.

 
sergeev:

Quindi, se si fa riferimento all'elenco degli ordini ad ogni funzione e si ricrea di nuovo l'array, questo porterà sicuramente ad un rallentamento. A causa del riempimento dell'array.

Ho detto questo? L'array di tick viene riempito una volta per tick se l'EA sta lavorando su ogni tick. E poi invece del solito campionamento:
    for (int li_int = li_total - 1; li_int >= 0; li_int--)
    {
        if (OrderSelect (li_int, SELECT_BY_POS))
        {
        .......
        }
    }
Seleziono da
for (int li_TIC = 0; li_TIC < gi_cnt_Tickets; li_TIC++)
{

}

oppure:
    for (int li_SMB = 0; li_SMB < ArraySize (gsa_Symbols); li_SMB++)
    {
    }
a seconda di come mi sento più a mio agio con questa o quella funzione.
Sono d'accordo che la razionalità di questo approccio è più evidente nei sistemi multivalutari, che sono una minoranza.
1...789101112131415161718192021...24
Nuovo commento