¡¡¡Ideas ambiciosas !!! - página 7

 
Mathemat:

Se equivoca de nuevo. La interpretación de la corriente entrante es tarea de quien se sitúa por encima del receptor y establece las condiciones del Juego. El receptor es de hierro; tritura la información según el algoritmo que le ha fijado el Game Master. En este sentido es completa y estrictamente objetiva, porque es una plancha muda. Pero es el Maestro el que es subjetivo.

¿Sabe que la información puede definirse de diferentes maneras, según el contexto del problema que se resuelve?

Por subjetividad del receptor me refiero a que puede interpretar la información de entrada de forma arbitraria, según el algoritmo implícito en ella. En este caso, la información objetiva de entrada es transformada por el receptor en subjetiva. El contexto y todo lo demás no tiene nada que ver.
 
Gracias, no es un mal sitio.
 
Algunas personas piensan que la programación orientada a objetos es realmente eficaz en los grandes proyectos, mientras que en los pequeños es mejor utilizar la vieja programación procedimental. Pero no estoy de acuerdo con esta opinión. Si el programa que quiere escribir es más grande que "Hello word" en al menos una línea, es mejor utilizar la programación OOP en lugar de la procedimental. Por mi propia experiencia, puedo decir que hasta los programas más pequeños se mejoran, se les añaden nuevas funcionalidades, nuevos controles, nuevas tareas. El resultado es que un programa inicialmente concebido como algo pequeño se convierte en un verdadero monstruo. Es muy importante sentar las bases aquí. Si se trata de programación procedimental, un proyecto se verá sobrecargado con un montón de funciones inmanejables, conversiones de punteros, etc., etc. La POO es algo malo. Escriba programas en él, empezando por "Hello Word", y luego desarrolle fácilmente y con gusto su funcionalidad. Por ejemplo, es imposible escribir el más mínimo programa en C# sin utilizar la POO. ¿Crees que los desarrolladores de este lenguaje son unos imbéciles miopes?
 
C-4:
Pero no estoy de acuerdo con esa opinión. Si el programa que quiere escribir es más que "Hello word" por lo menos una línea, es mejor usar OOP en lugar de
¿Podría darnos un ejemplo concreto con el que compararlo, para que no quede sin fundamento?
 

Ya está, el tema se ha desviado, estábamos hablando de otra cosa:

>OCULTO 10.11.2010 22:39

>Desde hace un par de años me ronda la idea de implementar un probador de estrategias multidivisa.

Si no te gusta la OOP, no la uses, es una discusión inútil.

 
xeon:

Ya está, el tema se ha desviado, estábamos hablando de otra cosa:

>OCULTO 10.11.2010 22:39

>Desde hace un par de años me ronda la idea de implementar un probador de estrategias multidivisa.

Si no te gusta la OOP, no la uses, es una discusión inútil.


He leído todo lo que se ha escrito aquí, y ahora me da mucho miedo MT5 porque estoy obsesionado con él, y quiero implantarlo cuanto antes.

Gracias a todos los que saben poner correctamente (razonablemente) los cerebros en su sitio.

Si pienso que MT5 está desarrollado por un equipo de personas, y todos lo estamos probando, ¿cuánto tiempo voy a emplear para su implementación en MQL4? Y MT4 morirá tarde o temprano, es cuestión de tiempo. Creo que MT5 durará entre 5 y 10 años de todos modos.

 
HIDDEN:

Después de leer todo lo que se ha escrito aquí, he empezado a mirar hacia MT5 porque me atrae mucho, y quiero implementarlo cuanto antes.

Gracias a todos los que saben poner correctamente (razonablemente) los cerebros en su sitio.

Si pienso que MT5 está desarrollado por un equipo de personas, y todos lo estamos probando, ¿cuánto tiempo voy a dedicar a su implementación en MQL4? Y MT4 morirá tarde o temprano, es cuestión de tiempo. De todos modos, creo que MT5 durará entre 5 y 10 años.

De momento en el probador de MT5, hay un obstáculo insalvable (al menos por ahora), que puede desanimar (a algunos usuarios), es la imposibilidad de establecer para las pruebas/optimización un historial propio (de terceros).
 
xeon:
De momento, en el probador de MT5, hay un obstáculo insalvable (al menos por ahora) que puede hacer desistir de él (a algunos usuarios), es la imposibilidad de utilizar un historial propio (de terceros) para las pruebas/optimización.


Por desgracia, hay un par de "puntos sensibles" en MT5 - indicadores multi divisa - muy inestable de trabajo en el probador, es difícil de depurar los indicadores multidivisa debido a la necesidad de la carga independiente de las matrices de series de tiempo - no se hace todavía, pero pronto lo haré - voy a mover el cálculo de los indicadores multidivisa al propio Asesor Experto - entonces los problemas deben desaparecer

SBS: gracias a la topicstarter para la comprensión - tenemos bastante ocupado en su tema :), con la implementación de un probador de múltiples monedas en MT4, no hay problemas particulares - ejemplos decentes en el foro, pero como un probador totalmente funcional no funcionará, y se esfuerzan por crear su propio probador - tiempo perdido - con el mismo éxito, puede analizar el comercio de múltiples monedas en el mismo Exel

 
IgorM:


por desgracia, hay un par de "problemas delicados" en MT5 - indicadores de multidivisas - no funcionan con confianza en el probador, es difícil de depurar los indicadores de multidivisas debido a la necesidad de la carga independiente de las matrices de series de tiempo - no se hace todavía, pero pronto lo haré - voy a mover el cálculo de los indicadores de multidivisas al propio Asesor de Expertos - entonces los problemas deben desaparecer

El bombeo del historial desde la base de datos MQ es fácil, sobre todo porque hay un ejemplo preparado: - https://www.mql5.com/ru/docs/series/timeseries_access

p.d. si he entendido bien la tarea...

 
xeon:
De momento en el probador de MT5 hay un obstáculo insalvable (al menos por ahora) que puede acabar con él (para algunos usuarios), que es la imposibilidad de sustituir el historial propio (de terceros) por el de pruebas/optimización.


Eso es un hecho. Los principiantes no lo necesitan, pero en el comercio real es algo necesario.