Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
"Apoteosi" considero un'espressione di fxsaber, sulla quale lui stesso non poteva dire come funziona, affermando semplicemente che "il codice è stato ripetutamente testato, e funziona". Questo, secondo me, non dovrebbe essere il caso:
Questo codice controlla seun ordine otfFilingType può essereeseguito, e lo restituisce se è disponibile su strSymbol, altrimenti è corretto.
Non ho assolutamente idea di come funzioni. E fare affidamento solo sull'autorità di fxsaber.
Forse qualcuno può spiegare?
Per capirlo, basta smontare questa ingombrante espressione di ritorno nei suoi componenti.
Il tuo esempio di "il fine giustifica i mezzi"
comunque questo codice è proprio come degli spaghetti, ma considerando che è probabilmente l'autore più utile in kodobase in questo momento e io stesso uso i suoi codici così come sono, lasciamo che qualcun altro critichi
comunque questo codice è proprio come degli spaghetti, ma dato che è probabilmente l'autore più utile in kodobase in questo momento e io stesso uso i suoi codici così come sono, lasciamo che qualcun altro critichi
non si tratta di critica, sto cercando di capire cosa può fare.... Ma come mostra l'intervista, e come ha ammesso lo stesso@fxsaber- nient'altro che mal di testa
SZZ: è molto probabile che la variante iniziale del piccolo mostro abbia un aspetto più chiaro ;)
ZS: alta probabilità che la versione originale del mostriciattolo sembrasse più evidente ;)
Preso da ZIP (contiene la primissima versione).
Ma in seguito c'era bisogno di sempre più funzionalità, e il codice stava lentamente diventando più corposo. Era diverso con la funzione Filling. Non c'era niente di definito, è stato scritto in una volta sola.
Solo il compilatore sa esattamente cosa farà. I compilatori moderni hanno un'euristica sbalorditiva. Si adattano al codificatore medio e sanno già meglio di cosa ha bisogno. La cosa migliore che un compilatore può fare è scrivere codice semplice e diretto con funzioni brevi. È più facile ed efficiente per il compilatore analizzare il grafo del codice sorgente composto da molti nodi di funzione per costruire il programma risultante. Avrà solo un effetto positivo sulla produttività, poiché le funzioni necessarie saranno bloccate in tutti i posti giusti.
Hai assolutamente ragione.
Se stiamo parlando di MQL5, potete dimenticare i metodi di "ottimizzazione" di 10-20-30 anni fa. Dovete scrivere il codice più leggibile. È così, e non la roba da hacker e la pura furbizia.
Perché?
Poiché il compilatore passa attraverso 5-10 cicli di riordino del codice, è incredibilmente chiaro e conciso, per non parlare dell'uso di decine di modelli di ottimizzazione.
Il compilatore MQL5 è divertito dai tentativi umani di fare +2% di velocità.
Questa è un'opera d'arte in realtà. 8 radici sono state calcolate in 4 chiamate del comando assembler. Due numeri doppi sono stati calcolati in una chiamata.Se vi interessa, guardate come calcoli SQRT + matematici vanno senza ramificazioni e un comando (128 bit di dati) calcola due radici in una volta
Questo codice si trasforma nel seguente codice assembler SSE:
La conclusione generale: la matematica ha vinto in MQL5 grazie alla perfetta ottimizzazione. Qui non sono gli array a perdere, ma vince la matematica.
Perché?
Al contrario, è molto più facile con due "se" che con l'operatore "o".
È più facile tracciare prima una condizione, e lasciare la funzione se è vera, e poi controllare l'altra condizione, e lasciare anche questa se è vera, che indovinare il risultato di una condizione complessa con "o" logico (che può essere facilmente confuso con "e"), e tracciare entrambe le opzioni di ritorno.
È piuttosto divertente leggere qui sotto che "la giustificazione per tale è il debugging", perché significa che tale codice è molto più comprensibile (altrimenti perché è in debugging?).
"Apoteosi" considero un'espressione di fxsaber, sulla quale lui stesso non poteva dire come funziona, affermando semplicemente che "il codice è stato ripetutamente testato, e funziona". Questo, secondo me, non dovrebbe essere il caso:
Questo codice controlla seun ordine otfFilingType può essereeseguito, e lo restituisce se è disponibile su strSymbol, altrimenti è corretto.
Non ho assolutamente idea di come funzioni. E fare affidamento solo sull'autorità di fxsaber.
Forsequalcuno può spiegare?
Una volta mi sono seduto e l'ho smontato passo dopo passo, sembra che abbia avuto bisogno di carta e penna)
Perché questo parsing è stato utile - ho capito che in caso di cambiamento della struttura di enum tutto sarà rotto) dato che vengono usate relazioni intere di valori enum (che secondo l'idea stessa di enumerazioni dovrebbero essere incapsulate). Io stesso cerco di evitarlo, al massimo il rapporto più-meno. Per coloro che hanno a che fare con WinAPI, è probabilmente familiare.
Per capire, basta smontare quell'espressione ingombrante di retournee.
Sì, è quello che ho cercato di fare. Ma non c'era abbastanza motivazione per smontarlo...
Assolutamente giusto.
Se stiamo parlando di MQL5, potete dimenticare i metodi di "ottimizzazione" di 10-20-30 anni fa. Dovete scrivere il codice più leggibile. È così, e non la roba da hacker e la pura furbizia.
Esattamente. Sono arrivato a questa conclusione molto tempo fa. Ma non perché penso che il compilatore lo renderà migliore. Ma perché la principale fonte di problemi nel codice è l'essere umano stesso, il che significa che si dovrebbe scrivere il codice in modo da renderlo il più semplice e trasparente possibile.
Quando non può essere "trasparente", bisogna scrivere commenti dettagliati sul perché è così e non così.
E il compilatore... Anche se non lo fa in modo abbastanza efficiente, è meno un problema che un potenziale bug dovuto al fatto che non si tiene conto di alcuni aspetti del programma.
Il codice è molto semplice e breve(descrizione). Se lo scrivi su FP, sarebbe interessante confrontarlo.
Per favore. C# in stile FP:
FP è abbastanza storto naturalmente (poiché è stato scritto da un codificatore FP storto, nel linguaggio FP incompleto C#).Ma l'obiettivo è mostrare che sul moderno gergo OOP si può fare anche in FP. Certo, è limitato, non è F# o Haskell, ma nessuno vieta di scrivere in stile FP. Usare l'immutabilità, funzioni di ordine superiore, chiusure, mappature, ecc. - sei il benvenuto a fare tutto. Ma questo non rende il codice perfetto per qualche motivo.
s.w. La struttura generale del codice imita deliberatamente l'originale. Anche se in senso buono dovrebbe essere molto diverso in FP, senza oggetti complessi e foreach che imitano Map, ma l'artista ha dipinto come poteva.
Per favore. C# in stile FP:
Capisco che è una questione di abitudine e di conoscenza della sintassi, ma ho molta difficoltà ad entrare nel codice anche se sono l'autore originale.
Forum sul trading, sistemi di trading automatico e test di strategia
Interessante opinione su OOP
fxsaber, 2021.01.29 13:39
Un'inezia.
Tecnicamente, è probabilmente un OOP. Ma la parte più primitiva. Non potrei farlo senza, però. Possibilmente, stupido riarrangiamento del cervello e avvincente questo.