Erros, bugs, perguntas - página 673
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
Renat, zero - muito obrigado pela vossa atenção ao tema e pela vossa resposta construtiva!
A seguir.
1. cerca de x64
Renat:
A opção mais correcta é a de actualizar para x64.
...
Naturalmente, se alguém chamar centenas de indicadores no modo de digitalização do mercado sem a sua descarga, deverá ir directamente para a versão de 64 bits + instalar memória adicional.
É estranho estar a fazer testes massivos sentado em x32 neste momento. Qualquer computador x64 decente com 16GB de memória (sem ser fanático por placas gráficas e monitores) pode ser comprado por 15.000 rublos.
A mudança para x64 é, por todos os meios, a linha de acção correcta. Mas... Um não exclui o outro. Mesmo os meus 16gigs (eu tenho-os) não os quero esbanjar em alguns dados desnecessários. Tenho outras coisas para trabalhar em paralelo - MSVS, Matlab, etc., nas quais também quero calcular tarefas volumosas. Fico satisfeito por compreenderem isto e por estarem dispostos a procurar formas de poupar dinheiro.
2. sobre um início fixo da história:
Renat:
Nós próprios queremos reduzir o consumo de recursos. Talvez a solução possa ser alguma função IndicatorMaxDepth(uint len), que actuará apenas sobre indicadores criados nesta EA.
Mas o problema é que durante os testes os amortecedores dos indicadores em modo de acumulação crescerão juntamente com a história e não haverá poupança.
Concordo plenamente (quase). Aviso: Em muitos casos, a optimização é feita num pequeno pedaço da última história. Neste caso, as poupanças podem ser bastante substanciais. Ainda assim, considero a opção como relativamente funcional - especialmente se tiver um bom trabalho ou estimativas sobre a implementação. Para mim, por exemplo, a opção não me parece muito completa - muito trabalho, e o resultado não é radical. Uma meia solução.
3. aqui está o yaz! :
Renat:
Cortar ohistórico do indicador em tempo rl, mantendo a profundidade definida , está repleto debelas falhas e irá derrubar directamente os programadores que calculam/utilizam o sincronismo das barras do gráfico e buffer do indicador.
Não ! e não fraught - se as barras do gráfico se comportarem da mesma forma - de forma síncrona. Por outras palavras - se os anéis amortecedores (mesmo que de tamanho diferente) sempre (forçadamente) usar a bandeira AsSeries - não se espera problemas maciços para o utilizador.
// Neste caso, seria conveniente fazer todos os buffers de história apresentados ao utilizador - indicador (isto é, circular, com AsSeries=verdadeiro).
Nesta variante:
(1) existe uma representação interna das matrizes de indicadores e preços (do seu lado) : indexação da esquerda para a direita (AsSeries==falso), os tamanhos não dizem respeito ao utilizador, e de facto"a entrada é proibida".
E (2) há um lado do utilizador - todos os amortecedores são circulares (na implementação. o utilizador vê uma matriz linear virtual), a indexação é da direita para a esquerda (AsSeries==verdadeiro) e o tamanho é definido pelo utilizador.
O que é o telhado do utilizador aqui? Nenhum. Quando fora de alcance - resposta padrão Array fora de alcance.
Só você tem dificuldades (não pequenas, para ser honesto). Mas! considerando a universalidade do esquema - você tem de se esforçar apenas uma vez. E para cortar todas as "boas falhas" no início, na depuração beta. Depois disso - felicidade universal e construção muito económica .
Procederemos à revisão da cache de indicadores, que agora utiliza o princípio da máxima eficiência contra o princípio da poupança de memória. Os indicadores que foram rejeitados serão descarregados imediatamente, em vez de os manter na memória durante algum tempo, como é feito agora. Isto tornará possível chamar centenas de indicadores em fila com uma descarga directa através do IndicatorRelease.
3. aí vem o yazel! :
Não ! Não se comportará- se as barras do gráfico se comportarem da mesma forma - de forma síncrona. Por outras palavras - se anéis tampão (mesmo que diferentes em tamanho) sempre (forçadamente) usar a bandeira AsSeries - não se espera grandes problemas para o utilizador.
// Neste caso, seria conveniente fazer todos os buffers históricos fornecidos ao utilizador - indicativos (isto é, circulares, com AsSeries=verdadeiro).
Nesta variante:
(1) existe uma representação interna das matrizes de indicadores e preços (do seu lado) : indexação da esquerda para a direita (AsSeries==falso), tamanhos não dizem respeito ao utilizador, e geralmente"nenhuma entrada é permitida".
E (2) há um lado do utilizador - todos os amortecedores são circulares (em implementação. o utilizador vê uma matriz linear virtual), a indexação é da direita para a esquerda (AsSeries==verdadeiro) e o tamanho é definido pelo utilizador.
O que é o telhado do utilizador aqui? Nenhum. Quando o utilizador sai do alcance - reacção padrão Array fora do alcance.
Só você tem dificuldades (não pequenas, para ser honesto). Mas! considerando a universalidade do esquema - você tem de se esforçar apenas uma vez. E todas as "boas falhas" têm de ser cortadas na raiz durante a depuração beta. Depois disso, todos ficam contentes e a construção é muito económica .
Boa ideia, sou a favor disso. Mas não cancela a implementação do esquema de anéis, apenas o complementa de forma agradável.Deixem-me descrever as condições do teste:
Como resultado do sub-corte automático do indicador, nós
Descreverei as condições do teste:
Como resultado do sub-corte automático do indicador nós:
1.
Sim, é tolerável. Dificilmente causará descontentamento em massa, pelo contrário, a economia será muito atractiva. Ninguém proíbe o desperdício de memória com a instalação de uma enorme MaxBar.
// Mas os indicadores apresentam uma falha devido à falta de barras! É aí que o descontentamento é justificado!
// Então tolera mesmo que... :) Bem, temos de... :(
2.
Isso é exactamente não e não! O esquema circular é exactamente o que leva a enormes poupanças na cópia de turnos de história. Na verdade, ao mudarmos por uma barra (N barras), temos de copiar exactamente um valor (N valores). Os custos(do utilizador) da virtualização do índice são negligenciáveis. De facto, são mesmo difíceis de detectar em testes de stress(o resto da divisão é calculado pelo processador durante um ciclo de relógio + a deslocação do buffer virtual começa em cada turno ao longo da história leva mais um par de ciclos de relógio). Portanto, não há quase nenhuma perda de velocidade. É impossível detectar esta desaceleração, é tão pequena. E no fundo de uma enorme poupança de memória, estas perdas são incomensuráveis com o ganho.
3.
Ehhh, um rosto...
Por alguma razão, há tanta dança e gritos sobre indicadores engasgando-se em barras ilimitadas, mas nem uma palavra sobre objectos gráficos dançantes. Tentar construir, por exemplo, o super grande Andrews' Pitchfork on Unlimited (em MN1, por exemplo), depois limitar o número de barras nas definições dos terminais, ir para prazos baixos e rebobinar para os pontos de ancoragem. Alguns deles estarão num tremendo desfasamento temporal em relação aos extremos (isto enquanto as forquilhas dos três pontos se situam exclusivamente na área das barras M1 reais, sem ultrapassar os limites das falsas de prazos mais elevados!) E porquê? Aparentemente, porque não tínhamos dados históricos suficientes sobre M1 para calcular o valor exacto do M1 de alguns pontos de ligação automática. Mas o que é que os dados históricos têm a ver com isso? Bem, talvez fossem suficientes, mas as barras expostas na janela não o eram, daí os turnos. Ou seja, alguns pontos "não sabem realmente onde estão".
Quem me dera que alguém o verificasse por si próprio, ou talvez eu seja o único que tem tal confusão...
Tenho notado uma estranheza!
No momento da formação de uma nova barra, se ler valores Abertos e Fechados de barras anteriores (por exemplo 10 barras anteriores) e depois 5 segundos depois obtê-los novamente, então alguns destes valores são diferentes e depois, se os obtiver enquanto uma nova barra está a formar, então tudo está bem, mas nos primeiros segundos, por alguma razão, estes valores são diferentes.
Espero tê-lo explicado claramente.
Pode dizer-me se antes de ler os valores de Barras Abertas e Fechadas desde o início de uma nova barra deve haver um atraso de mais de 5 segundos?
Aqui está um exemplo de operação:
Acima é accionada correctamente após um atraso, abaixo imediatamente após uma nova barra com um erro, e à direita a referência para a 6ª linha.
Talvez o problema esteja dessincronizado, é aconselhável seguir a nova barra através de todas as ferramentas em uso.
Sim, acabou por ter razão, obrigado!
Da mesma forma, ópera.