Errores, fallos, preguntas - página 1409
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
En cuanto al anuncio de la nueva construcción 1200.
Este tipo de soluciones se ven muy crujientes cuando se añade a la estructura ellargo time_msc junto con eldatetimetime. La pregunta es ¿por qué se necesita el time entonces? Es un desperdicio de recursos sin sentido.
Lo mismo ocurre con las banderasuint, mientras queuchar sería suficiente allí o al menos ushort (que con una importante reserva para el futuro). Y por qué se necesita uint allí está más allá de la comprensión.Lo triste es que los desarrolladores han dejado completamente de pensar en el almacenamiento racional de datos. Un array de ticks es un tamaño colosal por sí mismo. Y aquí se está derrochando la memoria de forma tan descuidada...
En fin, hablando de tiempo. Tal vez sea el momento de introducir en MQL un tipo de tiempo normal que contenga milisegundos, o de lo contrario sólo tendremos estas muletas.Tanto más cuanto que el propio datetime, en su forma actual, es algo muy irracional: consume 8 bytes pero sólo contiene segundos, y ¿quién lo necesita? 4 bytes(uint) son suficientes para esta tarea durante los próximos 90 años (y Duncan McLeod no está entre nosotros).
Esta solución preserva la compatibilidad con programas más antiguos que utilizan el tiempo en segundos o SymbolInfoTick().
Según nuestra experiencia, el juego de "hagamos un byte o dos" conduce a problemas monstruosos en el futuro. Sólo se entiende cuando se escribe software para 10 años adelante.
Los 4 bytes de fecha en segundos terminarán en 2038 (22 años más), no en 90 años.
¿Qué significa aquí TM=30M?
Según nuestra experiencia, el juego de "hagamos un byte o dos" conduce a problemas horribles en el futuro. Sólo te das cuenta de esto cuando escribes software con 10 años de antelación.
Por supuesto, hay que dejar algo de espacio para el futuro, pero dentro de unos límites razonables. Por ejemplo, en el caso que estamos comentando, el campo de las banderas sólo almacena información sobre otros seis campos. Si lo haces de tipo ushort, te sobrarán 10 campos más. ¿Cuánto más puedes añadir?
Si piensas guardar un vaso lleno, por ejemplo, 32 bits no son suficientes. ¿Por qué no hacerlo de 64 bits de una vez? Aunque, obviamente, para un vaso necesitarás una estructura muy diferente.
Por supuesto, entiendo que 2 bytes más no son muy significativos, pero resulta que 2 bytes por aquí, 2 bytes por allá... y se suma a un montón.
4 bytes de fecha en segundos terminan en 2038 (otros 22 años), no en 90 años.
Les digo - van a sufrir con estructuras económicas no extensibles, empiecen a pensar en términos de décadas, necesidad de apoyo largo y todo se aclarará.
Con las fechas de 4 bytes, las masas de software tendrán grandes problemas de desbordamiento justo en 2038, lo que llevará a reescribir frenéticamente el código antiguo. Y los desbordamientos se detectarán incluso antes en las operaciones de esteras y deltas.
Llevo 25 años programando y sé de lo que hablo. Llevo toda la vida escribiendo programas rentables. Fíjese en nuestros terminales: son verdaderas obras maestras por la cantidad de funcionalidades que contienen los archivos exe de pequeño tamaño. Ejecute un único terminal.exe desnudo en un ordenador limpio y vea lo que ocurre.
Pero ahora las cosas han cambiado: o escribes código de 64 bits con margen en casi todas partes o te quedas fuera del futuro. Esto es especialmente importante para nosotros, ya que no estamos lanzando cajas cerradas, sino plataformas de desarrollo con un requisito de compatibilidad.
Dentro de un par de años nos daremos una patada porque volveremos a encontrarnos con una inversión insuficiente. Y a su alrededor hay ordenadores con decenas de gigabytes en equipos básicos.
¿Qué significa aquí TM=30M?
Con un datetime de 4 bytes la mayoría de los programas tendrán grandes problemas de desbordamiento justo en 2038 lo que llevará a reescribir frenéticamente el código antiguo. Y los desbordamientos se detectarán incluso antes en las operaciones de esteras y deltas.
¿Te refieres a los códigos MQL4? (donde el datetime se basaba originalmente en el int). Luego, por supuesto, otra conversación relacionada con los problemas de compatibilidad. Pero originalmente estaba hablando de la racionalidad. Así que, en este caso, la racionalidad sufre.
Sin embargo, en cualquier caso, creo que estarás de acuerdo en que es necesario un nuevo tipo de tiempo que contenga milisegundos y que no debería empezar a partir de 1970, sino mucho antes, por ejemplo desde 1900. Ya no se trata sólo de forex, sino que los intercambios existen desde hace mucho tiempo.
...
Pero, en cualquier caso, creo que estará de acuerdo en que es necesario un nuevo tipo de tiempo, que contenga milisegundos. Y no debería empezar en 1970, sino mucho antes, por ejemplo en 1900. No estamos hablando sólo de forex ahora, sino que las bolsas existen desde hace mucho tiempo.
El único problema es que bajo el zar Gorokh no estaba de moda el uso de ordenadores y la historia de las garrapatas no se conservó para las generaciones futuras...
No se trata necesariamente de ticks. Por ejemplo, las velas del día siguen intactas.
Me da vergüenza preguntar, ¿por qué necesitas los precios de las velas diarias de 1900... años? ¿Para hacer un análisis técnico? ¿Probar a los asesores en la historia?
La velocidad de ejecución aumentará de 2 a 10 veces para las versiones x64 del terminal MetaTrader 5.
El resultado merece la pena. Aunque seguiremos trabajando en la velocidad de compilación.
Hace poco presumías de que la velocidad de MQL se acercaba a la de C++. ¿Y ahora resulta que va a superar a C++ en varias veces? ))
Si consigues esta velocidad en algunas pruebas especialmente preparadas, no significa que la consigas también en otros casos, pero la velocidad de compilación se reduce en todos los casos.