Erros, bugs, perguntas - página 257
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
Não parece que assim seja.
Acontece que havia apenas 2 (de 45) ofícios perdidos, ambos comprados.
Talvez eu esteja a procurar no lugar errado?
Marcado a vermelho: As posições curtas são 5 em 45. Vamos supor que 40 é 95%. Pergunta - Porquê 5 = 100%, é lógico assumir - 5%.
Embora me pareça que neste caso deveria ser 5 (11,11%) e 40 (88,89%).
Tente limpar a cache. Tentei diferentes opções, diferentes navegadores - a adição foi bem sucedida.
Está a inserir uma imagem directamente num comentário e não como um ataque, não está?
Marcado a vermelho: As posições curtas são 5 em 45. Digamos que 40 é 95%. Pergunta - Porquê 5 = 100%, é lógico assumir 5%.
Embora, parece-me que deveria haver 5 (11,11%) e 40 (88,89%) trocas comerciais.
Um total de 45 ofícios:
Aqui temos os seguintes resultados
5 Venda de negócios - 5, e 100% deles foram rentáveis (não perdendo) (ou seja, todos os negócios foram rentáveis).
Compra de comércios - 40, 38 deles são lucrativos, ou seja, 38*100%/40=95%.
Mais
Negócios rentáveis - 43 de 45, ou seja, 43*100%/45 = 95,56%
Negociações por perdas - 2 em 45, ou seja 2*100%/45 = 4,44%.
Um total de 45 ofícios:
O número total de negócios que temos
Vender negócios - 5, dos quais ganhando (não perdendo) negócios - 100% (ou seja, todos eles foram lucrativos)
Compra de comércios - 40, 38 deles são lucrativos, ou seja, 38*100%/40=95%.
Mais
Negócios rentáveis - 43 de 45, ou seja, 43*100%/45 = 95,56%
Negociações por perdas - 2 em 45, ou seja 2*100%/45 = 4,44%
Tenho notado este efeito. Ao adicionar o indicador ao gráfico(numa janela separada), o gráfico principal do castiçal deixa de ser actualizado (o preço congela), embora na janela com cotações tudo esteja OK - o preço muda de vermelho para verde. Embora o indicador tenha sido adicionado apenas à janela de um símbolo, o preço também congela na outra janela. Inicialização e cálculo do indicador estão dentro do corpo: if(prev_calculated==0). Os preços de fecho que não começam a partir do dia anterior participam no cálculo (o preço de fecho actual não participa). Após o cálculo do indicador estar concluído, o preço começa a mover-se e a mudar em sincronia com a janela.
Pode vê-lo na fotografia:
Tenho notado este efeito. Ao adicionar o indicador ao gráfico(numa janela separada), o gráfico principal do castiçal deixa de ser actualizado (o preço congela), enquanto na janela com as cotações tudo está OK - o preço muda de vermelho para verde. Embora o indicador tenha sido adicionado apenas à janela de um símbolo, o preço também congela na outra janela. Inicialização e cálculo do indicador estão dentro do corpo: if(prev_calculated==0). Os preços de fecho que não começam a partir do dia anterior participam no cálculo (o preço de fecho actual não participa). Após o cálculo do indicador estar concluído, o preço começa a mover-se e a mudar em sincronia com a janela.
Pode vê-lo na fotografia:
O primeiro cálculo revela-se muito intensivo em recursos. Verifique, talvez o código indicador não esteja escrito da forma mais óptima.
O primeiro cálculo revela-se muito intensivo em recursos. Verificar se o código indicador não está escrito da forma mais óptima.
Quis dizer que é possível separar a actualização das citações no gráfico do castiçal num fluxo de programa separado e o carregamento dos cálculos do indicador noutro fluxo.
A actualização das citações no gráfico é apenas uma exibição dos dados da base de dados do terminal, que também é utilizada para calcular os indicadores. Para poupar recursos, os dados da base terminal são passados para o indicador como dados de entrada, ou seja, não podem ser alterados até que o indicador seja calculado.
Caro alexvd, infelizmente o Indicador tem agora mais de 3000 linhas de código que consistem em mais de 20 classes e é bastante difícil optimizar o código (várias centenas de biliões de operações computacionais em loops), enquanto que este número pode crescer até cerca de 10000. Quis dizer que é possível de alguma forma separar a actualização das citações no gráfico do candelabro num fio de programa separado e o carregamento dos cálculos do indicador num fio separado. Francamente falando, quando comecei o meu trabalho, não esperava que a questão do desempenho surgisse tão urgentemente num computador de secretária, enquanto que também quero utilizar um pequeno computador portátil.
Tentar optimizar o indicador, o número de objectos e linhas não é importante. Muito provavelmente é possível fazer o indicador existente (com 3000 linhas) funcionar com a velocidade necessária.
Uma variante interessante é colocar todos os cálculos de recursos intensivos em temporizador (se parecer possível), então estes cálculos não serão efectuados em cada tick.
E gostaria de optimizar a caixa da calculadora tanto quanto possível (para limites razoáveis).
Tentar optimizar o indicador, o número de objectos e linhas não é importante. Muito provavelmente é possível fazer o indicador existente (com 3000 linhas) funcionar com a velocidade necessária.
Uma variante interessante é se colocarmos todos os cálculos de recursos intensivos num temporizador (se possível), então estes cálculos não serão efectuados em cada tick.
E o bloco da calculadora deve ser optimizado tanto quanto possível (dentro de limites razoáveis).
Em princípio, é possível optimizar um pouco o trabalho, porque alguns dados idênticos são calculados em objectos de classes diferentes, ou seja, não uma única vez. Mas aqui enfrentamos outro problema, nomeadamente - afastando-nos do conceito de muitas caixas negras, cada uma das quais pode ser depurada e ter confiança nela (ou seja, cada objecto é uma unidade totalmente autónoma, e se o cálculo de alguns dados intermédios, que são idênticos em objectos diferentes, se mover fora dos objectos, perde-se a autonomia, permitindo depurar cada classe separadamente. Neste caso, a estruturação do programa perder-se-á, ou seja, não conseguirei compreender o que escrevi e um mínimo erro será impossível de apanhar. A velocidade de depuração também aumentará drasticamente, pois terei de executar todo o algoritmo em vez de apenas uma parte dele. É assim que o número de objectos influencia a velocidade.
É por isso que penso que uma optimização semelhante pode ser tentada na fase final, quando o indicador é completamente criado, depurado e testado, mas infelizmente ainda está muito longe (estou a trabalhar na fase inicial há cerca de 4 meses, desde que finalmente percebi que estou pronto para o experimentar). Em livros sobre Econometria e Matemática tudo está disperso em fragmentos em diferentes livros (não existe uma apresentação material praticamente unificada em detalhes), os autores têm erros e discrepâncias em termos e algoritmos, que só são encontrados por principiantes quando se referem a dicionários enciclopédicos, a informação teórica entra em conflito com a possibilidade da sua realização prática, ou seja, a realização sob a forma de métodos numéricos, e os próprios métodos numéricos, por sua vez, fazem exigências à funcionalidade do ambiente de software), o processo é longo e entediante e viscoso.
De acordo com a lógica de cálculo, deve ocorrer após a formação de cada vela, pelo que inicialmente era suposto ser colocada no corpo da função "é nova barra", mas o facto de o seu tempo poder exceder este intervalo fez-me colocá-la no corpo da função se(prev_calculado==0) para que ocorresse apenas uma vez na fase de depuração. Vou pensar na sua sugestão de temporizador - obrigado.