Discussão do artigo "Distribuições estatísticas no MQL5 - tirando o melhor de R" - página 2
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
Por que, quando obtemos as inovações desejadas, elas são constantemente criticadas?
Se uma linguagem é criticada, isso significa que ela está viva.
De fato, é uma grande felicidade para os desenvolvedores quando há críticas e discussões depois. Somente dos comerciantes deste site, recebemos mais de 3.000 tíquetes para o Service Desk todos os meses. São 100 solicitações por dia, inclusive nos finais de semana. E isso não inclui as discussões no fórum.
Se uma linguagem é criticada, isso significa que ela está viva.
De fato, é uma grande felicidade para os desenvolvedores quando há críticas e discussões posteriores. Somente dos comerciantes deste site, recebemos mais de 3.000 tíquetes para o Service Desk todos os meses. São 100 solicitações por dia, inclusive nos finais de semana. E isso não inclui as discussões no fórum.
Para ser sincero, nunca olhei para isso dessa forma. Parecia-me que as críticas e solicitações intermináveis dos usuários eram um fardo para os desenvolvedores. Eu mesmo nunca recorri ao serviço, nunca pedi nada e nunca critiquei, mesmo quando me faltava algo. No fim das contas, fiz a coisa certa, pois havia muitas pessoas pedindo isso sem mim.... Mas aprendi a me adaptar e a usar as possibilidades do idioma da forma mais eficiente possível. Felizmente, a linguagem era muito adequada para resolver minhas tarefas. Às vezes, eu ficava surpreso com as coincidências. Por exemplo, no desenvolvimento de um programa, muitas vezes eu precisava de funções diferentes, mas, devido ao meu conhecimento insuficiente da linguagem, eu não sabia se elas existiam, mas sempre que eu recorria à documentação e fazia uma pequena pesquisa, ficava convencido de que as ferramentas de que eu precisava estavam disponíveis na linguagem. Até mesmo a função que retorna o comprimento da cadeia de texto, que é tão necessária para a interface, foi encontrada por mim no devido tempo, e fiquei convencido de que a linguagem foi realmente testada. No momento, tenho muitas tarefas, mas antes de entrar em contato com o servicedeck, aproveito todas as oportunidades para resolvê-las eu mesmo. Se houver algo em que a ajuda dos desenvolvedores seja necessária, talvez um dia eu me candidate....
P.S. No entanto, talvez esse seja o processo de desenvolvimento: críticas, reclamações, solicitações, discussões.... Então, acontece que eu não participo do desenvolvimento de idiomas. Mais precisamente, eu participo, mas de minha própria maneira. Como cada um de nós.
Certamente é muito trabalhoso. Mas eu não entendo, por que reinventar a roda várias vezes? Bibliotecas semelhantes e muito mais funcionais e, além disso, disponíveis publicamente já estão disponíveis, e por que sobrecarregar o MQL com a funcionalidade necessária para, digamos, 5% dos usuários? Não é mais fácil criar um adaptador para o próprio R, ou melhor, chamar suas funções? De qualquer forma, os recursos computacionais do R, SciLab ou MathLab não conseguem acompanhá-los. Para evitar acusações de parcialidade, não planejo conectar o R ao MT.
Certamente é muito trabalhoso. Mas eu não entendo, por que reinventar a roda várias vezes? Bibliotecas semelhantes e muito mais funcionais e, além disso, disponíveis publicamente já estão disponíveis, e por que sobrecarregar o MQL com a funcionalidade necessária para, digamos, 5% dos usuários? Não é mais fácil criar um adaptador para o próprio R, ou melhor, chamar suas funções? De qualquer forma, os recursos computacionais do R, SciLab ou MathLab não conseguem acompanhá-los. Para não ser acusado de preconceito, não planejo conectar o R ao MT.
Não estamos sobrecarregando a linguagem, mas complementando a biblioteca padrão.
As bibliotecas matemáticas são adicionadas nos códigos-fonte MQL5 e estão disponíveis nos catálogos /Include/Math. Agora há três bibliotecas matemáticas padrão: Alglib, Fuzzy e funções estatísticas, como no R.
Já expliquei o problema de usar sistemas de terceiros em https://www.mql5.com/ru/forum/96176/page11#comment_2859489.
Em relação às palavras de Renat, por favor, não exclua a postagem novamente.
Acho que seria interessante, nesse caso, fazer uma enquete entre os membros do fórum - quem usa o quê no momento - bibliotecas padrão, software de terceiros - R, matlab, Python, bem como o número de projetos sobre essa ou aquela solução em desenvolvimento ou já disponível, não usa nada. E a segunda pergunta é se vocês (usuários) vão usar bibliotecas padrão, é claro, no contexto das bibliotecas do matlab.
Na base de código, eu mesmo encontrei e usei apenas um produto que usa alglib, que é o https://www.mql5.com/pt/code/11859. Por uma questão de interesse, dei uma olhada na base de código sobre o tópico de redes neurais. Todos os exemplos disponíveis NÃO usam alglib ou bibliotecas internas semelhantes. E encontrei apenas mais um código que usa a alglib https://www.mql5.com/pt/code/15865.
Isso é tudo, não há mais nada no mercado ou na base de código. Ou as pessoas não as publicam ou não as utilizam. Então, talvez valha a pena realizar a pesquisa de marketing mais primitiva com antecedência, para não desperdiçar recursos em coisas desnecessárias?
E outra citação.
Do ponto de vista da monetização, tudo está claro. Usando bibliotecas internas, os produtos podem ser vendidos no mercado e os desenvolvedores terão uma renda adicional com isso. Mas, como eu já indiquei acima, não há NENHUM produto agora, de forma alguma, usando essas coisas. Portanto, acho que a expectativa de uma forte monetização dessa ideia é exagerada.
Também em Deus sabe em que ano tais pensamentos foram expressos https://www.mql5.com/ru/forum/6505/page11#comment_195723.
Mas, como já observei acima, NÃO há produtos agora, desde o início, usando essas coisas. Portanto, acho que a expectativa de uma forte monetização dessa ideia é exagerada.
Pense no fato de que o kodobase é uma parte minúscula do código criado, visível para o público. É por isso que você não pode tirar conclusões a partir dele.
Na verdade, um número impressionante de desenvolvedores na Ásia (e em outras regiões) programa silenciosamente e não se mostra de forma alguma em nossa comunidade. Sabemos disso pelo número de editores de lançamento em todo o mundo.
Nosso grande desafio é apoiar e ajudar a aumentar esse asberg subaquático, tentando fazer com que os membros se manifestem publicamente nos fóruns, no kodobase, no marketplace etc.
Faça uma pesquisa sobre as bibliotecas e os pacotes de análise em uso - será interessante para todos.
Não estou entendendo algo.
Vejamos
2.17.1 MathProbabilityDensityBinomial
A função calcula o valor da função de massa de probabilidade da distribuição binomial com parâmetros n e p para uma variável aleatória x. Em caso de erro, ela retorna NaN. Um análogo de dbinom() no R.
);
Afirma-se que esse é um análogo da função R, que é especificada no texto.
Qual é o resultado da chamada da função especificada em MQL? Um escalar? Um vetor?
Aqui está o que temos em R
n <- 2000
>
> k <- seq(0, n, by = 20)
>
> dbinom(k, n, pi/10, log = TRUE)
[1] -754.219687 -660.247472 -592.126636 -534.532344 -483.881605
[6] -438.460449 -397.256529 -359.600217 -325.015561 -293.146935
[11] -263.718651 -236.510862 -211.344286 -188.070044 -166.562645
[16] -146.714976 -128.434635 -111.641185 -96.264050 -82.240889
[21] -69.516303 -58.040813 -47.770020 -38.663934 -30.686405
[26] -23.804662 -17.988917 -13.212041 -9.449276 -6.678001
[31] -4.877524 -4.028903 -4.114796 -5.119322 -7.027950
[36] -9.827392 -13.505519 -18.051278 -23.454625 -29.706468
[41] -36.798607 -44.723697 -53.475197 -63.047346 -73.435124
[46] -84.634231 -96.641063 -109.452696 -123.066869 -137.481976
[51] -152.697057 -168.711791 -185.526498 -203.142139 -221.560321
[56] -240.783304 -260.814011 -281.656048 -303.313714 -325.792028
[61] -349.096753 -373.234428 -398.212400 -424.038867 -450.722923
[66] -478.274610 -506.704982 -536.026169 -566.251458 -597.395380
[71] -629.473815 -662.504106 -696.505196 -731.497775 -767.504466
[76] -804.550025 -842.661583 -881.868927 -922.204828 -963.705435
[81] -1006.410740 -1050.365139 -1095.618115 -1142.225065 -1190.248330
[86] -1239.758485 -1290.835969 -1343.573182 -1398.077239 -1454.473630
[91] -1512.911233 -1573.569331 -1636.667772 -1702.482242 -1771.368369
[96] -1843.802104 -1920.453074 -2002.333627 -2091.157734 -2190.508385
[101] -2315.710414
> a<-dbinom(k, n, pi/10, log = TRUE)
> str(a)
num [1:101] -754 -660 -592 -535 -484 ...
Ou seja, chamar a função no R gera um vetor, que pode ser desenhado usando o método de plotagem universal
> plot(a)
Um análogo é declarado.
É possível demonstrar que o resultado da aplicação por µl será o mesmo com o R?
Quando você quer implicar com alguém, começa com o texto.
Você insere um vetor no R. E na versão MQL - um escalar.
É fácil converter escalar->vetor. Se você gosta de usar o R, use-o!
Não haverá preenchimento padrão de MQL-R, fique à vontade.
Quando você quer implicar com alguém, começa com o texto.
Você insere um vetor no R. E na versão MQL - um escalar.
É fácil converter escalar->vetor. Se você gosta de usar o R, use-o!
Não haverá nenhuma junta MQL-R padrão, por favor.
Eu me dirigi a você?
Artigo em discussão....
Eu me dirigi a você?
Artigo em discussão....
Há uma escolha óbvia na expressão "analógico".
No artigo, é análogo, e um análogo completo. No R, praticamente tudo passa por vetores. Essas são questões de sintaxe concisa, pelas quais, em particular, o R é tão e merecidamente amado.
E isso não tem nada a ver com o artigo. É pura irritação.