Implementaciones alternativas de funciones/enfoques estándar - página 13
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
Este es el aspecto del principio del bloque:
Por lo que he entendido, has creado tu propio lenguaje de interpretación.
¿Así?
Otra pregunta tonta:
¿Cada ventana generada con diferentes elementos es un recurso o muchos?
Aunque, una mejor analogía sería probablemente HTML
Como he dicho antes, tu hijo necesita un constructor gráfico. Algo como lo de Andrei Barinov.
Además, tus videoclips son demasiado largos. Hay que reducirlos de 45 minutos a 5 minutos, o incluso mejor, a 3 minutos.
¿Ha intentado encontrar usted mismo la respuesta a la pregunta?
Sugerencia: En la búsqueda de Google, introduzca "DBL_MANT_DIG 53 52".
Sí, gracias. Lo encontré.
1. Por lo que he entendido, has creado tu propio lenguaje de interpretación.
¿Así?
Y una pregunta tonta:
¿Cada ventana generada con diferentes elementos es un recurso o muchos?
Aunque quizás una mejor analogía sería el lenguaje HTML.
Como he dicho antes, tu idea necesita un constructor gráfico. Algo como lo de Andrei Barinov.
Además, tus videoclips son demasiado largos. De los 45 minutos deberían reducirse a 5 minutos, o incluso mejor, a 3.
1. Sí, resulta que la definición de "intérprete" se adapta mejor a lo que he creado (aunque en el proceso de creación no tenía ni idea de lo que es).
2. Cada ventana formada consta de varios kanvases (recursos). Los dos primeros son de plataforma Windows. Antes utilizaba un método de dibujo diferente y por eso algunas partes eran semitransparentes y se podía ver el gráfico a través de ellas. Para evitarlo he añadido otro kanvas en el fondo. Entonces la técnica ha mejorado, pero el lienzo queda en segundo plano. Ha crecido en la tecnología y ahora es difícil deshacerse de ella. Pero al final lo quitaré y la plataforma de la ventana consistirá en un solo lienzo.
Además, los "campos" (pestañas de imágenes intercambiables), son lienzos independientes. Contienen imágenes ya hechas y, por tanto, cambian lo más rápidamente posible. Si dibujara todo en un solo lienzo, inevitablemente el cambio de imagen sería más lento. Tendría que volver a dibujar todo de nuevo. De todos modos, después de pensarlo, he llegado a la conclusión de que esta es la mejor opción.
3. Visual Constructor era, y sigue siendo, mi objetivo. Estoy muy cerca del comienzo de su aplicación. Hay una comprensión de su estructura. Existen todos los conceptos necesarios para su aplicación. Sé cómo hacerlo. Todo lo que necesito es tiempo.
ZS. La peculiaridad de mi desarrollo es la espontaneidad. No estaba familiarizado con los interpertores ni con el lenguaje HTML, y no sabía cómo funcionaban. Sin embargo, eso no me impide crear y hacer cosas similares. Creo que si funciona bien, seguiré haciéndolo. :)
A primera vista, parece que tiene un uso muy derrochador de la memoria. Sin embargo, puedo estar equivocado.
Lo ideal es que su tarea tenga sólo un lienzo que admita la transparencia sobre el gráfico de precios.
El rendimiento de MQL5 debería ser suficiente para formar toda la interfaz sobre la marcha sin tener bloques listos en la memoria, si la codificación es correcta.
Aunque no excluyo la posibilidad de sacrificar recursos de memoria para aumentar el rendimiento de las interfaces engorrosas.
Veo una gran ventaja en su enfoque hasta ahora:
Será más fácil para ti crear un constructor gráfico completo, ya que es más fácil generar código de marcado que el propio código MQL.
Pero es una tarea elefantiásica.A primera vista, parece que tiene un uso muy derrochador de la memoria. Sin embargo, puedo estar equivocado.
Lo ideal es que su tarea tenga sólo un lienzo que admita la transparencia sobre el gráfico de precios.
El rendimiento de MQL5 debería ser suficiente para formar toda la interfaz sobre la marcha sin tener bloques listos en la memoria, si la codificación es correcta.
Aunque no excluyo la posibilidad de sacrificar recursos de memoria para aumentar el rendimiento de las interfaces engorrosas.
Veo una gran ventaja en su enfoque hasta ahora:
Será más fácil para usted crear un constructor gráfico completo, ya que es más fácil generar código de marcado, no el código MQL en sí.
Pero es una tarea elefantiásica.Todavía hay un exceso de memoria relativamente pequeño. Tienes razón. Los objetos de los elementos, como el texto o el icono, reciben "inmerecidamente" un número de 235 propiedades en el núcleo, mientras que sus propias propiedades son varias veces menores. El objeto elemento principal, es decir, la base, debe tener las 235 propiedades, pero los objetos icono y texto tienen menos propiedades. Esto crea un exceso de memoria.
La idea es que si añado otras 60 celdas a la fila de objetos de elementos principales, puedo poner en ellas propiedades de texto e iconos. Esto haría que el núcleo fuera más "ancho", pero podría eliminar dos tercios de los objetos.
Habría un excelente ahorro de memoria y una ganancia en la velocidad de construcción del núcleo. Sin embargo, esto es técnicamente difícil de aplicar. Hay mucho trabajo que hacer. Hasta ahora, el consumo de memoria y el tiempo de construcción son bastante aceptables. Pero la perfección no tiene límites...
Utilizar un solo lienzo no es una buena idea. Es mucho más fácil utilizar un lienzo para cada ventana y un lienzo para cada campo. El lienzo genérico necesita ser redibujado mucho más a menudo. Para cada cambio de imagen o cada cambio de ventana. En el desplazamiento... Hay que tener en cuenta que el rediseño no siempre es rápido. No está en los algoritmos, sino en la "sofisticación" de los gráficos. Déjeme explicarle:
Si dibujas una simple etiqueta rectangular (un cuadrado, por ejemplo), es un ciclo sobre una matriz de píxeles con las celdas adecuadas inicializadas con el valor correcto (color).
Si dibujas un cuadrado con un marco, son dos ciclos en una matriz de píxeles.
Si dibujas un cuadrado con un marco y un icono, son tres ciclos.
Si dibujas un cuadrado con un marco que tiene un gradiente de superficie y un icono que tiene una sombra, eso son cuatro o más ciclos en la matriz de píxeles.
Por lo tanto, cuanto más pronunciado sea el gráfico, más habrá que "planchar" esta serie de píxeles en ciclos, creando la imagen correcta. Por lo tanto, cuanto menos haya que redibujar, mejor.
Un solo lienzo para todas las imágenes, le hará redibujar todo continuamente. Por lo tanto, no es una buena solución.
ZS. La tarea es ciertamente elefantiásica, pero puedo hacerlo. (Aunque me ayudarán).
ZS. ¡Gracias por el vídeo, es inspirador! :)
¿Redimensiona la ventana con el ratón?
Si es así, ¿aparece un cuadrado rojo?
¿Se puede cambiar el tamaño de la ventana con el ratón?
Si es así, ¿aparece un cuadrado rojo?
No entiendo de qué plazas estamos hablando.
La ventana dinámica puede cambiar de tamaño con el ratón. ¿Cómo podría ser si no?
ZS: La ventana dinámica tiene inicialmente un tamaño de pantalla completo. Además, se "recorta" al tamaño deseado. Es decir, todo su dinamismo se realiza en el tamaño máximo del mapa de bits ya creado.
Para continuar con el tema del redondeo.
He descubierto que los procesadores Intel modernos que soportan el conjunto de instrucciones SSE4.1 ampliado tienen el comando de redondeoROUND{PS, PD} . Seguro que AMD tiene algo parecido.
https://ru.wikipedia.org/wiki/SSE4#SSE4a
http://o-ili-v.ru/wiki/SSE4
¿Significa esto que el compilador MQL5 no utiliza este comando a nivel de la CPU? Ya que mi procesador Intel Kaby Lake soporta este conjunto.
Y hay mucho más, incluso la multiplicación escalar de vectores.