Implementaciones alternativas de funciones/enfoques estándar - página 12
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
¡Vaya! ¡Genial! Gracias. Y pensé: siempre cuenta. Sí, bueno, es lógico, ya se puede calcular en tiempo de compilación.
Entonces, así:
Pero sería más correcto escribirDBL_MANT_DIG en lugar de 53.
Caso de ganancia mínima, si todos los valores del doble son fraccionarios.
1. Su implementación es incompleta, sólo se puede utilizar si se conoce de antemano el rango de valores posibles.
Este es el código de la implementación completa
2. Las funciones autoescritas son significativamente más lentas que las funciones incorporadas cuando se compilan para la depuración, cuando las optimizaciones están desactivadas.
1. Su implementación es incompleta y sólo puede utilizarse si se conoce de antemano el rango de valores posibles.
Este es el código para la implementación completa
2. Las funciones autoescritas son mucho más lentas que las incorporadas al compilar para la depuración cuando las optimizaciones están desactivadas.
Muchas gracias, Ilyas, por el excelente código.
Por supuesto, es una gran ayuda aquí.
Lo estoy estudiando.
ZS ¿No es esta versión exactamente igual?Nikolai, hola. Veo que estás trabajando en los gráficos, pero no entiendo muy bien cuál es la tarea actual. ¿En qué estás trabajando?
¿Acelerar las funciones de renderizado?
En general, sobre el tema del hilo, he logrado implementar un enfoque completamente alternativo para dibujar en el lienzo. Sin utilizar la clase CCanvas.
Es decir, no modificar un conjunto de funciones por separado, sino crear un mecanismo de dibujo completo, que consiste en un solo bloque.
(Por supuesto, apenas puedo demostrar todo esto en el código, ya que hay mucho código y está escrito de forma no estándar, pero me gustaría contarlo en general).
Así que:
1. el bloque (función)
sólo acepta 2 parámetros: Kanvas y Elemento.
2. Cada objeto MT tiene asignado su propio recurso. Se carga inmediatamente en la "matriz de píxeles" utilizando ResourceReadImage(); si el recurso no existe todavía, se pone una bandera, que posteriormente determinará el alcance del ciclo sobre el núcleo.
3. el núcleo, que es una matriz de propiedades de todos los elementos. Contiene datos sobre los tamaños de los objetos y los colores de los diferentes estados. Y muchos otros datos. Hay 235 propiedades en total para cada objeto. Al mismo tiempo, cada elemento (dependiendo del tipo) puede contener de uno a 11 objetos (no hay limitación).
4. En el bloque Dibujo, cada objeto implica un "Detalle" del dibujo. Por lo tanto, el ciclo por objeto en el núcleo, es un ciclo de dibujo en el que se crea la imagen de cada Detalle. Si un lienzo aún no ha sido creado, se realiza un ciclo completo en todos los detalles de ese lienzo solamente. La afiliación a los Kanvas se prescribe en el núcleo, para cada Detalle. Es decir, todos los Kanvases, (y Partes) tienen sus propios números de secuencia. A través de estos números es posible dibujar el contenido de sólo los Kanvas requeridos.
4. Si un Kanvas ya existe y su imagen está cargada en un array de píxeles, y sólo necesitamos redibujar un único elemento (en un evento de cambio de color, por ejemplo), entonces el rango del bucle central se reduce a los límites del único elemento cuyo número fue obtenido por la función de dibujo.
El dibujo en sí es sencillo. Es un ciclo a través de las celdas de un array unidimensional de izquierda a derecha. Antes de fijar el ciclo:
1. La célula inicial (punto A).
2. La célula final (Punto B).
3. Pasen por encima.
Es difícil resumir el funcionamiento de un bloque de 1500 líneas de código en pocas palabras. Se trata de una función que ha ido creciendo y puliéndose durante 20 meses. Me lo sé casi de memoria, lo que hace que sea fácil seguir desarrollándolo.
Utilizando el núcleo y el foco (poniendo las variables importantes en el ámbito global), el bloque adquiere enormes posibilidades. Sus límites no son visibles para mí hasta el día de hoy.
Así que esa es la alternativa al enfoque estándar de dibujo de kanvas.
zy. Si está interesado en los detalles, puedo explicarlo.
Así es como se ve el comienzo del bloque:
1. Su implementación es incompleta y sólo puede utilizarse si se conoce de antemano el rango de valores posibles.
Este es el código para la implementación completa
Gracias una vez más por el código. He estado desconcertando con estas máscaras de bits como el doble. Resulta que no es tan fácil como pensaba antes.
He ajustado ligeramente mi versión a la tuya. Sólo había una diferencia: tu versión devolvía en los valores -1>x>0 Ceil(-0,1)= - 0,0, mientras que la mía devolvía 0,0. Aunque no sé cuándo puede ser útil.
Y se obtiene lo siguiente:
Lo mismo, sólo que legible y con comentarios:
He escrito un script (adjunto), que confirma al 100% la identidad con tu versión.
Pero esta variante es más rápida, más compacta y, en mi opinión, más legible.
Observe que no se crea ni una sola variable en el cuerpo de la función, mientras que su versión crea 4 variables de 8 bytes.
¿Tal vez me equivoque?
Resultados cuando la entrada x siempre tiene una parte fraccionaria:
Los resultados cuando la entrada x tiene una parte fraccionaria son raros:
2. Las funciones autoescritas son significativamente más lentas que las incorporadas al compilar para la depuración, cuando las optimizaciones están desactivadas.
No está claro por qué se necesita la velocidad al depurar.
Pero si realmente lo necesitas, puedes utilizar la construcción:
Y hay otra cosa que no entiendo:
¿Por qué la documentación y el DBL_MANT_DIG real son iguales a 53?
como según la misma Wikipedia= 52.
Y, como, se deduce de su código que 52 también ?
Nikolai, hola. Veo que estás trabajando en los gráficos, pero no entiendo muy bien cuál es la tarea actual. ¿En qué estás trabajando?
¿Acelerar las funciones de renderizado?
¡Hola Piotr!
Le responderé en persona.
Y hay otra cosa que no entiendo:
¿Por qué la documentación y el DBL_MANT_DIG real son iguales a 53?
mientras que según la misma wikipedia= 52.
Y parece que su código también implica que es 52 ?
¿Ha intentado encontrar usted mismo la respuesta a la pregunta?
Sugerencia: En la búsqueda de Google, escriba "DBL_MANT_DIG 53 52".