Errori, bug, domande - pagina 1409
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
Per quanto riguarda l'annuncio della nuova costruzione 1200.
Tali soluzioni appaiono molto crostose quando unlungo time_msc viene aggiunto alla struttura insieme altempodatetime. La domanda è perché il tempo è necessario allora? È uno spreco di risorse senza senso.
Lo stesso vale per le bandiereuint, mentreuchar sarebbe sufficiente lì o almeno ushort (che con una riserva significativa per il futuro). E perché uint è necessario lì non è comprensibile.La cosa triste è che gli sviluppatori hanno completamente smesso di pensare all'immagazzinamento razionale dei dati. Un array di tick è una dimensione colossale di per sé. E qui la memoria viene sprecata in modo così sconsiderato...
Comunque, parlando di tempo. Forse è il momento di introdurre in MQL un tipo di tempo normale che contenga millisecondi, altrimenti avremo solo queste stampelle.Tanto più che lo stesso datetime nella sua forma attuale è una cosa molto irrazionale: consuma 8 byte ma contiene solo secondi - e chi ne ha bisogno? 4 byte(uint) sono sufficienti per questo compito per i prossimi 90 anni (e Duncan McLeod non è tra noi).
Questa soluzione conserva la compatibilità con i vecchi programmi che usano il tempo in secondi o SymbolInfoTick().
Nella nostra esperienza, il gioco del "facciamo un byte o due" porta a problemi mostruosi in futuro. Lo si capisce solo quando si scrive software per 10 anni avanti.
I 4 byte di datetime in secondi finiranno nel 2038 (22 anni in più), non in 90 anni.
Cosa significa qui TM=30M?
Nella nostra esperienza, il gioco del "facciamo un byte o due" porta a problemi orrendi in futuro. Te ne rendi conto solo quando scrivi software con 10 anni di anticipo.
Quindi non si tratta di arrivare al limite. Certo, dovremmo lasciare un po' di margine per il futuro, ma entro limiti ragionevoli. Per esempio, nel caso che stiamo discutendo, il campo flags memorizza informazioni solo su altri sei campi. Se lo fate di tipo ushort, avrete 10 campi in più, quanto potete aggiungere ancora?
Se pensate di salvare un bicchiere pieno, per esempio, 32 bit non sono sufficienti. Perché non fare 64 bit in una volta sola? Anche se, ovviamente, per un bicchiere avrete bisogno di una struttura molto diversa.
Certo, capisco che 2 byte in più non sono molto significativi, ma risulta che 2 byte qui, 2 byte là... e si aggiunge molto.
4 byte datetime in secondi finiscono nel 2038 (altri 22 anni), non in 90 anni.
Vi dico - soffrirete con strutture economiche non estensibili, iniziate a pensare in termini di decenni, necessità di supporto a lungo termine e tutto diventerà chiaro.
Con 4 byte datetime masse di software avranno grossi problemi di overflow proprio nel 2038, il che porterà a una frenetica riscrittura del vecchio codice. E gli overflow saranno catturati ancora prima nelle operazioni mat e nei delta.
Ho programmato per 25 anni e so di cosa sto parlando. Ho scritto programmi a basso costo per tutta la mia vita. Guardate i nostri terminali - sono dei veri capolavori per la quantità di funzionalità contenute in singoli file exe di piccole dimensioni. Esegui un singolo terminal.exe nudo su un computer pulito e vedi cosa succede.
Ma le cose sono cambiate ora - o si scrive codice a 64 bit con un margine quasi ovunque o si resta fuori dal futuro. Questo è particolarmente importante per noi, dato che non stiamo rilasciando scatole chiuse, ma piattaforme di sviluppo con un requisito di compatibilità.
Tra un paio d'anni ci prenderemo a calci perché ci ritroveremo di nuovo sottoinvestiti. E tutto intorno ci sono computer con dozzine di gigabyte nell'equipaggiamento di base.
Cosa significa qui TM=30M?
Con 4 byte datetime la maggior parte dei software avrà grandi problemi di overflow proprio nel 2038, il che porterà a una frenetica riscrittura del vecchio codice. E gli overflow saranno catturati ancora prima nelle operazioni mat e nei delta.
Intendi i codici MQL4 (dove datetime era originariamente basato su int). Poi, ovviamente, un'altra conversazione legata a problemi di compatibilità. Ma io parlavo inizialmente di razionalità. Quindi, in questo caso, la razionalità ne risente.
Comunque, in ogni caso, penso che sarete d'accordo che un nuovo tipo di tempo contenente millisecondi è necessario e non dovrebbe iniziare dal 1970, ma molto prima, per esempio dal 1900. Non si tratta più solo di forex, gli scambi esistono da molto tempo.
...
Comunque, in ogni caso, penso che sarete d'accordo che è necessario un nuovo tipo di tempo, uno che contenga millisecondi. E non dovrebbe iniziare nel 1970, ma molto prima, per esempio nel 1900. Non stiamo parlando solo di forex ora, ma gli scambi esistono da molto tempo.
L'unico problema è che non era di moda usare i computer sotto lo zar Gorokh e la storia delle zecche non è stata conservata per le generazioni future...
Non si tratta necessariamente di tick. Per esempio, le candele del giorno sono ancora intatte.
Mi imbarazza chiedere, perché avete bisogno dei prezzi delle candele giornaliere per 1900... anni? Per fare analisi tecnica? Per testare i consiglieri sulla storia?
La velocità di esecuzione aumenterà da 2 a 10 volte per le versioni x64 del terminale MetaTrader 5.
Il risultato ne vale la pena. Anche se lavoreremo ancora sulla velocità di compilazione.
Recentemente vi siete vantati che la velocità di MQL è vicina a quella di C++. E ora si scopre che supererà C++ di parecchie volte? ))
Se riuscite a ottenere questa velocità in alcuni test appositamente preparati, non significa che la otterrete anche in altri casi, ma la velocità di compilazione sta rallentando in tutti i casi.