Mi enfoque. El núcleo es el motor. - página 38
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
Bueno, bueno... Ve a por ello, Peter.
Tienes razón en lo de la "degradación", pero creo que eres presuntuoso en lo de "tirar de los usuarios".
Pero, adelante. Puede que haya alguien por ahí que sepa programar, pero comercia "sin manos".
Estoy pensando, hay una famosa plataforma americana para el comercio manual. Tiene la posibilidad de automatizar parcialmente las acciones dentro de la plataforma, pero hay que saber cómo hacerlo. También hay una API. Pero, ¿cuántos lo conseguirán?
Podemos escribir semiautomáticos prácticos y ofrecerlos a los clientes. Y no sólo ellos. A todos los operadores que operan manualmente se les puede ofrecer una automatización parcial de las acciones, controlar el mercado desde las mesas e interactuar con el programa mediante ventanas de diálogo. Mostrar mensajes sobre eventos del mercado. Bueno, tal vez no sepa o no entienda algo, pero en teoría...
Nosotros, en cambio, podemos escribir semiautomáticos prácticos y ofrecerlos a los clientes. Y no sólo ellos. Podemos ofrecer a todos los operadores que operan manualmente una automatización parcial de sus acciones, observar el Mercado desde las mesas e interactuar con el programa a través de ventanas de diálogo. Mostrar mensajes sobre eventos del mercado. Bueno, tal vez no sepa o no entienda algo, pero en teoría...
Sólo hay una forma de averiguarlo.
Porúltimo, al menos publica algo.
Que sea menos que ideal y sin plushkas (si es necesario, más tarde añadir), y de inmediato ver la demanda + retroalimentación de los usuarios irá y será más claro en qué dirección para cavar siguiente.
Cuanto antes lo haga, más tiempo ahorrará (o mejor dicho, menos tiempo perderá... :(
Habría dado mucho por esos consejos en mi época :)
Bueno, bueno... Ve a por ello, Peter.
Tienes razón en lo de la "degradación", pero creo que estás siendo presuntuoso con lo de "tirar de los usuarios".
Pero, adelante. Puede que haya alguien que sepa programar, pero que comercie "con las manos".
No es posible. Aquellos que saben programar seguramente harán un asistente en MQL5 y pasarán sólo 1-2 semanas estudiando las operaciones de comercio en MQL5.
En cuanto al robot semiautomático, en unas horas haré un vídeo y os mostraré cómo es un robot automatizado moderno que puede trabajar en modo semiautomático como Asesor Experto.
Y no hace falta reinventar paneles complicados para ello, sino hacerlo muy sencillo para que sea más claro para todos.
Los usuarios de hoy en día están degradados por el grial del testering. Necesitan que se les empuje hacia un poco de complejidad y responsabilidad por sus actos. De lo contrario, una degradación completa de algotrading.
No veo otro futuro para el nicho de algotrading. Sinceramente, no veo...
Tanto patetismo... veo manos levantadas de pena ;)))
A ti, Petya, te encanta el papel de mesías.
Todo el mundo se degrada... a qué viene el mundo... tu misión, tu destino es conducir a una humanidad degenerada hacia un futuro brillante de algotrading. Aquí ya hay un diagnóstico. De la cabeza...
Petya, no te hagas el tonto.
Hay algo en mql oop que personalmente no me gusta. Cualquier objeto "vacío" ocupa 16 bytes. Además, su puntero ocupa 8 bytes. En total, 24 bytes por cada elemento, sin contar los datos. Si, en cambio, haces una matriz de propiedades, puedes sustituir un objeto "vacío" por 6 ints, cada uno de los cuales puede almacenar casi cualquier cosa, excepto cadenas (para el tiempo o el precio, un int es suficiente en el 99% de los casos)
Y la operación de conversión de tipo dynamic_cast no es barata en términos de velocidad. Así que el método del topicstarter (no lo he visto, claro, pero teóricamente) puede funcionar más rápido y ocupar menos memoria que el analógico con OOP.
Ilya Malev:
Así que el método de topikstarter (no lo he visto, por supuesto, pero teóricamente) puede funcionar más rápido y ocupar menos memoria que los análogos OOP.
No puede, el "núcleo" del topicstarter es una matriz de cadenas de inmenso tamaño, y hablar de eficiencia de tal enfoque es poco realista, incluso teóricamente.
Y la operación de conversión de tipo dynamic_cast no es barata en términos de velocidad. Así que el método del topicstarter (no lo he visto, claro, pero en teoría) puede funcionar más rápido y ocupar menos memoria que su análogo OOP.
Así que nadie discute que el acceso directo a una enorme matriz global es más rápido que todos estos artificios de la interfaz y las conversiones de tipo. También podemos pensar en los patrones de diseño, por ejemplo, Visitante con doble envío - hay una gran cantidad de sobrecarga allí.
Sin embargo, todo esto se compensa con la comodidad de la asistencia y la modificación. Desgraciadamente, la máxima transferencia de cualquier esfuerzo de pensamiento al ordenador ha sido la corriente principal de desarrollo de la programación durante mucho tiempo. Llega a un punto en el que la suma de una progresión aritmética se calcula mediante un bucle en lugar de utilizar la conocida fórmula de la suma. En ese sentido, estoy de acuerdo con Peter en que la gente es "degradante".
Pero, por desgracia, no hay elección: o te "degradas" con todos los demás, intentando no hacerlo tan rápido, o te quedas irremediablemente atrás. Y el hecho de que su programa sea ineficaz tiene poca importancia.
Aquí veo incluso una analogía con la competencia en biología, en las relaciones entre el depredador y la presa. La liebre, que huye del lobo, en realidad no compite con el lobo, sino con otras liebres. No necesita alejarse del lobo lo más rápido posible. Es mucho más importante escapar del lobo que ser el último. Porque si es el último en huir - será comido, pero si huye más rápido que todos los demás - gastará más energía de la necesaria, y ésta puede ser gastada en direcciones más útiles.
Lo mismo ocurre con todo tipo de tecnologías de programación... La forma más eficiente de programar en ensamblador, pero requiere tanto esfuerzo que no tiene sentido - la energía se gasta mejor de forma más productiva, incluso si el código no es tan eficiente en eso. La matriz de Peter con acceso global es del mismo tipo. Acceder a ella es eficiente, pero recordar qué hay y cómo acceder a qué requiere demasiado esfuerzo.
No puede, el "núcleo" en el topicstarter es un conjunto de cuerdas de inmenso tamaño, y es poco realista, incluso teóricamente, hablar de la eficacia de tal enfoque.
¿Es realmente un conjunto de cadenas o es una forma de hablar? Si los datos están representados por cadenas mql (string), no hay realmente ninguna posibilidad...
Acceder a ella es eficiente, pero recordar qué hay y cómo acceder a ella cuesta demasiado.
Cuando el "núcleo" esté listo, puedes dedicar una cantidad relativamente pequeña de esfuerzo a pegar en él una interfaz cómoda que resuelva todos los problemas de presentación y acceso "torpe" a la información. Aunque esto es una charla ociosa, según tengo entendido, TC no ha publicado sus códigos y quién sabe si están en la naturaleza :) ¿O los ha publicado? Honestamente, no pude pasar las 38 páginas
Además, un método que se limita únicamente a las "semiautomáticas" no tiene valor por definición. Aunque puede ayudar a ocupar un nicho local y limitado en el mercado de productos y autónomos