Ayúdame a aprender a programar. - página 3

Nuevo comentario
 
Tio Nisla:
Quería añadir antes que si la función somebodyfunc() hace algunas otras manipulaciones además de devolver alguna cantidad o algo, calcula parámetros comerciales, por ejemplo, tal uso causa artefactos difíciles de atrapar y podría llevar al autor de un código a un estupor: "¿Ht? ¿Cómo es que 4 veces? ¡¡¡O_o F$#@!!! ¿No se supone que está ahí tres veces? ¿Por qué me miente mi EA?". Eso es lo que yo llamaba "shithcod", que un experto se escandalizaba hasta las raíces del pelo. No lo he sacado a relucir, porque es obvio, pero tú lo has hecho por mí. Pero no has tenido en cuenta que el direccionamiento por un índice calculado dinámicamente sin reinicialización del array es otra cosa. En sys desnudos esto suele llevar a GPF, en pluses con punteros y arrays inteligentes a una excepción y su manejador. En mql no está claro a qué conduce.

¿Qué son los "artefactos escurridizos"? ¿Es algo religioso? ¿Te lo inventas y te lo crees?

 
Aleksandr Slavskii:

Señores, personalidades, pero averigüemos la verdad.

Veo en el ejemplo quese llama aPositionsTotal()en cada iteración del bucle.

Pero Dimitri, por el contrario, estás diciendo que el compilador lo hace de una manera diferente - no lo entiendo. Explícate.

Si quieres decir que la funciónPositionsTotal() no recalcula las posiciones cada vez, sino que simplemente devuelve el valor de una variable que contiene el número de posiciones abiertas, entonces sí, tienes razón, no tiene sentido declarar una variable más, pero entonces ¿qué tiene que ver el compilador?

Y si esta función recalcula las posiciones abiertas cada vez, entonces resulta que el compilador tiene que entender si el valor de esta función afecta a los cálculos posteriores y utiliza una función o una variable.

Parece que no lo consigo.

Se recalcula cada vez o no se recalcula, pero la llamada de PositionTotal() es definitivamente costosa. Y esto se demuestra fácilmente con un simple experimento. Pero en lugar de dar un experimento asesino que me haga pedazos, vienen con argumentos extravagantes con "artefactos difíciles de encontrar". Puedes encontrar ese código de ejemplo desde la primera página ya sabes dónde y ver cómo se ve allí))) Se cambió deliberadamente antes de pegarlo en el foro (gran aplauso). Y se hizo sólo para evitar la carga innecesaria de un principiante.

Y el compilador, me refería a que optimiza el código y llama a la variable directamente en lugar de a través de una función:

int x;

for(;i<x;)

и

for(;i<F();)

int F(){return(x);}

Esto se puede ver claramente con la función ArraySize(); no se puede distinguir entre llamar a una función y utilizar una variable con ella. Pero con PositionsTotsl() este no es el caso, por desgracia.

Por cierto, también se puede llegar al fondo de la declaración de variables dentro de un bucle, lo que también reduce la velocidad. ¿Qué es lo que no llega a la mordida? ¿No lo sabes? Aunque aquí también podemos discutir, hay una diferencia entre el 4 y el 5.

 

¿Seguro que PositionsTotal() pide el número de posiciones abiertas cada vez? ¿O tal vez está optimizado y guarda el valor en una constante con una marca de actualización y sólo devuelve siempre el mismo número si no cambia)?

Debe haber alguna optimización interna de esta función. Los desarrolladores no son tontos para hacer una función tan importante y potencialmente costosa por "lo que hará de todos modos".

Los que se indignan, por favor, comprueben cuánto tiempo y recursos se necesitan para realizar las dos variantes del mismo bucle.

No hay necesidad de tirar caca.


Me gustaría ver el código fuente de PositionsTotal() por puro interés académico.


Pues bien, si lo piensas, lo más sencillo sería hacer una variable global del terminal almacenando este valor. Y devuelve sólo este valor. Y actualizarla al abrir o cerrar posiciones - para que la variable sea segura y se sincronice, para que Dios no quiera que se escriba algo allí.

Creo que así es como se hace.

Bueno, los datos sobre las propias posiciones probablemente se almacenan en algunas estructuras de datos, de modo que era posible obtenerlos sin recurrir a los servidores innecesariamente. En general creo que ahí todo es normal con la productividad en cualquier variante de convocatoria/.


Y el estilo del código es estéticamente bonito o no, cada uno decide por sí mismo)

 
Nikolay Mitrofanov:

Quien se escandalice, que compruebe cuánto tiempo y recursos se necesitan para ejecutar las dos variantes del mismo ciclo.

No hay necesidad de tirar caca.

Espero que no fuera dirigido a mí, porque no dudo de la autoridad de Dimitriy.Tio Nisla tampoco hasido codificado por primera vez, pero


Estoy aprendiendo, por eso pregunto.

 

PositionsTotal() es complicado, debe devolver siempre el número correcto, y cambiar su valor en cuanto cambie el número de posiciones. Por lo tanto, es poco probable que sea tan rápido como una simple variable o ArraySize().

 
Aleksandr Slavskii:

...


Estoy aprendiendo, por eso pregunto.

Si estás aprendiendo, no te dejes llevar por estas pequeñas cosas en absoluto. Concéntrese en la capacidad de traducir su idea en código (o algún proceso mal definido en una secuencia de acciones). Y luego el código se puede retocar como se quiera.

 
Dmitry Fedoseev:

Si estás aprendiendo, no te preocupes en absoluto por estos detalles. Concéntrese en ser capaz de traducir su idea en código (o algún proceso mal definido en una secuencia de acciones). Y luego el código se puede retocar como se quiera.

Creo que es bueno que una persona intente entenderlo y profundice.

Al no prestar atención a las pequeñas cosas, el programador adquiere el hábito de escribir el código a su antojo. Y luego, peinar el código supone un doble trabajo y, a menudo, no sólo para el autor, sino para los que todavía tienen la suerte de trabajar con el código.

¿Por qué molestarse en escribir código cuando se puede hacer correctamente y escribirlo bien y entender los detalles?)

Su consejo es... bueno... IMHO


Su consejo es bueno para un programador con experiencia (fuertemente seguro de sí mismo) que luego puede limpiar, porque sabe dónde y qué hay que limpiar.

 
Nikolay Mitrofanov:

Para mí, creo que es bueno que una persona intente comprender y profundizar...

Al no prestar atención a los pequeños detalles, el programador adquiere el hábito de escribir código de forma incorrecta. Y luego, peinar el código supone un doble trabajo y, a menudo, no sólo para el autor, sino para los que todavía tienen la suerte de trabajar con el código.

¿Por qué molestarse en escribir código cuando se puede hacer correctamente y escribirlo bien y entender los detalles?)

Su consejo es... bueno... IMHO


Su consejo es bueno para un programador con experiencia (fuertemente seguro de sí mismo) que luego puede peinar, porque sabe dónde y qué hay que peinar.

Para los principiantes más - es mejor por lo menos de alguna manera, pero para resolver un problema, en lugar de quedarse atascado en un nivel de discusiones en el foro como "cómo se puede escribir aquí sin const, y aquí sin estática, etc., etc. o - oh hombre, si usted hace esta pregunta, entonces es mejor no acercarse a la programación en absoluto".

No pasa una semana sin que alguien me envíe un indicador para arreglar algún código como este: for(int i=0;i<Bars;i++). Y aquí se frotan los problemas, lo que puede dar velocidad... Bueno, el 30%.

Incluso los EAs eficientes (en el sentido de la velocidad de las pruebas) son problemas de su algoritmo, que cada vez renace para cada estrategia específica, más que un problema de complejidades sintácticas.

 
Dmitry Fedoseev:

Para los principiantes más - es mejor resolver el problema por lo menos de alguna manera, en lugar de quedarse atascado en un nivel de discusiones del foro como "cómo se puede escribir aquí sin const, y aquí sin estática, etc., etc. o - oh hombre, si usted hace esta pregunta, entonces es mejor no acercarse a la programación en absoluto".

No pasa una semana sin que alguien me envíe un indicador para arreglar algún código como este: for(int i=0;i<Bars;i++). Y aquí se frotan los problemas, lo que puede dar velocidad... Bueno, el 30%.

Si un programador novato pregunta algo en el foro, significa que quiere saber la respuesta, significa que está interesado y lo necesita. Incluso he creado un hilo para pedir consejo.

Si entendí bien el tema, la cuestión de la aplicación de su idea no era "hacerlo bien pero que funcione" sino lo mejor y más correctamente posible. Eso es bueno. Así es.

"Sólo de alguna manera" para cualquier actividad es un enfoque terrible.

Primero, averiguar, y luego hacerlo con conocimiento de causa: el mejor enfoque.

 
Nikolay Mitrofanov:

Si un programador novato pregunta algo en el foro, significa que quiere saber la respuesta, significa que está interesado y lo necesita. Incluso creó el hilo para pedir consejo.

Si he entendido bien al autor del hilo, la cuestión de la aplicación de su idea ya no es "hacer lo que se quiera para que funcione", sino inmediatamente lo mejor y más correcto posible. Eso es bueno. Así es.

"Sólo de alguna manera" para cualquier actividad es un enfoque terrible.

Lo mejor es entender primero y luego hacer con el conocimiento.

¿Con conocimiento de qué? Si este algoritmo no existe en la naturaleza, sino que hay que inventarlo uno mismo, y es el algoritmo el que lo define todo.

12345678910...13
Nuevo comentario