Errores, fallos, preguntas - página 2637
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
¿tal vez comparado con la programación funcional?
Consulta la wikipedia:
Y descubrimos que no es lo mismo.
Así que todo es un procedimiento...
Puede que le sorprenda, pero los jóvenes programadores de hoy en día consideran que la programación OOP es más fácil que la programación procedimental.
Estás pensando en términos de hace 25 años. Los jóvenes de hoy absorben el OOP con la leche de su madre. Aprende OOP si quieres estar en la tendencia, de lo contrario no harás más que refunfuñar.
Pero realmente es así. Que los viejos programadores intenten resolver las tareas de la Olimpiada para escolares.
Lo que estudiaron antes en las universidades, asignaturas como programación dinámica, teoría de grafos, OOP, clases, etc. Los escolares actuales de 9-10 cursos (no todos, por supuesto) resuelven esos problemas en pocos minutos.
Y es natural. Ley de la naturaleza :)
Sí, entiendo de OOP, no en la medida que me gustaría, por supuesto.
Esto no es una queja sino una sugerencia constructiva.
Para que el desarrollador no tenga que escribir una función para asignar dos mallocs, obligan a los usuarios a aprender POO.
Por supuesto, es que el progreso y la popularización de la lengua. Bueno, aquí se puede ver cuánto aman y entienden la OOP.
Verás, Nikolay, todo lo que hay en el wrapper es código innecesario para ser ejecutado, no creo que haya que explicarlo.
No hace falta que te hable de los modernos compiladores de optimización: no sabemos qué instrucciones aplicarán.
Quizá también le sorprenda que incluso los programadores estadounidenses prefieran escribir en el estilo procedimental no porque la POO sea mala, sino porque el código es más sencillo y rápido.
Y si no hay tareas objeto en el proyecto, por qué utilizar wrappers, que de alguna manera deben ser entendidos, para los jóvenes))
Por eso no estoy de acuerdo contigo en que los jóvenes absorban con avidez la OOP.
Estoy pensando en C, que es donde se construye la lógica del lenguaje mql.
C nació en 1972, así que tiene 48 años ))
Pero de todos modos, C es uno de los lenguajes más rápidos. ¿Sabes por qué? Porque no tiene envolturas de clase.
Bueno, eso no es cierto en absoluto. Es que todavía hay muchos lenguajes en uso sin OOP. C, por ejemplo. En Canadá, por ejemplo, la mayoría de las instituciones gubernamentales están sentadas en Kobol y no pueden deshacerse de él.
https://www.tiobe.com/tiobe-index/
Roman, sinceramente, no entiendo por qué haces un escándalo sobre el cambio de las dimensiones de la matriz, qué dificultades puede haber con eso.
Para eso no se necesitan punteros ni OOP.
De todos modos, para un ordenador, una matriz de cualquier dimensión es una matriz unidimensional.
Entonces, trabaja con un array dinámico unidimensional. Y formar matrices virtualmente y redimensionarlas como quieras con la ayuda de funciones.
Por ejemplo algo como:
En la práctica, sólo utilizo matrices unidimensionales en mi código, aunque también trato con matrices multidimensionales sobre la base de las unidimensionales.
Por eso me gustaría pedirte que hicieras funciones como ArrayResize sólo para matrices ArrayResizeMx(A, n, m)
todo hecho, no quiere soluciones listas usando POO (no se requiere saber POO, ¡utiliza las listas!)
utilice ALGLIB , hay un método para redimensionar la matriz Resize().... pero todavía todo se hace por OOP ))))
SZS: busca en el foro, había muchas veces sobre este tema, había ejemplos, se puede envolver una estructura con un campo de matriz en una matriz de estas estructuras - será sin OOP, pero para mí todo parece engorroso
Estoy pensando en C, que es la base de la lógica de mql.
El lenguaje C nació en 1972, así que resulta que tiene 48 años ))
Pero de todos modos, C es uno de los lenguajes más rápidos. ¿Sabes por qué? Porque no tiene envolturas de clase.
No recuerdo el C puro, lo estudié en la uni hace tiempo, pero si no me equivoco, C no tenía arrays dinámicos como tal, pero se podía trabajar con punteros a memoria, y el trabajo de asignación de memoria y control de acceso a la misma recaía plenamente en el programador, que es esencialmente el mismo envoltorio
Vale, esto podría ser una gran discusión, no tiene sentido continuar.
Roman, sinceramente, no entiendo por qué te has hecho un lío con el cambio de las dimensiones de la matriz, qué dificultades puede haber con ello.
Para eso no se necesitan punteros ni OOP.
De todos modos, para un ordenador, una matriz de cualquier dimensión es una matriz unidimensional.
Entonces, trabaja con un array dinámico unidimensional. Mientras tanto, forme matrices virtualmente y cambie su tamaño a su antojo utilizando funciones.
Está claro que cualquier dimensión es un array unidimensional para el ordenador.
Se trata de la usabilidad del lenguaje. Si vemos la dimensión [][] en el código, podemos entender visualmente que es una matriz, no un array unidimensional.
La legibilidad del código es mucho mayor que adivinar lo que contiene [][].
Nunca pensé que me encontraría con tal falta de comprensión cuando me pidieron que añadiera una función sobre la asignación de memoria para las matrices.
Todos ustedes están usando ArrayResize, es conveniente y no se molestan con él. ¿Qué problema supone para un desarrollador escribir una función de asignación de memoria parauna matriz multidimensional?
Así es, no hay problemas ni obstáculos, y para los usuarios es conveniente organizar el código. Así que decidí portar una buena biblioteca de métodos numéricos en C a mql,
pero no tengo ninguna herramienta mql normal para eso. Una vez más hay muletas, lo que elimina todo deseo de construir un código ineficiente.
Entiendo de OOP, no tanto como me gustaría, por supuesto.
Esto no es una queja sino una sugerencia constructiva.
Para que el desarrollador no tenga que escribir una función para asignar dos mallocs, obligan a los usuarios a aprender POO.
Por supuesto, es que el progreso y la popularización de la lengua. Bueno, aquí se puede ver cuánto aman y entienden la OOP.
Verás, Nikolay, todo lo que hay en el wrapper es código innecesario para ser ejecutado, no creo que haya que explicarlo.
No hace falta que te hable de los modernos compiladores de optimización: no sabemos qué instrucciones aplicarán.
Quizá también le sorprenda que incluso los programadores estadounidenses prefieran escribir en el estilo procedimental no porque la POO sea mala, sino porque el código es más sencillo y rápido.
Y si no hay tareas objeto en el proyecto, por qué utilizar wrappers, que de alguna manera deben ser entendidos, para los jóvenes))
Por eso no estoy de acuerdo contigo en que los jóvenes absorban con avidez la OOP.
Estoy pensando en C, que es donde se construye la lógica del lenguaje mql.
C nació en 1972, así que tiene 48 años ))
Pero de todos modos, C es uno de los lenguajes más rápidos. ¿Sabes por qué? Porque no tiene envolturas de clase.
MQL está construido en C++.
Roman, para introducir estas características que mencionas, MQL tendrá que introducir muchas cosas adicionales en cuanto al trabajo con la memoria. Y esto es una complicación para los principiantes.
Usted mismo ha dicho que debe ser más fácil para los no profesionales.
Es una situación como la de "se me da bien aprender a pedalear en bicicleta, es muy sencillo y comprensible". Pongamos pedales en el BMW, será más fácil". :)
es decir, en general soy de la opinión de que tanto el estilo procedimental como el OOP son poco prácticos))
todo hecho, no quiere soluciones listas usando POO (no es necesario saber POO, ¡utiliza las listas!)
utilice ALGLIB , hay un método para redimensionar la matriz Resize().... pero aún así todo se hace con OOP ))))
SZS: busca en el foro, había muchas veces sobre este tema, había ejemplos, se puede envolver una estructura con un campo de matriz en una matriz de estas estructuras - será sin OOP, pero para mí todo parece engorroso
El problema es que no te acuerdas de C puro, yo lo estudié en la uni, pero si no me equivoco, C no tenía arrays dinámicos como tal, sino que podías trabajar con punteros a memoria, y el trabajo de asignar memoria y controlar el acceso a la misma dependía completamente del programador, que sería una envoltura para el programador
OK, esto podría convertirse en una gran discusión y no tiene sentido continuar
Probado ALGLIB, hay un problema con la impresión desde el objeto, la función ArrayPrint no imprime objetos.
Pero a partir de [][] imprime una bonita matriz, incluso con cabeceras, de nuevo, es fácil de ver cuando se necesita seguir visualmente el resultado del cálculo.
Sí, he mirado algunos temas del foro, pero no me impresionan. Por eso todo parece engorroso e ineficiente. C es un lenguaje muy elegante y mql tiende a corromperlo.
Sí, C puede asignar memoria para matrices dinámicas a través de punteros, pero en mql no hay punteros a variables, así que de nuevo tenemos que cambiar a objetos.
Cuando los usuarios sólo necesitan una función ArrayResizeMx(A, n, m, k) y estará en la implementación nativa, se entiende la diferencia.
Pues no tiene sentido seguir, si se han enterado y lo harán, muchas gracias. Pero la función es realmente útil y necesaria.
Especulación en voz alta, pero es más bien un llamamiento al desarrollador.
Para este Zloy, no te lo tomes como algo personal.
Así pues, las matrices dinámicas sólo pueden manejarse mediante objetos o estructuras. Otra muleta se crea en general.
No hay punteros a variables en mql, así que tenemos que usar el enfoque de objetos donde los punteros están disponibles.
Por lo tanto, para utilizar las matrices dinámicas, un usuario debe conocer la POO y trabajar con punteros, y además, en ejecución MQL.
¿Cuántos de ellos tienen estos conocimientos? Tú mismo sabes la respuesta. No tengo ninguna dificultad para entender el enfoque de los objetos, pero para los que no conocen la POO
Crean un umbral artificial para el uso del lenguaje, en particular cuando se trata de matrices dinámicas.
Enmi opinión, un desarrollador, por el contrario, debería estar interesado en facilitar el uso del lenguaje, en lugar de complicarlo.
En otras palabras, deben desarrollar aquellas funciones que sean necesarias para que el usuario trabaje cómodamente con el lenguaje.
Y más aún con las matrices, que son casi la base de los métodos numéricos.
Por esta razón, me gustaría pedirles que crearan funciones similares a ArrayResize, pero para matrices ArrayResizeMx(A, n, m),
y quizás también para las multidimensionales. En otras palabras, dar la posibilidad de trabajar con matrices no como con objetos, sino como con arrays habituales al estilo C.
Especialmente para la representación visual de las matrices, la función ArrayPrint(A, 0) imprime matrices a partir de matrices, no de objetos.
Los desarrolladores han sido bastante específicos al respecto. Aquí
Los desarrolladores han sido bastante específicos al respecto. Aquí
No hace falta ir muy lejos, el siguiente post, con preguntas específicas de Prival,
Lo conozco desde hace mucho tiempo, más o menos desde la misma época, un desarrollador militar competente, y qué, por qué se fue de aquí, la respuesta es obvia.
Han pasado diez años, ¿ha cambiado algo?
Como estaba lleno de algoritmos simples, se ha mantenido en ese nivel. ¿Dónde están las soluciones profesionales?
Pero estamos escribiendo más a python que para dar herramientas para escribir estas soluciones profesionales y desarrollar nuestro kodobase.
Ahí es donde está el error, no hay herramientas, no hay un nivel adecuado de programadores.
Vale, me voy a dormir ahora, que aún no he dormido. Buena suerte a todos.
Así que todo es un procedimiento...
El procedimiento es B, todo es elemental allí, sólo que hay más oportunidades de dispararse en el pie.
Creo que te has equivocado y has querido decir funcional. Pero no importa.