Erros, bugs, perguntas - página 1335

 

No código fonte do indicador Fractals.mq5, existem tais entradas para o cálculo dos fractais (linhas 74 e 79):

//---- Upper Fractal
if(high[i]>high[i+1] && high[i]>high[i+2] && high[i]>= high[i-1] && high[i]>= high[i-2])

//---- Lower Fractal
if(low[i]<low[i+1] && low[i]<low[i+2] && low[i]<= low[i-1] && low[i]<= low[i-2])

Nestes cálculos, estou confuso por sinais iguais em >= e <= (em vermelho).

Sempre pensei que se forma um fractal ascendente quando, numa combinação de pelo menos cinco barras, a barra média tem o máximo mais alto, ou seja, é sempre mais alta (não mais alta ou igual) do que as duas altas vizinhas do lado esquerdo e direito. Com o fractal para baixo, respectivamente. Na parte acima referida do código, pode ver-se que a igualdade é permitida. Verifique por favor se existe um erro no código Fractals.mq5.

 

Tenho um sinal, a monitorização mostra uma lixeira a 100%, a conta está bem, estou a bater ao telefone há três dias, tanto para o Service Desk como para o pessoal da empresa. Sem resposta...

Como resolver o problema....?

 
Stanislav Olhovsky:

Tenho um sinal, a monitorização mostra uma lixeira a 100%, a conta está bem, estou a bater ao telefone há três dias, tanto para o Service Desk como para o pessoal da empresa. Sem resposta...

Como resolver o problema....?

Não deve retirar mais do que ganhou, então a curva de equilíbrio não irá a zero.
 

Escrevi para "Inovações nos favoritos" e há silêncio. Vou escrever aqui:

Windows 10 x64, Mozilla Firefox 39.0. Não posso enviar imagens ou ficheiros anexos para a minha conta pessoal.

 
Karputov Vladimir:
Não deve retirar mais do que o ganho, então a curva de equilíbrio não irá a zero.

O sinal está a funcionar há quase 4 meses, apenas adições de rebites, ninguém retirou nada lá, tudo estava normal, crescimento estável... No terminal, os dados são normais e noutra monitorização em linha ....

Captura de ecrã do mybook anexado, aí tudo é normal.

Resposta do corretor, o histórico é armazenado durante 1 mês, mas depois há dois ou três meses sobre sinais teria sido o mesmo...

Arquivos anexados:
Error.png  36 kb
 
É tudo novamente sobre o "privado". As juntas continuam...
 

Caros programadores!

O indicador de bandas e o indicador iBands têm leituras diferentes. No indicador Bands o desvio padrão é calculado utilizando a função StdDev_Func, enquanto nas iBands é calculado utilizando o método GetData. Ao comparar a forma como o gráfico é desenhado, podemos ver uma grande diferença no estado dos amortecedores responsáveis pelos níveis de desvio. Enfrentei este problema na MQL4, talvez seja o mesmo na MQL5.

 

Não tinha prestado muita atenção a isso antes, mas agora, ao trabalhar com grandes conjuntos de objectos de classe, notei um consumo de memória demasiado grande. Verifiquei-o por sizeof() e uma classe absolutamente vazia leva 16 bytes. E considerando que as classes aqui são geridas, adicionamos mais 8 bytes por ponteiro. O total é de 24 bytes. É demasiado caro.

Dei uma vista de olhos na documentação e vi o que lá encontrei:

объекты классов всегда имеют таблицу виртуальных функций, даже если в классе не объявлено ни одной виртуальной функции.

A questão é porque é que as classes simples (as que não participam na herança) precisam da tabela de funções virtuais, uma vez que tudo é conhecido sobre estas classes na fase de compilação.

Acontece que os métodos neles são chamados da mesma forma que os métodos virtuais, ou seja, há um redireccionamento adicional do acesso através da tabela. E onde está a elogiada optimização do compilador? Como podemos afirmar depois disto alguma comparação de desempenho com C++?

 

Está enganado.

Se um método não for descrito como virtual, é chamado directamente. Além disso, existem optimizações para remover a virtualidade. O destruidor é sempre virtual, o que leva a uma mesa virtual.

Cerca de 24 bytes é uma afirmação estranha - a referência ao objecto não se refere ao tamanho.

As aulas em línguas geridas/seguras contêm sempre metainformação, por isso tudo aqui é razoável. Se quiser tamanho puro, utilize estruturas.

 
Renat Fatkhullin:

O destruidor é sempre virtual, o que resulta numa mesa virtual.

Então, porque não deveria o destruidor ser optimizado? É apenas por causa do destruidor que temos de armazenar 8 bytes extra...

Os 24 bytes é uma afirmação estranha - a referência ao objecto não tem nada a ver com o tamanho.

Bem, só não sei como tudo é aí implementado. Suponha que tem um conjunto de objectos:

CObj array[];

O sistema armazena referências (apontadores) para cada elemento?

Se quiser tamanho puro, utilize estruturas.

Mas não se pode levar um ponteiro para uma estrutura e isso reduz a conveniência da sua utilização. É por isso que por vezes é preciso fazer uma escolha dolorosa... Se se conseguir reduzir o tamanho da classe, isso seria maravilhoso. E se também se tiver um ponteiro para a estrutura, tudo ficará bem).