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
E você também pode adicionar o drawdown como porcentagem, para que seja mais fácil de ver. >> Obrigado.
Isto pode ser o início de um conversor FSB para MQL4.
Qualquer ajuda ou feedback é altamente apreciado.
Seria bom se a FSB pudesse gerar uma dll com a estratégia e a função pudesse ter este aspecto:
que é enviar uma série de barras para a dll e obter uma resposta da estratégia
A dll em si é assim
você tem todos os seus próprios indicadores de qualquer maneira e só precisa de dados de séries temporaisFornecerei mais tarde a ponte completa FSB <-> MT4.
Portanto, a FSB levará as informações de cotação e conta da MT e enviará de volta as ordens de negociação. Dessa forma, poderá comercializar as estratégias de FSB na MT.
Agora estou tentando fazer algumas estruturas básicas de EA para se adequar às estratégias de FSB na MT como EA sem nenhuma interoperação.
Eu preciso de vários padrões simples como:
* Entrar (adicionar, reduzir, fechar) na Abertura da Barra (ou valor do Indicador) quando:
- condição1 == verdadeira; e
- condição2 == verdadeira; e
- condição3 == verdadeira; e
- condição4 == verdadeiro
* Sair no Bar Fechamento quando:
- condição1 == verdadeira; ou
- condição2 == verdadeira;
ou
* Saída no valor do Indicador.
ou
* Saída em Parada Permanente de Perda
ou
* Reverta seguindo as regras de entrada.
A maioria dos indicadores é padrão e os outros são bastante simples e podem ser facilmente reescritos em MQL4. Quando tivermos o padrão EA básico, não haverá problema para traduzir os indicadores.
As coisas que estou testando agora são:
Posição aberta em "Abertura de Bar" e fechamento em "Fechamento de Bar".
Espero, portanto, desenvolver dois novos produtos:
1. FSB - Ponte de alimentação e execução de dados MT
2. exportador estratégico para a MQL4
Provavelmente ambos os programas serão de código aberto.
(oh, eu pensei que o assunto estava calmo agora... vamos animá-lo :)?! (vou escrever muito ... vou tentar ser lógico ;), e não sobrecarregar o tema - vou dividi-lo em várias mensagens)
Cavalheiros, bem-vindos!
Miroslav - primeiro, um par de palavras "sobre o tempo" (a parte lírica). (Espero sinceramente que sua compreensão do russo esteja de acordo com o par :))).
O produto, é claro, é fantástico! Falo a partir de minha experiência, tanto como ex-programador quanto como usuário abstrato (software abstrato). Você pode sentir o amor por ele (porque tudo é feito com muito cuidado) e há esperança de que o desenvolvimento do programa não pare "de repente" (não morra). Sim, muito provavelmente há alguns erros lógicos (um exemplo ilustrativo foi com Data Horizon), há pequenos bugs na interface ... Mas no geral - ESTE É O FILHO! É apenas uma canção!!!
Peço ao público que preste atenção a outro fato revelador. A atitude em relação às críticas e o estilo de discussão dos problemas/falhas/novas características/etc. Este sou eu no contexto do início da linha, onde o desenvolvimento do produto alternativo começou, e como o autor da SSB reagiu aos comentários ao seu endereço. Não creio que Miroslav também tenha um "vagão" de tempo para desenvolver um programa GRATUITO (e que ele seja um programador assim). Mas ele encontra tempo para nós (para se comunicar), de acordo com nossos comentários e pedidos para finalizar o produto, conserta bugs e oferece algo novo (veja seus posts recentes). E tudo é calmo, medido, sem histeria, como no caso da SSB acima mencionado. Isso merece respeito (extra). Meus cumprimentos, Miroslav...
Para terminar a parte lírica (distraidamente agora) - que eu pessoalmente sou um adepto da teoria do "movimento aleatório de preços". Ou seja, nesta pergunta eu compartilho completamente a opinião de um certo círculo de pessoas (incluindo criadores de sites como http://www.bigmany.ru), que estão convencidos de que trabalhando no mercado (quero dizer Forex e "tudo que está perto dele") onde não há como reconhecer o segundo de (apenas) dois indicadores principais do mercado (quero dizer Volume). - é simplesmente inútil e sem sentido (desprovido de qualquer sentido razoável) confiar em qualquer informação de análise técnica e, em menor grau, fundamental...
Poderíamos ter terminado aqui em geral :), mas como você sabe - a Rússia é notória para tolos e estradas, e usando o primeiro ponto desta afirmação - ainda não deixo a idéia de "ganhar milhões" :D, na verdade - estou apenas curioso. É interessante ouvir "opiniões de analistas" (como os astrólogos com seus horóscopos - "muitos especialistas", pouco uso), é interessante apenas olhar para gráficos (você concorda - é incrível), é interessante brincar com códigos (você começa a entender realmente o que as pessoas tentam expressar com determinados indicadores), ... É simplesmente interessante... É interessante trapacear (ou melhor ainda - NÃO trapacear) o "sistema" um dia... É por isso que estou aqui (no mercado, condicionalmente). E espero me beneficiar não só a mim mesmo, mas também ao público. Porque, como Miroslav - algum altruísta na vida.
Minha opinião atual é que os sistemas de análise técnica que estão sendo usados atualmente em todo o mundo (e a clara maioria) estão de fato, INVOLVIDOS no mercado. Ou seja, a multidão de pessoas, olhando para seus monitores e guiadas pelos valores de seus indicadores, amigavelmente espera movimento em uma determinada direção, faz acordos... e move esse mesmo preço. Mesmo que em pequena escala, mesmo que nem sempre (ainda há proprietários de "fábricas, jornais, navios a vapor" que não se importam com TA, eles só precisam comprar ou vender um determinado volume em um determinado momento). Mas isso acontece! Em outras palavras - estando "no circuito" (do mesmo AT), você pode tentar mudar a probabilidade de seus movimentos aleatórios positivos no mercado para (ligeiramente?) mais de 50%. Não é fácil... MAS possível! Assim que eu me decepcionar com este postulado - deixarei o mercado... (e não será sobre o tamanho dos lucros/perdas, é apenas, bem, realmente frustrante e inútil trabalhar dentro de um sistema completamente aleatório... bem, ver acima)
Portanto, agora aos negócios.
1. Enquanto houve aqui uma pausa - eu estive pensando. Sim, podemos esperar por Miroslav (quando ele faz a ponte entre MT e FSB, ou aqui, compilador de estratégias). Mas, no final - aquele que pelo menos faz algo sozinho obtém o resultado :). Parti do pressuposto, que tenho (garantido) uma determinada ferramenta (FSB), tenho MT, vamos supor, que além dessas duas entidades não haverá mais nada - portanto operamos dentro de sua estrutura, ou seja, operamos dentro de sua estrutura: O FSB (no momento) é um sistema fechado; precisaremos da MT de qualquer forma; o código de consultor (robô comercial) será necessário em qualquer caso - sim, deve haver um modelo universal, que (aproximadamente) forneça valores de indicadores e tudo, então de acordo com o "esquema aprovado"; então precisaremos dos próprios indicadores.
2. Vou parar imediatamente no código Expert Advisor. Não compartilho do otimismo dos criadores de simples Expert Advisors - bem, é impossível imaginar o número de situações anormais no terminal e no mercado. E estamos falando de dinheiro, nenhuma brincadeira é apropriada (eles não verificaram o código de erro - eles calcularam alguma ação padrão... e é isso, -$1.000 se foi (condicionalmente)). Ou seja, estou convencido de que qualquer especialista que realmente lide com dinheiro (ou, melhor, com dinheiro real) deve ser "ironclad" em termos de reações a eventos externos. O código deve prever um número máximo de variações no terminal, servidor, ou no próprio mercado. Em resumo - é bastante sério, e não pode ser resolvido (por escrito) com um salto. Eu ficaria feliz em participar da criação de tais padrões. Mas...
3. Decidi ir até o fim desde o fundo. Tive uma idéia - se não há nada para operar para um Expert Advisor (indicadores) - para que precisamos então de um Expert Advisor:)! Por isso, tomei os indicadores.
A premissa era a seguinte. Primeiramente, ninguém garantirá que os valores dos indicadores em FSB sejam equivalentes aos valores dos indicadores padrão ou adicionais em MT. E para obter resultados "comparáveis" em ambos os programas - os valores devem ser os mesmos. Em segundo lugar, o número de indicadores em si (padrão) é SEMPRE diferente. E para usar (e procurar) externos... de alguma forma eu gosto ou do padrão ou do meu próprio (na vida). (Terceiro - tenho a impressão de que a "conversão" do código indicador da FSB não é uma mega tarefa, como Miroslav mencionou - os algoritmos em si são bastante simples, os indicadores em si são muito "organizados" em termos de código (o código é unificado), ou seja, mais ou menos falando - eles criam um conjunto de erros.Grosso modo, criamos um modelo uma vez e o "preenchemos" com alguns índices um a um (esta é a imagem ideal do mundo :))). Há mais no quarto - eu estava me perguntando :).
De qualquer forma, o fim-de-semana foi assim mesmo. Antes de começar algo, eu normalmente "levo muito tempo para aproveitar" (neste caso - pense). Eu não tenho tempo para modificar o modelo em si (entendo isso). Especialmente quando o número de indicadores excede um determinado número. Portanto, os pontos-chave devem ser projetados de uma só vez. Como resultado, eu fiz as seguintes suposições:
- Estes devem ser indicadores (e não apenas funções para o futuro código do Expert Advisor). Afinal, a percepção visual das informações não desempenha o menor papel para um humano (e para mim, em particular), e a chamada de um indicador do código do Expert Advisor não é um problema tão grande (o iCustom já causou muitos problemas no fórum - quando há tantas opiniões, eu geralmente prefiro verificar tudo sozinho, os resultados dos meus "testes de campo" servem, provavelmente há uma pequena sobrecarga, mas NÃO é um grande (isto eu declaro com total responsabilidade) e acho que pode ser negligenciado em termos de universalidade). Mas para os "conhecedores especiais" :) (só por precaução) caso os cálculos em indicadores sejam feitos em uma função separada do mesmo tipo (ver abaixo).
- Os indicadores devem emitir os mesmos valores que no FSB original (item negociado separadamente abaixo). Isto é, o código da FSB é tomado como base e, se possível, modificado o mínimo possível.
- O código deve ser otimizado para funcionar corretamente com o IndicatorCounted (ou seja, por velocidade)
- Os parâmetros indicadores, assim como seus valores, devem ser uniformes e homogêneos. Não estou falando de tipos de dados, como tal. Se você olhar o código de indicadores de Miroslav, você poderá ver uma boa homogeneidade de parâmetros de entrada e buffers de saída. A tarefa é manter a imagem inicial para ajudar os usuários a serem facilmente guiados ao indicar parâmetros ou tomar valores indicadores.
- A implicação do ponto anterior é ... mm (atenção - isto é importante). O ponto-chave sobre o uso de todos os indicadores não é que eles gerem quaisquer valores próprios. É que eles produzem SIGNALS! Realmente, para mim como pessoa - que diferença faz o valor de um índice agora ou mais tarde(?!) Ainda são "números incompreensíveis". Compreensível é quando é "Comprar" ou "Vender" :). Tudo o resto é "pouco claro"! Miroslav usou esta idéia muito elegantemente criando dois buffers em cada indicador (para posições longas e curtas) que, dependendo de como o indicador é usado (como Ponto da Posição ou Condição Lógica), obtêm valores de abertura/fechamento de uma posição ou do filtro Sim/Não (se todos os "Sim" na lógica de abertura - abrir, se pelo menos um "Não" na lógica de fechamento - fechar (em geral RTFM). Gênio! ;) Eu segui este caminho e simulei este comportamento. No momento, os dois primeiros buffers do indicador (cujos valores podem ser vistos na Janela de Dados) são os buffers correspondentes com filtros (1/0) ou com os valores do preço para abrir posições para o lado longo ou curto, respectivamente. Mais tarde, ao utilizar os indicadores no código do Expert Advisor, não importa realmente o que, onde ou que valores um determinado indicador gera - ele apenas analisará os valores dos dois primeiros buffers para um assunto muito simples (Sim/Não (condicionalmente) ou tomar diretamente o preço a partir daí) ... E é isso! Há uma nuance - quase 100% "tropeça" em Ishimoku (ali, a quantidade de amortecedores do próprio indicador está próxima do limite da própria MT (8)) - Não quero recusar uma boa idéia (com os dois primeiros amortecedores), mas não posso combiná-los em um só (estava pensando... poderia haver não apenas 1/0 (que poderia ser transformado em uma bitmask), mas também etiquetas de preço). Muito provavelmente terei que fazer algo com os próprios valores indicadores. Veremos... Enquanto vamos...
Em geral, em resumo (resumos): qualidade (compatibilidade com FSB, livre de bugs, etc.), facilidade de uso posterior, velocidade, legibilidade do código. Nesta ordem.
Bem, e (na verdade) - o que aconteceu ... (breve histórico)
- Todos os indicadores têm o valor "fsb" no prefixo do nome do arquivo (exemplo: "fsbBlaBlaBla.mq4").
- Eu peguei os indicadores em uma ordem pseudo-aleatória, então não me culpe. Até agora, há, isto é. Para mais discussão/análise etc. - Acho que é o bastante.
- Miroslav usa três funções externas (que são colocadas nas fontes (na parte inferior da página)) para calcular a média móvel e os valores dos buffers lógicos. Eu tive que começar com eles. Todas as funções são agrupadas em um arquivo (" fsbCommon.mq4 "), organizadas como funções de biblioteca (" fsbCommon.mqh "). Existe outro arquivo desta ópera (" fsbConstants.mq4 "), que, respectivamente, contém constantes por conveniência no código. Não houve problemas especiais com as próprias funções (compliquei um pouco a lógica inicial dos "osciladores lógicos", para verificações adicionais (arrays fora dos limites, valores iniciais corretos garantidos (o primeiro na história) (Miroslav, há um erro lógico no código deste tópico).. .e tentei por muito tempo "emular" o comportamento do iShift em MovingAverage para que a função preencha corretamente os valores do buffer resultante para qualquer valor são desse parâmetro (e não apenas para aquelas restrições que são dadas no código original original)... como resultado, abandonei este assunto por enquanto, colocando um "stub" no início (com iShift diferente de "0" a função não trabalho ainda, o que, no entanto, ainda não foi necessário)). MovingAverage acabou sendo complicado, mas mata vários coelhos com uma cajadada só. Como retornar o buffer da função como um valor em MT, não é possível (talvez não necessário) - um parâmetro adicional apareceu no final ( afTarget ) Além disso, considerando IndicatorCounted (), mais uma etapa O parâmetro é responsável pelo valor da primeira barra para processamento. Bem, o último parâmetro adicional define a "constante de preço" em termos de MT, pelo valor do qual os valores da MovingAverage em si são calculados com base nas matrizes de séries existentes ou (se o valor iAppliedPrice fora dos valores de "constantes de preço" MT) - com base em aFonte . (daí a sobrecarga do código) Vou especificar imediatamente a nuance da programação - onde há ciclos intercalados com seleções por caso - os ciclos são inseridos dentro das seleções, e não (o que geralmente é mais lógico) vice-versa. Feito não porque não sei como fazer direito - mas porque sei o quão rápido :)! (bem, no futuro, não vou me alongar sobre isso, quem quiser analisar o código - de nada, mas antes de fazer a pergunta "sobre a estupidez do código" pense um pouco sobre o que (potencialmente) poderia causar tal programação).
Outra nuance está relacionada ao MovingAverage (pode ser informativo para alguém) - porque. Os valores de média móvel nos modos de suavização exponencial (incluindo suavizado) dependem diretamente de seus próprios valores anteriores - a escolha do "ponto de partida" se torna muito importante (qual valor tomar como base para cálculos adicionais). Normalmente existem várias abordagens para isso. Alguém pega o preço de fechamento do período anterior. Alguém fez a média do preço do período anterior N... Miroslav foi pelo segundo caminho. MT claramente vem em primeiro lugar. Daí as discrepâncias significativas nesses dois modos de suavização no início do gráfico (adicionei um espaço em branco para testar MovingAverage e tudo mais (" fsbTest.mq4 "))! E as restrições impostas por mim dentro da função sobre a disponibilidade de dados do próprio MovingAverage ANTES iFirstBar, ou uma quantidade semelhante de valores calculados DEPOIS iPrimeira Barra. Porque os próprios indicadores usam uma constante para o valor mínimo de barras no gráfico (agora 2000) - isso deve ser suficiente para qualquer situação (porque ainda não vi parâmetros com períodos superiores a 200). A menos, é claro, que mais de um MA seja usado por vez;).
- Por analogia com o parágrafo anterior, foram criados arquivos para subfunções externas que já utilizo no meu trabalho com este projeto (prefixo "st": " stCommon.mq4 ", " stCommon.mqh ", " stConstants.mq4 ")
- Bem, na verdade - os próprios indicadores. Em termos muito curtos (vamos tomar " Bar Range " como exemplo):
tipo de slot conjuntos tipo slots dentro Termos FSB (Ponto da Posição ou Condição Lógica) . Esses indicadores que podem ser não apenas filtros de entrada/saída, mas também definir o preço de abertura/fechamento - este parâmetro determina exatamente o que o indicador irá gerar em seus buffers lógicos. Veja todas as constantes em fsbConstants.mq4 (tudo está bem claro lá)
indLogic - na verdade, uma condição lógica para o indicador (carrega uma carga semântica diferente, dependendo do valor tipo de slot )
Bem, os parâmetros vão além, na ordem em que aparecem nas fontes do indicador em forexsb.com e como são exibidos no próprio FSB. Os limites de parâmetro são especificados nos comentários e são controlados ao chamar init() chamando a subfunção PCheck().
Com buffers, tudo no nível global é usado como buffers de indicador (anexados ao próprio indicador). Apenas as lógicas desejadas (LPIndBuffer[], SPIndBuffer[]) (sempre e sempre nesta ordem (#0 - posições longas, #1 - posições curtas)), IndBuffer[] - dados do próprio indicador. Mas neste caso, como é usado um histograma de cores, esse buffer carrega apenas os próprios valores, e dois buffers adicionais são usados para renderização de cores (para ser honesto, o MT começou a programar apenas transferindo indicadores :), e como você pode simular o comportamento de histogramas de cores dentro do MT de outra forma - eu nunca inventei isso (quem pode dizer? Se isso é possível)). Eles não são exibidos no DataWindow de forma alguma.
NO iniciar() tudo está como de costume (os valores dos parâmetros são verificados, os nomes do próprio indicador e os índices são definidos, os buffers são anexados etc.)
Em deinit(), estou pensando em inserir lógica no caso de NÃO fechar o indicador (conveniência adicional, para que os parâmetros, lá, não sejam redefinidos, etc.), à minha vontade (ainda não é uma prioridade).
começar() muito primitivo. Sua tarefa é verificar se há barras suficientes no gráfico (para calcular qualquer MA e em geral) e chamar a função para calcular o próprio indicador, após a chamada bem-sucedida, o desenho personalizado do indicador é chamado (se for necessário ser desenhado de alguma forma de uma maneira especial, como neste caso como -once)
Calcular() - cálculos reais. O código, em geral, é semelhante ao código de Miroslav, exceções são feitas para otimizações relacionadas a IndicatorCounted(). Se buffers de indicador adicionais são necessários para calcular o indicador, eles são definidos dentro da própria função (estática) (para não desperdiçar os índices do próprio indicador) e são atendidos pela função BufferSync(). Aqui está uma piada separada - inicialmente houve uma tentativa de limitar os cálculos por mais um parâmetro constante (iMaxBars). "Testes de campo" (parte 2) do comportamento de arrays de séries na presença de histórico, ausência, movimento para o futuro (a chegada de aspas, aumento de arrays à DIREITA (agora estou visualmente, sobre a representação gráfica )), ... movimento para o passado (quando falta o histórico (nos movemos para a esquerda no gráfico) e o terminal o carrega do servidor... e os arrays se expandem para a ESQUERDA)... Então. .. Interrompeu. Eu fiz isso lindamente (tentei fazê-lo) - dependendo da direção da expansão BufferSync () e expande a matriz resp. esquerda ou direita, preenchendo os valores vazios de EMPTY_VALUE. Aqui apenas o próprio MT normalmente não expande matrizes de índice para a ESQUERDA. Ele SEMPRE os expande para a direita (do lado da barra [0]). Espero que esteja claro do que estou falando - que durante o próximo salto na história, quando o valor das barras no gráfico exceder iMaxBars (pulando, novamente) - as situações são bem possíveis quando o indicador não desenha seus valores à esquerda do iMaxBars, mas aqui estão "dados estranhos" dele, à esquerda do iMaxBars pode ser facilmente. Talvez ninguém os veja... Mas "não são bonitos" (não é o nosso método). E tudo o que é necessário é que o próprio MT complemente os buffers com valores vazios na direção certa ... É potencialmente possível pegar essa situação, mas ... Em geral, desenhamos desde o início do gráfico... _sempre_. (Bem, na medida do possível para este indicador específico)
Outra nuance está associada a IndicatorCounted() - ao que parece - uma função divina. Devolva os valores das barras calculadas e não haverá reclamações contra você... SERÁ! Acho que não é o próprio IndicatorCounted() o culpado (assim como os programadores do MQ), mas um monte de programadores de indicadores personalizados, que não atingiram o propósito divino dessa função. Portanto, é forçado a sempre retornar um pequeno número de valores potenciais. Ou recalculamos todo o gráfico (IndicatorCounted() == 0), ou a primeira ((IndicatorCounted() == Bars - 1) ou duas (IndicatorCounted() == Bars - 2). por exemplo, se a conexão for interrompida e o gráfico "correr" mais de uma barra à frente - isso é tudo ... "árvores morreram em pé" (IndicatorCounted() == 0) - contamos todo o gráfico em um novo Por quê? era impossível retornar o número de barras ignoradas (3, 4, ... 5... 10...)? (para que essa função se destinava, pelo que entendi, inicialmente) Em geral, assim. ..
... Eu "tropecei" no RSI. E em todos os sentidos. Em primeiro lugar, eu não entendi o código de Miroslav (perguntas para ele vão abaixo). Em segundo lugar, ao testar o indicador, vi discrepâncias nos valores obtidos dentro de MT e FSB! Não, não é nada do que você pensou ("suportou torto" - bem, admita, você pensou;)). O ponto, infelizmente, parece estar nestas declarações:
Resumindo - flutuar ! Depois de pensar um pouco, eu desacelerei por enquanto. a primeira tese (exatidão e qualidade) tornou-se questionável (e é uma prioridade).
O seguinte raciocínio é possível aqui: Por um lado, o float não é ruim, é, por assim dizer, uma "rugosidade" dos valores do indicador, o que deve tornar a estratégia de negociação ainda menos suscetível a picos aleatórios no mercado. Por outro lado, por exemplo, ao cruzar algum fLevel (1.0, por exemplo) - você concordará: 0,99998 e 1,00001 são duas grandes diferenças :). E há essas discrepâncias. E se a pose abre em tal e tal momento, mas na verdade o nível do FSB ainda não atinge 1.0 e desce, então quem é o culpado? (aquele que transferiu os indicadores :D?!)
Na verdade, existem duas soluções (dado que o float MT não é suportado!):
- emular um float no próprio MT (com algumas construções dolorosas como NormalizeDouble(X, Digits + 2) ) - bem, não em todos os lugares, mas considere que cada multiplicação/divisão por qualquer
- alterar float no FSB para double. Aqui você precisa entender o alcance das mudanças, obviamente finitas, mas você precisa caminhar com cuidado por toda parte. E que o resultado potencial das estratégias geradas em humanos pode “flutuar”. E, em geral, Miroslav precisa disso? (minha humilde opinião é que o próprio FSB precisa disso, pois precisão extra nunca prejudicou ninguém, mas na velocidade dos cálculos (se esse objetivo foi perseguido (?), porque não vejo mais motivos) nesta seção de tempo da realidade Não deve ter nenhum efeito significativo.) Eu concordo com essa questão com os caras do MQ - porque. se não operarmos com matemática inteira (algum Decimal), então pelo menos tentaremos com a máxima precisão possível. Em geral, aqui está um ... não é uma pergunta fácil ...
Desculpe por ser verboso (não direi mais nada, apenas a essência).
Eu gostaria de ouvir uma opinião - este assunto deveria continuar (e depois "ir" mais longe, o resto dos indicadores a serem pesquisados)? Posso até mesmo em alguma ordem (já que mesmo assim a bagunça original :)), que, talvez, o que precisa ir adiante. O tempo, infelizmente, no caso geral é privado (vice-diretor geral em seu escritório - "o dia voa sem ser notado" :D). Eu encontro o tempo normalmente à noite. Mas um ou dois indicadores por dia, acho que posso fornecer...
Portanto, perguntas para Miroslav sobre o tema...
1. Qual é o valor do fMicron? (eu o defino (na reflexão) para 0,000001, ao que parece, ou ele é ainda menor?
2. Qual é o parâmetro bIsDescreteValues (na lógica do oscilador). Eu entendo o significado disso - mas qual é o seu valor padrão? E de que condições depende a mudança? (ou digamos - a que está relacionado (na interface FSB ou onde mais))
3. Na verdade sobre a RSI, o que é este projeto?
:)? A motivação para a pergunta é a seguinte: Se minha visão estiver correta - é um MA suavizado. No contexto do código inteiro - é aplicado ao MA já calculado e gera MA suavizado, onde apenas o primeiro valor permanece "vivo" :) Uma espécie de pergunta lógica - o que é supérfluo aqui? Esta construção, que entre outras coisas torna REALIZADO(!) a escolha dos modos de suavização do RSI no próprio indicador (ele sempre se torna suavizado), bem como em seus dependentes. Ou cálculos de MA anteriores (com modo correto a partir de parâmetros) para afPos, afNeg?
Claramente, o RSI clássico se baseia na média suavizada. Mas há pelo menos uma variante com MA simples e seria lógico remover o código acima tornando operacional o comportamento do parâmetro maMethod. Ou removemos o cálculo de MA antes deste ciclo e removemos os parâmetros de MA RSI em todos os indicadores (já que eles não afetam nada de qualquer forma!).
Eu retiraria este código (acima) :). (No indicador convertido esta parte é comentada, quem precisa da funcionalidade original - remova as tags de comentário! O código RSI é apenas para referência... Até decidirmos aqui, eu o utilizaria "por minha conta e risco" :))
4. Como já foi dito, há um erro lógico não crítico na lógica dos osciladores no comportamento nas barras iniciais. Não posso fazer isso agora, vou escrever amanhã (onde e como corrigir).
5. O que devemos fazer com a flutuação na FSB? (ou com falta dela em MT) :)?
O arquivo contém os arquivos necessários, desembalados para a raiz MT (o arquivo estará no próximo post)
Boa sorte a todos... escrever :)Arquivo indicador atual (2009-04-15)
Concordo que a bóia não funciona - precisamos procurar uma saída. Precisamos escrever a correspondência. Em seguida, criar uma biblioteca de indicadores. Se eu puder ajudar, ficarei feliz.