Paradoja de NormalizarDoble - página 2
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
La ruptura del patrón es que, incluso después de la normalización, ¡todavía hay colas!
No hay colas después de la normalización... No engañes a la gente.
No entro en .... pero tengo
la situación es la siguiente: normalizo un número al doble, lo escribo en una variable global del terminal, luego lo leo, lo vuelvo a normalizar y ¡obtengo cruz!
finalmente - no tengo poder para atrapar estas colas - simplemente las corté a la fuerza usando DoubleToStr(current,2)
No entro en .... pero tengo
la situación es la siguiente: normalizo un número al doble, lo escribo en una variable global del terminal, luego lo leo, lo vuelvo a normalizar y ¡obtengo cruz!
como resultado - no hay fuerza para atrapar estas colas - Acabo de tomar y cortarlas a la fuerza usando DoubleToStr(current,2)
Si normalizas la variable double, por ejemplo, a 5 caracteres, entonces la variable almacenará 5 caracteres, en el caso de raprinters y demás, conviertes la variable a un tipo de datos diferente, lo que puede provocar colas.
Pero no hay cola en el doble después de la normalización...
Para que no se produzca un fallo, es necesario hacer la normalización en los puntos de aplicación, en el curso de los cálculos...
Si se normaliza una variable doble a 5 dígitos por ejemplo, la variable almacenará 5 dígitos, en caso de reimpresión y otras cosas se convierte la variable a otro tipo de datos y puede aparecer una cola como consecuencia.
pero no hay cola en el doble después de la normalización...
Para que no se produzca un fallo, la normalización debe hacerse en los puntos de aplicación, no puede hacerse en el curso de los cálculos...
¿entonces puede dar colas exactamente durante esta conversión?
no sabía
Gracias.
Es decir, si hago, por ejemplo, una transformación de
entonces podría dar colas precisamente en este proceso de conversión?
no lo sabía.
Gracias.
NormalizeDouble funciona exactamente así (y siempre ha funcionado así desde el primer MQL)
El número se multiplica por 10 a la potencia de los dígitos, se convierte en forma de número entero (descartando la parte fraccionaria), y luego se divide por 10 a la potencia de los dígitos
¿Cuál es el problema aquí? ¿Hay una ruptura del patrón?
¿Se tira la parte fraccionada? El redondeo se realiza mediante.
NormalizarDoble(1,25,1) = 1,3
¿Se descarta la parte fraccionaria? Se realiza el redondeo.
NormalizarDoble(1,25,1) = 1,3
Así que si hago, por ejemplo, una conversión
entonces podría dar colas precisamente en este proceso de conversión?
no lo sabía.
Gracias.
La verdad es que no. Sistema binario = sistema decimal. Los decimales binarios son 0,5 / 0,25 / 0,125 / 0,0625 / 0,03125, etc. No es posible sumar todos los dígitos decimales de estos ladrillos. Por ejemplo, es imposible juntar un número decimal 0,3 exactamente (sólo se puede juntar un valor aproximado), en el sistema binario será un poco menos o un poco más. Así es como aparece esta cola.
Sólo los números divisibles sin resto por 1/2^cada potencia se representan con exactitud.
En otras palabras, distorsionamos los números cuando intentamos representar los números decimales en forma binaria.
Estamos acostumbrados a que para no escribir exactamente el resultado de una operación 1/3 habrá que redondear. Pero en el sistema ternario hay una representación exacta de la operación == 0,1. Si nuestro sistema nativo fuera ternario y el pc trabajara con decimal, nos sorprendería la basura en bits al convertir de nuevo a ternario el número 0,1troico.
Una analogía así:
Estamos acostumbrados a no escribir exactamente el resultado de una operación de 1/3 que tenemos que redondear. Pero en el sistema ternario hay una representación exacta de la operación == 0,1. Si nuestro sistema nativo fuera el ternario y el pc trabajara con el decimal, nos sorprendería la basura en bits al convertir de nuevo a ternario el número 0,1troico.
Es cierto.
Pero por alguna razón, incluso una calculadora de céntimos puede leer un número de la memoria y devolver exactamente lo que estaba escrito allí.
Se escribe una fracción 1,23 y se obtiene exactamente 1,23 sin colas.
Y aquí está el truco.
en teoría, el usuario debería estar libre de una rutina como la de presentar el número en formato binario
<Modo de perforación desactivado>.