Erros, bugs, perguntas - página 680
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
Uau, como você é gentil. Desculpe, esqueci-me que era o seu fim-de-semana. E quanto a nós? Talvez fosse melhor libertar as construções às segundas-feiras para que não houvesse tais mal-entendidos? Não temos dias de folga. Nós (comerciantes, não programadores) preocupamo-nos com a qualidade da plataforma. E para que é que está a torcer?
Não se preocupe - vamos verificá-lo e corrigi-lo.
Por agora, pode usar o modo tiki, como antes - é a única opção fiável para testes. Utilizar os outros métodos apenas para uma avaliação grosseira da estratégia (independentemente do que o autor da estratégia pensa).
Cabe ao programador analisar os dados. A pergunta acima foi puramente privada e não teve nada a ver connosco ou com o terminal.
"Eu não sou eu e o cavalo não é meu". Clássico.
Isto é, curiosamente, sobre Thomas, não sobre Yeroma: não sobre a nossa análise, mas sobre a vossa síntese de TFs sénior, mantendo alguns - nomeadamente temporais - atributos precisos do objecto chamado barra. E é tudo. Não há mais nada de que precise para ser feliz como programador.
Basta pensar quantas rotinas ineficientes estão a acontecer: vocês, criadores do terminal, assumiram a responsabilidade pela criação do sénior TF da M1, mas a boa ideia estava morta, e depois da vossa síntese deveríamos fazer a operação inversa - análise de dados! Qual é o jogo do "arquivamento-desanquivo-arquivamento"?! Qual é a piada disso? Se já inventou a síntese, faça-a o mais eficiente possível: forneça os seus resultados com dados mais informativos. Então, vamos a isso...
1. cabe ao programador analisar os dados. A pergunta acima foi puramente privada e não tem nada a ver connosco ou com o terminal.
2. as suas perguntas sobre barras em falta devido ao seu desconhecimento da situação do mercado. Veja as tabelas de stock ou de futuros para alargar os seus horizontes e as perguntas sobre "não deve haver buracos" desaparecerão instantaneamente.
3. estas são palavras gerais. Especialmente sobre a estratégia.
Renat, estás muito enganado quanto à particularidade excepcional desta pergunta. Queres uma votação no fórum sobre esta pergunta "excepcionalmente privada"? Ela dissipará instantaneamente as tuas ilusões.
2. já o vi. Então? Muitas barras em falta? Também não tenho ilusões a esse respeito. Tenho uma pergunta. Não é de todo original e de forma alguma "exclusivamente privado". Nomeadamente: o modo de acesso (e exibição!) às cotações (incluindo, sim, sim!, as de baixa liquidez) automaticamente (!!) suportado pelo fabricante do terminal, no qual todos os buracos intra-sessão nas cotações são preenchidos com dodges com os parâmetros {Volume=0, Aberto=Alto=Baixo=Fechado=[preço anteriorde fecho de barra]}. Ou serei eu um grande original? Sê honesto, Renat. Colocando a mão direita no coração esquerdo.
3. OK. Vamos abandonar a estratégia. É apenas a minha especulação.
Convido a um pouco de espaço de agitação.
Algures nas profundezas da história existe uma barra D1- teoricamente são barras de 60*24=1440 minutos. Usando CopyTime(), mordemos nos seus bordos um segmento na expressão M1-história e procuramos o hi- e o low extrema com ArrayMinimum() e ArrayMaximum() na forma mais precisa e volumosa. Para encontrar a hora exacta de um extremo de uma barra, é um piscar de olhos, mas e se precisarmos de calcular centenas? Mas é preciso! Afinal, ninguém tem o direito de dizer "ei, pára, não queres isso" e até de nos censurar por uma abordagem errada dentro dos limites das ferramentas que nos são fornecidas. E quanto mais a barra especificada estiver na história, mais lento é oCopyTime() a lidar com ela. Depois há esta conversão demoníaca entre o tempo da barra e o seu índice! Não, não sou a favor da exibição de barras perdidas, prefiro concordar com a ideologia da MetaQuotes, mas não posso deixar de notar que tal conversão é também intensiva em termos de recursos, confusa e inchada do código. Se houvesse sempre exactamente barras de 60 minutos numa hora terminal (barras de 24 horas num dia, etc.), poderia seleccionar imediatamente a barra de índice necessária através de simples operações aritméticas de multiplicação, adição e subtracção - não a perderia de certeza... e sem conversão em duas faces.
Assim, à questão de pentear através de 1440 barras em busca de um extremo... Digo-lhes que é uma actividade sem sentido. E por falar em esperteza... - existe uma alternativa?
Apenas uma coisa me veio à cabeça (e já passou um ano, por isso nem sequer era uma alternativa, mas uma solução básica, que eu perguntei aqui, mas nunca ninguém respondeu): será o método de interpolação adequado para puxar o valor exacto do tempo? Nomeadamente: manipulações de substituição sequencial com prazos cada vez mais baixos até M1? Ou seja, temos de fazerCopyTime()'s com subperíodos de interesse, que não é uma amostra de desempenho, e depois substituí-los numa matriz. Na ideia, é feito dezenas de vezes mais rápido do que uma leitura completa de 1440 barras: em D1 temos 6xH4, em H4 - 4xH1, em H1 - 2xM30, em M30 - 2XM15, em M15 - 15XM1. No máximo em cada período, obtemos o número total de passes:
em D1: 6 H4-bars, encontrou um +
em H4: 4 H1-bars, encontrou um +
em H1: 2 M30-bars, encontrou um +
M30: 2 M15-bars, encontrou um +
em M15: 15 M1-bars, encontrou uma = 29 iterações no máximo contra 1440!!!
Parece: a vantagem é óbvia. E agora pensem, o cristal e a RAM não se engasgariam com todos aqueles matryoshka BDSM-CopyTime()' s em loop durante vários períodos... Eu, pessoalmente, estremeço ao pensar nisso. Depois há todas aquelas verificações de disponibilidade simultânea de dados de diferentes prazos, que podem nunca acontecer, sincronização, etc... E todas as paqueras com a selecção de múltiplos de TFs mais baixos para os mais altos não-padronizados - estou farto de falar em voz baixa. Parece que o meu trabalho de co-decisão se enraizou na direcção errada.
De qualquer modo, não sei quanto a si, mas já não tenho qualquer entusiasmo por perder tempo a trocar um monte de códigos.
É claro que sei que o xerife não se importa com os problemas indianos. Então para quem é o terminal?
Convido-vos a pensar um pouco.
............
..........Claro que compreendo: o xerife não quer saber dos problemas indianos. Então para quem é o terminal?
É tudo dolorosamente familiar. E irritante ano após ano. x100intraday, vamos fazer uma votação, ver quantas mais pessoas ficam fartas dela.
É tudo dolorosamente familiar, e fica irritante ano após ano. x100intraday, vá em frente e faça a sondagem, vamos ver quantas mais pessoas ficam excitadas com isso.
Se é importante em princípio que o faça, instrua-me (aqui mesmo ou em privado), mas se não o fizer, é melhor que o faça você mesmo, eu sou a favor.
P.S.: E eu não acredito nas urnas eleitorais. Olhe para mim: como membro activo de vários fóruns e blogs, por mais que ultrapasse algo que não me diz respeito ou que simplesmente não tem tempo para ler, mesmo que seja meu. E nem todos podem votar, independentemente da relevância do problema para eles. E se o problema é totalmente estranho, então porquê todo este trabalho extra? Talvez não seja digno de um raciocínio assim, mas eu não sou o único com o problema. A votação é quase-objectivo. É preciso confiar sempre na objectividade, discrição e prudência do colectivo profissional, que afirma saber melhor do que nós, os utilizadores, o que precisamos e o que é mau para nós. ...Já para não falar de percalços como lançar votos entusiásticos não com base no princípio de "Putin é o melhor político de hoje!" mas "ele é o mais belo"!
É política utópica tornar um produto conveniente (= de alguma forma atractivo?) para uma maioria estatística de utilizadores e assumir que esta maioria irá consumir automaticamente o produto em massa. O rebanho tem uma estrutura hierárquica e segue sempre os líderes dos subgrupos. Até que isto se torne um axioma da sua estratégia de usabilidade, continuará a fazer cálculos errados na avaliação do potencial apelo dos seus serviços.
No contexto do acima exposto, existem recursos tremendos para aumentar a atractividade do terminal para as massas - por exemplo, para finalmente implementar uma história de minutos "sem buracos", a possibilidade de testar noutras citações, ordens CCA, e muitos outros serviços "estatisticamente não reclamados" que são de real interesse para os líderes intelectuais nos seus próprios fóruns (e não apenas escritos do nada).
Em MT4, funcionou assim: #importar "TrendLine\\\MemoryDLL.dll".
O engraçado é que já experimentei um monte de opções, incluindo esta.
O resultado é o mesmo - o ficheiro necessário não é encontrado (tenho de chegar a *.ex5).
Antes funcionava assim
#import "\DirName\FileName.ex5"Agora não funciona, nem as outras variantes.Tem medo de gastar tempo a calcular características de barras adicionais para casos muito raros (perto de zero %), mas alegremente exige que sejamos nós a preparar muitos dados em 100% dos casos, retardando e consumindo memória muitas vezes mais.
Alguns metodicamente dão conselhos tão bonitos para se matarem contra a parede, que é tempo de falar de pragas.
Os estrategas deste tipo são imediatamente visíveis.
Não parece estar a pensar muito à frente.
Tem medo de gastar tempo a calcular características adicionais da barra para casos muito raros(perto de zero %)
Tenho a sensação de que haverá uma votação :)