Desejos para MT5 - página 46

[Mykola Demko]

-Alexey-:
Discordo, há um problema, aqui está um exemplo (grelha 10000x10000):

duplo x1=0,0011;

duplo y1=x1/10000;

duplo x2=0,0012;
duplo y2=x2/10000;

duplo c=y1-y2;
duplo d=MathPow(c,2);


printf(string(d)));

результат: 9.999999999999968e-017

Então, o que faço com este resultado? Como posso compará-lo com outros resultados? DBL_EPSILON=2.2204460492503131e-016. Para além dos dois últimos dígitos - ver? E isso são apenas duas operações. E eu tenho mais destas operações. E esta informação deve ser utilizada para restaurar os dados mais tarde com mais algumas operações. Mais perdas. Estou apenas a aprender a programar numa língua tipo C e tal aula é difícil para mim de construir (ou melhor, não faço ideia de como). Este é um trabalho sério. A propósito, por acaso, tem uma tal aula? E os criadores podem melhorar as coisas para todos de uma só vez. Seria possível fazer 100.000x100.000 grelhas. Já estariam disponíveis amostras mais ou menos representativas, embora mesmo isto não seja suficiente em geral. E se fizessem uma aula de precisão arbitrária, seria ainda melhor :) É apenas um tipo de dados. Se existe, está lá por uma razão, porque preenche uma necessidade. A questão é que eu não sei se é difícil ou não para os criadores. Se é difícil e caro - concordo consigo - porquê passar-lhes o meu problema. Mas se não é difícil - porque não fazê-lo? Mais uma vez - um poderoso ambiente de desenvolvimento para cálculos comerciais com alta precisão - alguma vantagem competitiva aqui :). É por isso que pergunto o que eles pensam sobre o assunto.

Por favor releia a forma padrão do número, e muitas perguntas desaparecerão.

No formulário padrão 1.111e5 é maior do que 9.999e4, pelo que a comparação é bastante correcta.

Aqui está o mesmo resultado: 9.999999999999999999968e-017 está relacionado com a representação binária do número, nem todos os números em forma binária são representados por uma fracção finita, alguns são representados por uma fracção infinita, arredondando assim a mantissa para o número mais próximo com uma fracção finita.

A propósito, double d=MathPow(c,2); não é correcto tirar grau, se trabalhar com o dobro então double d=MathPow(c,2.0); por isso, não sei se o erro é ou não, mas ao definir um número até um grau também se deve estar atento ao tipo de indicador.

[Aleksandr Chugunov]

-Alexey-:
A fantasia não tem absolutamente nada a ver com isso. A minha pergunta surgiu sobre a possibilidade de implementar o método de análise mais comum. E isto é trabalhar com as séries que restam após a remoção da tendência e do ciclo. Está escrito sobre este método em todos, sem excepção, livros de texto sobre estatísticas financeiras e livros de método nas universidades. Isto não é uma fantasia, mas uma das abordagens canónicas da análise. E um ambiente especializado deveria ter meios para implementar esta abordagem, não acha?

)))))))

[[Excluído]]

Urain:

Por favor releia a forma padrão do número, e muitas perguntas desaparecerão.

No formulário padrão 1.111e5 é maior do que 9.999e4, pelo que a comparação é bastante correcta.

Aqui está o mesmo resultado: 9.999999999999999999968e-017 está relacionado com a representação binária do número, nem todos os números em forma binária são representados por uma fracção finita, alguns são representados por uma fracção infinita, daí arredondar mantissa para o número mais próximo com uma fracção finita.

Sobre o 1.111e5 e o 9.999e4, vejo. Mas preciso de os comparar: 9.99999999999999999999999999968e-017 (sobre a perda de precisão em dígitos que eu adicionalmente escrevi). A ajuda diz-me que os números com uma diferença inferior a DBL_EPSILON devem ser considerados indistinguíveis. Desculpe, se não estou a deixar claro - estou apenas a aprendê-lo agora :) Obrigado separadamente pela informação sobre o indicador.

[Andrey Dik]

Urain:

A propósito, double d=MathPow(c,2); não é correcto tirar grau, se trabalhar com double então double d=MathPow(c,2.0); por isso, não sei se há ou não erro, mas ao definir um número a um grau é necessário seguir o tipo de indicador.

O expoente deve, em qualquer caso, ser do tipo duplo.

[Mykola Demko]

Caros programadores, permitam a devolução de valores vazios, ou definam uma nova classe que devolva valores de qualquer tipo.

Algo parecido com isto:

voids get(int i)
  {
   if(i==0)return((int)2);
   else
     {
      if(i==1)return((double)2);
      else
        {
         if(i==2)return((string)2);
        }
     }
  }

Quero ter este tipo de declaração em funções definidas pelo utilizador:

int  Custom_ArraySize( void  array[] );   
bool Custom_ArraySort( number&  array[] );

e para isso preciso de acrescentar algo à língua. Os utilizadores estão demasiado seguros, precisam de se soltar um pouco em algum lugar.

Imagine que um programador está a escrever código, criou 1500 linhas e todo o código funciona com um duplo, para lhe passar uma int ele terá de fazer uma sobrecarga para mais 1500 linhas. E tem 14 tipos.

[Evgeniy Logunov]

Urain:

Imagine, uma pessoa escreve código, faz 1500 linhas, e todo o código funciona com o duplo, para passar para ele terá de fazer sobrecarga para mais 1500 linhas. E tem 14 tipos.

Usar OOP.

[Mykola Demko]

lea:

Usar OOP.

Acha que escrevo em autocódigo?

aos Desenvolvedores:

como opção para aliviar a situação da fraternidade de escrita, fazer uma conversão de tipo de matriz, para que possa, pelo menos, fazer tal chamada:

void OnStart()
  {
   int array[10];
   func((double)array)
  }
//+------------------------------------------------------------------+
void func(double &array[]){};

[Evgeniy Logunov]

Urain:

Acha que escrevo em autocódigo?

A julgar pelo facto de precisar de tal extensão da língua, suponho que sim.

p.s. Se tivesse apenas o compilador C++ na altura em que resolveu o seu problema, será que ouviríamos uma sugestão para rever o padrão linguístico?

[Mykola Demko]

lea:

Com base no facto de precisar de tal extensão da língua - aparentemente, sim.

p.s. Se tivesse apenas um compilador C++ na altura do seu problema - teríamos ouvido a sugestão de rever o padrão linguístico?

Não confundir tradutor e compilador. mql não é realmente um compilador, é um tradutor que descreve chamadas de funções C++ seguras.

E o mql5 está em fase de desenvolvimento activo. Assim, o meu pedido de alterações é bastante adequado.

[Evgeniy Logunov]

Urain:

Não confundir tradutor e compilador, mql não é realmente um compilador, é um tradutor que descreve chamadas de funções C++ seguras

Além disso, o mql5 está na fase activa de desenvolvimento. Assim, o meu pedido para fazer alterações é bastante adequado.

Ok, se é tão importante, vamos tomar Java e não C++. Também tradução em bytecode :) Por favor, reconsiderar o padrão linguístico?

Um pedido para acrescentar um tipo universal não é bem adequado. Deve-se pedir modelos. E para os tipos universais, o OOP é suficiente.