Errores, fallos, preguntas - página 257
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
No lo parece.
Resulta que sólo hubo 2 (de 45) operaciones perdedoras, ambas de compra.
¿Quizás estoy buscando en el lugar equivocado?
Marcado en rojo: las posiciones cortas son 5 de 45. Supongamos que el 40 es el 95%. Pregunta - Por qué 5 = 100%, es lógico suponer - 5%.
Aunque me parece que en este caso deberían ser 5 (11,11%) y 40 (88,89%).
Prueba a borrar la caché. Probé diferentes opciones, diferentes navegadores - la adición fue exitosa.
Estás insertando una imagen directamente en un comentario y no como un atach, ¿no es así?
Marcado en rojo: las posiciones cortas son 5 de 45. Digamos que el 40 es el 95%. Pregunta - Por qué 5 = 100%, es lógico suponer un 5%.
Aunque me parece que debería haber 5 (11,11%) y 40 (88,89%) operaciones.
Un total de 45 operaciones:
Aquí tenemos los siguientes resultados
5 Operaciones de venta - 5, y el 100% de ellas fueron rentables (no perdedoras) (es decir, todas las operaciones fueron rentables).
Operaciones de compra - 40, 38 de ellas son rentables, es decir, 38*100%/40=95%.
Más información en
Operaciones rentables: 43 de 45, es decir, 43*100%/45 = 95,56%.
Operaciones con pérdidas - 2 de 45, es decir, 2*100%/45 = 4,44%.
Un total de 45 operaciones:
El número total de acuerdos que tenemos
Venta de negocios - 5, de los cuales, negocios ganadores (no perdedores) - 100% (es decir, todos fueron rentables)
Operaciones de compra - 40, 38 de ellas son rentables, es decir, 38*100%/40=95%.
Más información en
Operaciones rentables: 43 de 45, es decir, 43*100%/45 = 95,56%.
Operaciones con pérdidas - 2 de 45, es decir, 2*100%/45 = 4,44%.
He notado este efecto. Al añadir el indicador al gráfico(en una ventana separada), el gráfico de velas principal deja de actualizarse (el precio se congela), aunque en la ventana con las cotizaciones todo está bien - el precio cambia de rojo a verde. Aunque el indicador se ha añadido sólo a la ventana de un símbolo, el precio también se congela en la otra ventana. La inicialización y el cálculo del indicador están dentro del cuerpo: if(prev_calculated==0). Los precios de cierre que no parten del día anterior participan en el cálculo (el precio de cierre actual no participa). Una vez completado el cálculo del indicador, el precio comienza a moverse y a cambiar de forma sincronizada con la ventana.
Se puede ver en la imagen:
He notado este efecto. Al añadir el indicador al gráfico(en una ventana separada), el gráfico de velas principal deja de actualizarse (el precio se congela), mientras que en la ventana con las cotizaciones todo está bien - el precio cambia de rojo a verde. Aunque el indicador se ha añadido sólo a la ventana de un símbolo, el precio también se congela en la otra ventana. La inicialización y el cálculo del indicador están dentro del cuerpo: if(prev_calculated==0). Los precios de cierre que no parten del día anterior participan en el cálculo (el precio de cierre actual no participa). Una vez finalizado el cálculo del indicador, el precio comienza a moverse y a cambiar de forma sincronizada con la ventana.
Se puede ver en la imagen:
El primer cálculo resulta ser muy intensivo en recursos. Compruébelo, tal vez el código del indicador no está escrito de la manera más óptima.
El primer cálculo resulta ser muy intensivo en recursos. Compruebe si el código del indicador no está escrito de la manera más óptima.
Me refería a que es posible separar la actualización de las cotizaciones en el gráfico de velas en un flujo de programa separado y la carga de los cálculos de los indicadores en otro flujo.
La actualización de las cotizaciones en el gráfico es sólo una visualización de los datos de la base de datos del terminal, que también se utiliza para calcular los indicadores. Para ahorrar recursos, los datos de base del terminal se pasan al indicador como datos de entrada, es decir, no pueden modificarse hasta que se calcula el indicador.
Estimado alexvd, desafortunadamente el Indicador tiene ahora más de 3000 líneas de código que consisten en más de 20 clases y es bastante difícil optimizar el código (varios cientos de billones de operaciones computacionales en bucles), mientras que este número puede crecer hasta 10000 aproximadamente. Me refería a que es posible separar de alguna manera la actualización de las cotizaciones en el gráfico de velas en un hilo de programa separado y la carga de los cálculos de los indicadores en un hilo separado. Francamente, cuando empecé a trabajar, no esperaba que el problema de rendimiento fuera tan grave en un ordenador de sobremesa, mientras que yo también quiero utilizar un pequeño portátil.
Intenta optimizar el indicador, el número de objetos y líneas no es importante. Lo más probable es que se pueda hacer funcionar el indicador existente (con 3000 líneas) con la velocidad necesaria.
Una variante interesante es poner todos los cálculos que consumen muchos recursos en un temporizador (si parece que es posible), entonces estos cálculos no se realizarán en cada tick.
Y me gustaría optimizar al máximo la caja de la calculadora (dentro de unos límites razonables).
Intenta optimizar el indicador, el número de objetos y líneas no es importante. Lo más probable es que se pueda hacer funcionar el indicador existente (con 3000 líneas) con la velocidad necesaria.
Una variante interesante es si ponemos todos los cálculos que consumen muchos recursos en un temporizador (si es posible), entonces estos cálculos no se realizarán en cada tick.
Y el bloque de la calculadora debe optimizarse al máximo (dentro de unos límites razonables).
En principio, es posible optimizar un poco el trabajo, porque algunos datos idénticos se calculan en objetos de diferentes clases, es decir, no una vez. Pero aquí nos enfrentamos a otro problema, a saber - alejarse del concepto de muchas cajas negras, cada una de las cuales puede ser depurada y tener confianza en ella (es decir, cada objeto es una unidad totalmente autónoma, y si el cálculo de algunos datos intermedios, que es idéntico en diferentes objetos, se mueven fuera de los objetos, la autonomía se perderá, permitiendo depurar cada clase por separado. En este caso se perderá la estructuración del programa, es decir, no podré entender lo que he escrito y un mínimo error será imposible de detectar. La velocidad de depuración también aumentará drásticamente, ya que tendré que ejecutar todo el algoritmo en lugar de sólo una parte. Así es como el número de objetos influye en la velocidad.
Por eso creo que una optimización similar puede intentarse en la etapa final, cuando el indicador esté completamente creado, depurado y probado, pero desgraciadamente aún falta mucho (llevo trabajando en la etapa inicial unos 4 meses, desde que por fin me di cuenta de que estoy preparado para probarlo). En los libros de Econometría y Matemáticas todo está disperso en fragmentos en diferentes libros (no hay una presentación del material prácticamente unificada en detalles), los autores tienen errores y discrepancias en los términos y algoritmos, que son encontrados por los principiantes sólo cuando se refieren a los diccionarios enciclopédicos, la información teórica entra en conflicto con la posibilidad de su realización práctica, es decir, la realización en forma de métodos numéricos, y los métodos numéricos mismos a su vez hacen demandas a la funcionalidad del entorno de software), el proceso es largo tedioso y viscoso.
Según la lógica del cálculo, debe producirse después de la formación de cada vela, por lo que originalmente debía colocarse en el cuerpo de la función "is new bar", pero el hecho de que su tiempo pueda superar este intervalo me hizo colocarlo en el cuerpo de la función if(prev_calculated==0) para que se produjera sólo una vez en la fase de depuración. Pensaré en tu sugerencia del temporizador - gracias.