Erros, bugs, perguntas - página 2637
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
talvez em comparação com a programação funcional?
Veja a wikipedia:
E descobrimos que não é a mesma coisa.
Portanto, é tudo processual...
Posso surpreendê-lo, mas os jovens programadores de hoje consideram que o OOP é mais fácil de programar do que a programação processual.
Está a pensar em termos de 25 anos atrás. Os jovens de hoje absorvem o OOP com o leite da sua mãe. Aprenda OOP se quiser estar na tendência, caso contrário não fará mais nada senão resmungar.
Mas é realmente assim. Deixar os antigos programadores tentarem resolver tarefas olímpicas para as crianças em idade escolar.
O que estudaram anteriormente nas universidades, tais como programação dinâmica, teoria gráfica, OOP, aulas, etc. Os actuais alunos de 9-10 aulas (nem todos, claro) resolvem tais problemas em poucos minutos.
E é natural. Lei da natureza :)
Sim, compreendo o OOP, não na medida em que eu gostaria, claro.
Isto não é uma rabugice, mas uma sugestão construtiva.
Para que o programador não tenha de escrever uma função para atribuir dois mallocs, forçam os utilizadores a aprender o OOP.
É claro que é esse progresso e popularização da língua. Bem, pode ver o quanto eles adoram e compreendem o OOP aqui.
Como vê, Nikolay, tudo o que está no invólucro é código desnecessário para ser executado, não creio que precisemos de explicar.
Não preciso de vos falar sobre compiladores modernos de optimização - não sabemos que instruções irão aplicar.
Talvez também vos surpreenda que até os programadores americanos prefiram escrever no estilo processual não porque o OOP é mau, mas porque o código é mais simples e mais rápido.
E se não existem tarefas de objecto no projecto, porquê utilizar invólucros, que de alguma forma devem ser compreendidos, para os jovens))
É por isso que não concordo consigo que os jovens absorvam com entusiasmo o OOP.
Estou a pensar em C, que é onde a lógica da linguagem mql é construída.
C nasceu em 1972, portanto tem 48 anos de idade ))
Mas de qualquer modo, o C é uma das línguas mais rápidas. Sabe porquê? Porque não tem invólucros de classe.
Bem, isso não é de todo verdade. É que ainda há muitas línguas em uso sem OOP. C, por exemplo. No Canadá, por exemplo, a maioria das instituições governamentais estão sentadas em Kobol e não se conseguem livrar dela.
https://www.tiobe.com/tiobe-index/
Roman, sinceramente não compreendo porque é que estás a fazer um alarido sobre a mudança das dimensões da matriz - que dificuldades pode haver com isso.
Para isso não são necessários indicadores ou OOP.
De qualquer forma, para um computador, uma matriz de qualquer dimensão é uma matriz unidimensional.
Assim, trabalhar com uma matriz dinâmica unidimensional. E formar matrizes virtualmente e redimensioná-las como desejar, com a ajuda de funções.
Por exemplo, algo do género:
Na prática, uso apenas matrizes unidimensionais no meu código, embora também lide com matrizes multidimensionais com base em matrizes unidimensionais.
É por isso que eu gostaria de lhe pedir para fazer funções como ArrayResize apenas para matrizes ArrayResizeMx(A, n, m)
tudo feito, não quer soluções prontas usando OOP (não é obrigado a conhecer OOP, use ready-made!)
use ALGLIB , existe um método para redimensionar a matriz Resize().... mas ainda assim tudo é feito pelo OOP ))))
SZS: procure no fórum, houve muitas vezes sobre este tópico, houve exemplos, pode embrulhar uma estrutura com um campo de matriz numa matriz destas estruturas - será sem OOP, mas para mim tudo isto parece incómodo
Estou a pensar em C, que é a base da lógica mql.
A língua C nasceu em 1972, pelo que se verifica que tem 48 anos de idade))
Mas de qualquer modo, o C é uma das línguas mais rápidas. Sabe porquê? Porque não tem invólucros de classe.
Não me lembro de C puro, estudei-o na universidade há muito tempo, mas se não me engano, C não tinha matrizes dinâmicas como tal, mas podia-se trabalhar com apontadores para a memória, e o trabalho de alocação de memória e controlo de acesso à memória estava totalmente a cargo do programador, que é essencialmente o mesmo invólucro
OK, isto pode ser um grande argumento, não vale a pena continuar.
Roman, sinceramente, não compreendo por que razão fez um alarido sobre a mudança das dimensões da matriz - que dificuldades pode haver com ela.
Para isso não são necessários indicadores ou OOP.
De qualquer forma, para um computador, uma matriz de qualquer dimensão é uma matriz unidimensional.
Assim, trabalhar com uma matriz dinâmica unidimensional. Entretanto, forme virtualmente matrizes e redimensione-as como desejar, utilizando funções.
É evidente que qualquer dimensão é uma matriz unidimensional para computador.
Se virmos a dimensão [][] no código, podemos compreender visualmente que se trata de uma matriz, não de uma matriz unidimensional.
A legibilidade do código é muito maior do que adivinhar o que [][] contém.
Nunca tinha pensado que iria encontrar tal falta de compreensão quando me pediram para acrescentar uma função sobre alocação de memória para matrizes.
Todos vocês usam o ArrayResize, é conveniente e não se incomodam com ele. Qual é o problema de um programador escrever uma função de alocação de memória parauma matriz multidimensional?
É verdade, não há problemas nem obstáculos, e é conveniente que os utilizadores organizem o seu código. Assim, decidi portar uma grande e boa biblioteca C de métodos numéricos para mql,
mas não tenho quaisquer ferramentas mql normais para isso. Mais uma vez há muletas, o que elimina todo o desejo de construir códigos ineficientes.
Eu compreendo o OOP, não tanto quanto gostaria, claro.
Isto não é uma rabugice, mas uma sugestão construtiva.
Para que o programador não tenha de escrever uma função para atribuir dois mallocs, forçam os utilizadores a aprender o OOP.
É claro que é esse progresso e popularização da língua. Bem, pode ver o quanto eles adoram e compreendem o OOP aqui.
Como vê, Nikolay, tudo o que está no invólucro é código desnecessário para ser executado, não creio que precisemos de explicar.
Não preciso de vos falar sobre compiladores modernos de optimização - não sabemos que instruções irão aplicar.
Talvez também vos surpreenda que até os programadores americanos prefiram escrever no estilo processual não porque o OOP é mau, mas porque o código é mais simples e mais rápido.
E se não existem tarefas objectivas no projecto, porquê utilizar invólucros, que de alguma forma devem ser compreendidos, para os jovens))
É por isso que não concordo consigo que os jovens absorvam com entusiasmo o OOP.
Estou a pensar em C, que é onde a lógica da linguagem mql é construída.
C nasceu em 1972, portanto tem 48 anos de idade ))
Mas de qualquer modo, o C é uma das línguas mais rápidas. Sabe porquê? Porque não tem invólucros de classe.
O MQL é construído em C++.
Roman, a fim de introduzir estas características que menciona, a MQL terá de introduzir muitas coisas adicionais em termos de trabalhar com memória. E isto é uma complicação para os principiantes.
O senhor mesmo disse que deve ser mais fácil para os não-profissionais.
É uma situação como "Sou bom a aprender a pedalar numa bicicleta, é tão simples e compreensível. Vamos colocar pedais na BMW, vai ser mais fácil". :)
s.e. Sou geralmente de opinião que tanto o estilo processual como o estilo OOP são coxos e impraticáveis))
tudo feito, não quer soluções prontas usando OOP (não é obrigado a conhecer OOP, use ready-made!)
use ALGLIB , existe um método para redimensionar a matriz Resize().... mas ainda assim tudo é feito com OOP ))))
SZS: procure no fórum, houve muitas vezes sobre este tópico, houve exemplos, pode embrulhar uma estrutura com um campo de matriz numa matriz destas estruturas - será sem OOP, mas para mim tudo isto parece incómodo
O problema é que em C não se lembra de C puro, estudou-o em uni, mas se não me engano, não havia matrizes dinâmicas, mas podia-se trabalhar com apontadores para a memória, e o trabalho de atribuir memória e controlar o acesso à memória era deixado inteiramente a cargo do programador, seria o mesmo invólucro
OK, isto pode tornar-se um grande argumento e não vale a pena continuar
ALGLIB testado, há um problema com a impressão a partir do objecto, a função ArrayPrint não imprime objectos.
Mas a partir de [][] imprime uma bela matriz, mesmo com cabeçalhos, mais uma vez, é fácil de ver quando se precisa de seguir visualmente o resultado do cálculo.
Sim, já analisei alguns tópicos no fórum, mas não estou impressionado. É por isso que tudo parece incómodo e ineficiente. C é uma linguagem muito elegante e o mql tende a corrompê-la.
Sim, C pode alocar memória para matrizes dinâmicas através de apontadores, mas em mql não há apontadores para variáveis, por isso novamente temos de mudar para objectos.
Quando os utilizadores só precisam de uma função ArrayResizeMx(A, n, m, k) e ela estará na implementação nativa, compreende-se a diferença.
Bem, não faz sentido continuar, se já ouviram falar disso e vão fazê-lo, muito obrigado. Mas a função é realmente útil e necessária.
Especulação em voz alta, mas é mais um apelo para o promotor.
Para este Zloy, não o leves a peito.
Assim, as matrizes dinâmicas só podem ser manipuladas através de objectos ou estruturas. Uma outra muleta é criada em geral.
Não existem apontadores para variáveis em mql, pelo que temos de utilizar a abordagem por objectos onde os apontadores estão disponíveis.
Assim, para utilizar matrizes dinâmicas, um utilizador deve conhecer o OOP e trabalhar com apontadores, e além disso, na execução do MQL.
Quantos deles têm este conhecimento? Você mesmo sabe a resposta. Não tenho qualquer dificuldade em compreender a abordagem ao objecto, mas para aqueles que não conhecem o PON
Criam um limiar artificial para a utilização da língua, em particular quando se trata de matrizes dinâmicas.
Ameu ver, um programador, pelo contrário, deveria estar interessado em tornar a linguagem mais fácil de usar, em vez de a complicar.
Por outras palavras, devem desenvolver tais funções que são necessárias ao utilizador para um trabalho confortável com a língua.
E ainda mais com matrizes, que são quase a base dos métodos numéricos.
Por esta razão, gostaria de lhe pedir para criar funções semelhantes ao ArrayResize, mas para as matrizes ArrayResizeMx(A, n, m),
e talvez também para as multidimensionais. Por outras palavras, dar a possibilidade de trabalhar com matrizes não como com objectos, mas como com matrizes habituais no estilo C.
Especialmente para representação visual de matrizes, a função ArrayPrint(A, 0) imprime matrizes a partir de matrizes, não de objectos.
Os criadores têm sido bastante específicos a este respeito. Aqui
Os criadores têm sido bastante específicos a este respeito. Aqui
Não há necessidade de ir longe, o próximo posto, com perguntas específicas de Prival,
Conheço-o há muito tempo desde aproximadamente o mesmo tempo, um programador militar competente, e o que, porque é que ele deixou aqui, a resposta é óbvia.
Passaram-se dez anos, será que alguma coisa mudou?
Como foi preenchido com algoritmos simples, permaneceu a esse nível. Onde estão as soluções profissionais?
Mas estamos a escrever mais para python do que para dar ferramentas para escrever estas soluções profissionais e desenvolver a nossa kodobase.
É aí que está o erro, não há ferramentas, não há um nível adequado de programadores.
Ok, agora vou dormir, ainda não dormi. Boa sorte para todos.
Portanto, é tudo processual...
O procedimento é B, lá é tudo elementar, apenas mais oportunidades de disparar um tiro no pé.
Penso que se enganou e quis dizer funcional. Mas isso não importa.