Número mágico automático - página 3

Nuevo comentario
 
BarrowBoy:

Si no estuvieras cerrando parcialmente ninguna orden, podrías usar el comentario para almacenar la información del par/marco de tiempo de origen...

Si hay dos EAs en el mismo símbolo y marco temporal, ¿cómo saben de cuál de las órdenes históricas deben recoger sus respectivos IDs?


Todo esto depende en parte de la información que uno asume que está garantizada para estar disponible en el reinicio. Por ejemplo, hay algunas personas en este foro que almacenan los datos en esta línea en objetos ocultos en la ventana del gráfico. Eso no está mal, pero a mí personalmente me asusta cualquier mecanismo que el usuario pueda romper, sin darse cuenta de cómo o por qué.

 
jjc wrote >>

Si hay dos EAs en el mismo símbolo y marco temporal, ¿cómo saben cuál de las órdenes debe recoger sus respectivos IDs?

Maldita sea - era que en el ámbito del proyecto :D

Supongo que asumí que el EA (si es de diferente tipo o versión) tendría un identificador en los comentarios también :)

-BB-

 
jjc wrote >>

No veo cómo esto es posible sin que MT4 o el usuario asigne un ID a cada EA. O, más exactamente, no puedo ver nada que no implique algo muy desagradable como generar un ID único y luego modificar el archivo .chr del EA para almacenar el ID como parte de los parámetros externos del EA.

Y, para entretenimiento general, lo siguiente no avanza realmente la discusión de ninguna manera, pero reemplaza la entrada al hash djb2 con un valor que está garantizado para ser único (a costa de requerir llamadas DLL). No sé qué tan bueno es djb2 en cosas como GUIDs, pero acabo de intentar generar 1,000,000 IDs sin ninguna colisión. Pero sigue sin resolver el problema del reinicio.

No veo cómo es posible sin que MT4 o el usuario asigne un ID a cada EA. O, más exactamente, no puedo ver nada que no implique algo muy desagradable como generar un ID único y luego modificar el archivo .chr del EA para almacenar el ID como parte de los parámetros externos del EA.

>>¿Cómo podría la enésima instancia del EA p/u su archivo chartyy.chr?

.

asumiendo que una instancia pueda realmente mapear su propio archivo .chr:

si el código fuente del EA tiene: extern int myID = <someCompileTimeVal>;

entonces cualquier instancia que vea <someCompileTimeVal> puede asumir que es la 'primera vez' -> gen it's id -> mod myID line -> create recovery files using myID's uniqueness,...

entonces en la detección de reinicio acceder a su archivo .chr para p/u myID que sería la llave maestra para permitir la reasignación de archivos...

.

Ej:

chart02.chr

<gráfico>
símbolo=EURUSD
periodo=15
..

..

<experto>
name=LMT 1.8
flags=343
window_num=0
<entradas>
myID=<someCompileTimeVal>

...

</inputs>
</experto>
EOF


¡¡¡Ayuda !!!

.

Y, para entretenimiento general, lo siguiente no hace avanzar la discusión de ninguna manera, pero reemplaza la entrada al hash de djb2 con un valor que está garantizado para ser único (a costa de requerir llamadas a la DLL). No sé qué tan bueno es djb2 en cosas como GUIDs, pero acabo de intentar generar 1,000,000 IDs sin ninguna colisión.

He utilizado PsPad ed para aspirar a los 1mil y he hecho una ordenación con remove dups marcado.

>>Pero... ¿Cómo has hecho esta detección ".. sin colisiones" ?

 

"Y, para entretenimiento general, lo siguiente no avanza realmente en la discusión de ninguna manera, pero reemplaza la entrada al hash de djb2 con un valor que está garantizado para ser único (a costa de requerir llamadas DLL). No sé qué tan bueno es djb2 en cosas como GUIDs, pero acabo de intentar generar 1.000.000 de IDs sin ninguna colisión".

.

Para tu información, he encontrado colisiones en mis 1mil llamadas del código

ordenado EOF

.

sorted + dups removed EOF

 
fbj:

>>¿Cómo podría la enésima instancia de EA p/u su archivo chartyy.chr?

.

asumiendo que una instancia pueda realmente mapear su propio archivo .chr:

si el código fuente del EA tiene: extern int myID = <algunoCompileTimeVal>;

entonces cualquier instancia que vea <someCompileTimeVal> puede asumir que es la 'primera vez' -> gen it's id -> mod myID line -> create recovery files using myID's uniqueness,...

entonces en la detección de reinicio acceder a su archivo .chr para p/u myID que sería la clave maestra para permitir la reasignación de archivos...

Tienes razón. Había olvidado que no hay una forma obvia de que un EA identifique su archivo .chr si hay varios EAs para el mismo símbolo y marco temporal. Estaba pensando que podría crear un objeto de etiqueta oculta que contenga algo así como un GUID, y luego buscar el archivo .chr que contenga el valor correcto. Sin embargo, estoy bastante seguro de que el archivo .chr no se actualiza cuando se añade un nuevo objeto al gráfico.


Y hay otro problema. Estoy bastante seguro de que MT4 mantiene la información sobre el gráfico en la memoria, escribe en el archivo .chr cuando MT4 se cierra (o se hace un cambio en las propiedades del EA), y esto, por lo tanto, sobrescribiría cualquier cambio que el propio EA hiciera en el archivo .chr mientras se estaba ejecutando. Si fuera increíblemente valiente, podría intentar establecer la propiedad externa simulando la pulsación de teclas - llamando a la ventana de propiedades, moviéndose a la configuración requerida, cambiándola, pulsando Enter, etc.

 
fbj:

Para que sepas, encontré colisiones en mis 1mil llamadas al código

ordenado EOF

Al volver a ejecutarlo, también lo hice: 172 colisiones en 1.000.000 de intentos.

 
jjc wrote >>

Tienes razón. Había olvidado que no hay una forma obvia de que un EA identifique su archivo .chr si hay varios EAs para el mismo símbolo y marco temporal. Estaba pensando que podría crear un objeto de etiqueta oculta que contenga algo así como un GUID, y luego buscar el archivo .chr que contiene el valor correcto. Sin embargo, estoy bastante seguro de que el archivo .chr no se actualiza cuando se añade un nuevo objeto al gráfico.

Y hay otro problema. Estoy bastante seguro de que MT4 mantiene la información sobre el gráfico en la memoria, escribe en el archivo .chr cuando MT4 se cierra (o se hace un cambio en las propiedades del EA), y esto, por lo tanto, sobrescribiría cualquier cambio que el propio EA hiciera en el archivo .chr mientras se estaba ejecutando. Si fuera increíblemente valiente, podría intentar establecer la propiedad externa simulando la pulsación de teclas - llamando a la ventana de propiedades, moviéndose a la configuración requerida, cambiándola, pulsando Enter, etc.

Leí lo anterior -> me fui a hacer un poco de ejercicio -> y durante la ducha las células grises gritan OBJECT. Matas la ruta .chr pero las dos palabras "etiqueta objeto" provocaron ese estallido cerebral :)

Entonces, ¿qué te parece? olvidando por el momento lo de conseguir el 100% de la identificación garantizada. La otra parte es esta memoria de estado recuperable que contiene un ID de EAs.

Bueno...

1. void vArchiveID (int iID), int iRestoreID () [y int iGetNewID () llegar a en otro post SI este está bien :]

2. vArchiveID() crea el objeto [¿oculto?] label? en el gráfico de memoria de estado de EAs.

El nombre del objeto DEBE ser el mismo para cualquier EA que llame... así que .ex4 lib o .mqh lib para (1)

3. El TC se va a la quiebra o el EA se hunde, etc.

4. Al reiniciar el EA, el primer trabajo es llamar a iRestoreID() que devuelve -1 si no hay objeto en el gráfico o el ID archivado de la ejecución anterior.

5. si no hay ID entonces llama a iGetNewID() y luego a vArchiveID() y presumiblemente establece [por primera vez] cosas del archivo de volcado

6. si el ID es 'restaurado' entonces se recupera el último estado a través de los archivos de volcado...

..

¿Qué te parece?

 
fbj:

[...]

¿Qué te parece?

Lo que sugieres es -creo- exactamente a lo que me refería en mi post de las 14:43. El único peligro con esta ruta - y la única razón para jugar con el archivo .chr directamente, con el fin de establecer las propiedades externas - es eliminar la posibilidad de que los usuarios accidentalmente borrar los objetos de la carta. Pero incluso eso puede superarse en gran medida asegurando que el objeto se recrea, si es necesario, en deinit().


Pero BB/CB puede considerar inaceptable depender del archivo .chr. Es posible que quieran algo que pueda recuperarse únicamente a partir de los datos mantenidos fuera de las instalaciones (es decir, la lista de operaciones mantenida por el corredor).

 

Había estado alejado de este hilo durante un tiempo.


Parece que estamos añadiendo algún grado de complejidad para permitir la recuperabilidad con números mágicos automatizados, ¿no? Es decir, para que una pieza tonta de código reencarnado pueda averiguar quién era en una vida pasada cuando todo lo que sabe es lo que es y dónde está. No es necesariamente algo malo. Pero..


Me hizo pensar que sería útil documentar (muy concisamente)

- Criterios para decidir implementar números mágicos

- Criterios para decidir utilizar la generación automatizada de números mágicos

- Criterios para decidir implementar una capa de persistencia

- Criterios para decidir sobre el acceso a globales o a archivos para la persistencia


La razón por la que sugiero esto es para evitar que todo el mundo piense que tiene que implementar el fregadero de la cocina en sus EAs.


¿Vistas?


CB


- Sólo me quedan 8 posts antes de tomarme un descanso por un tiempo.

 

sí, bueno al final, el fregadero de la cocina es más probable que en este sitio, todos los académicos. Para mí, la primera preocupación prioritaria es tener una garantía de auto[make|acquire] Expert ID. Un valor que puede ser utilizado para muchos propósitos.

Tener una forma única de acceder a los archivos de volcado en el reinicio es, en el mejor de los casos, azaroso y, en cualquier caso, requiere que los usuarios se adhieran a un conjunto de reglas de uso de EA. Muchas instancias ccy+período+EA no es una opción.

Yo pretendía que cualquier instancia pudiera determinar quién era yo antes del reinicio y eso se ha demostrado que es inviable. Por mi parte, no confiaría en que ningún usuario siguiera ni siquiera el conjunto de reglas más básico. Si no puedo estar totalmente seguro de un método automático, no adoptaría un medio en el que se requiriera la intervención del usuario.

.

Usando CoCreateGuid() de jjc i/f voy a generar suficientes números no repetitivos. Suficiente es subjetivo pero yo voy por muchos... Junto con un trozo de código de la biblioteca como la función del servidor de acceso a los recursos al archivo que contiene los números. La cantidad de números será tal que al menos 2 años pueden pasar sin reutilizar un número. En el momento en que se alcanza el EOF, simplemente se envuelve en BOF y continúa sirviendo números. Mis cálculos se basan en 10 solicitantes que trabajan 5 días a la semana y 50 semanas al año, donde cada día un solicitante podría necesitar 20 nuevos números. Este resultado se duplica. Una cantidad absurda de números, básicamente 200.000. Sí, una funcionalidad de la edad de piedra, pero sin necesidad de depender del terminal de ninguna manera más allá de la capacidad de ejecutar mi código. Por supuesto, uno podría seguir durante siglos sobre las ramificaciones de uno, 10 o 100 archivos y sus ubicaciones físicas y mecanismos de acceso. Al final es mucho mejor que mi lamentable función make expert id y es estanco en cuanto a la unicidad del número para [en realidad] más de 2 años.

.

CB, el 666 debe ser el número de la suerte de los pilotos de helicópteros.

1234
Nuevo comentario