Nova MQL4 com propriedade # estrita

Bom dia,

Estou me perguntando sobre essa "MQL4 com #property strict", que incluo no código, mas a compilação sempre apresenta erros. Você pode explicar como isso pode ser corrigido? Quero dizer, para ter um código com essa nova condição de "#property strict".

Obrigado!

Olá,

Planejamos adicionar suporte à propriedade estrita para que você possa oferecer suas estratégias e, possivelmente, também fazer upload no mercado de MQL. A meta para disponibilizar isso é a próxima compilação 129 ou a compilação seguinte. Esperamos que isso esteja pronto em uma dessas compilações

Perfeito! Muito obrigado!

Ótima notícia
Excelente, vocês sempre oferecem o novo e o especial. Continuem assim e sempre estaremos apoiando.

cumprimentos,

Boa tarde,

Eu estava verificando a nova versão, mas vi que a propriedade # ainda está pendente.

Gostaria de saber se estou fazendo algo errado ou se isso não está incluído na nova versão.

Obrigado!

Olá, concordo que essa é uma solicitação relevante. Não se trata apenas de rigor, mas, pelo que me lembro, alguns indicadores estão usando a antiga estrutura de codificação MT.

Há uma solicitação formal de recurso?

Enyx

Olá,

A implementação está sendo trabalhada agora. Você poderá fornecer a versão especial do código da estratégia que atende aos requisitos do mercado MQL

Isso também será válido para a licença PROFI ou somente para a ULTIMATE?

Olá, Tomás,

Obrigado.

Se eu precisar ampliar um pouco o tópico.

Alguns outros produtos concorrentes (como o FXB) têm uma estrutura de indicador OOB muito bem definida, o que torna a codificação do indicador lógica e fácil. Além disso, o código do consultor especialista exportado é bem estruturado e mais fácil de depurar. Atualmente, apenas as opções de negociação estão próximas dessa abordagem.

Aqui está como eu imaginaria a situação da ideia:

1) Os indicadores SQX são baseados em OOB

2) O código de especialista SQX é baseado em OOB

3) Um modelo de indicador SQX baseado em OOB que segue a estrutura de código Java personalizada do SQ. Não devemos nos esquecer de que um indicador personalizado precisa ser implementado tanto em MQL quanto em Java. Já tenho uma tentativa de codificação que terei o prazer de compartilhar com a equipe da SQ. As vantagens são inúmeras. Fácil troca de código entre a implementação Java e a MQL. Mesma estrutura. Menos codificação, bugs e testes mais fáceis. Também permite a reutilização/inclusão de componentes em ambas as plataformas. É para isso que serve o OOB.

Código Java:

@Override
vazio protegido Na BarUpdate() lança a TradingException {
this.Calls++;

calcLow.onBarUpdate(Input.Low.get(0), CurrentBar);
calcHigh.onBarUpdate(Input.High.get(0), CurrentBar);

int tendência = 0;

double clow = calcLow.getValue(0);
double chigh = calcHigh.getValue(0);
double cc = Input.Close.get(0);

Se ((cc >= clow) && (cc <= chigh)) {
// No canal
tendência = 0;
{} else {
se (cc < clow) { trend = -1; }
se (cc > chigh) { trend = 1; }
}

// Retorna o resultado normalizado
Lower.set(0, calcLow.getValue(0,0,true));
Upper.set(0, calcHigh.getValue(0,0,true));
Trend.set(0, trend);
}
}

Código MQL:

for(int idx=ix_start; idx<=ix_end && !_StopFlag; idx++)
{
calcLow.onBarUpdate(low[idx],idx);
calcHigh.onBarUpdate(high[idx],idx);
UpdateExternalBuffers(idx);

int tendência = 0;

double clow = calcLow.getValue(0,0,true);
double chigh = calcHigh.getValue(0,0,true);
double cc = close[idx];

Se ((cc >= clow) && (cc <= chigh)) {
// No canal
tendência = 0;
{} else {
se (cc < clow) { trend = -1; }
se (cc > chigh) { trend = 1; }
}

Enyx

Enyx, não sei se estou entendendo. O que você quer dizer com OOB? Orientado a objetos?

Os indicadores SQX em Java são orientados a objetos. Você está se referindo às versões MQL4/5?

Isso é subjetivo, mas eu diria que a estrutura do código Java para indicadores no SQ é simples de entender, é mais simples do que no MQL.

A razão pela qual o código MQL dos indicadores personalizados no SQ às vezes não é orientado a objetos é simplesmente o fato de que alguns deles não são nossos - nós os reimplementamos em Java para o SQ, mas o MQL é original.

Não vejo grande vantagem em reimplementá-los em um design orientado a objetos em MQL. Minha opinião é que o design orientado a objetos para indicadores simples é uma sobrecarga desnecessária.

Mas estou aberto a discussões e a ouvir seus argumentos 🙂

Olá Mark,

1) Concordo que seu argumento é (principalmente) válido para a base de código do indicador existente. Por outro lado (pelo que me lembro), a base de código do SQX MQL para MT4 e MT5 é, em sua maioria, diferente. Portanto, temos três bases de código - snippet Java do SQX, código do MT4 e código do MT5. Como podemos garantir que tudo isso funcione em todos os casos (incluindo os de borda)? Existe a opção de "validação", mas digamos que não é um uso trivial e, pelo menos no passado, o conjunto de testes para indicadores internos não estava passando completamente.

O teste manual de um especialista gerado e a verificação cruzada com o MT é um esforço muito árduo. E, sim, isso não é possível nem mesmo para MT4 multi tf/símbolos. Multiplique isso por um portfólio grande...

Portanto, isso deixa algumas dúvidas na mesa. A validade ou não pode ser um fator subjetivo, mas os resultados devem ser idênticos na simulação e na negociação real. Uma base de código idêntica tornaria todo o processo mais controlado. Na negociação, você pode confiar, mas precisa validar. Portanto, aqui está meu argumento de que vale a pena unificar a base de código da SQX. É um esforço trivial? Não, mas vale a pena em qualquer aspecto.

2) Sim, estou me referindo à abordagem orientada a objetos. Não se trata de saber se o código em Java ou MQL é mais simples, mas sim do esforço e do custo de dar suporte a ambas as bases de código. E eu não concordaria que é trivial para ambas as plataformas, pois desenvolvo indicadores personalizados. Preciso fornecer evidências para justificar meu argumento?

Enyx

E executei rapidamente o teste de indicadores na última versão 129dev6 - Stochastics, Fibo, Pivots NÃO passam na validação interna do SQ. Isso torna meu argumento mais válido agora?

Enyx

Para completar. A menos que eu esteja errado, há um conjunto de testes fornecido pelo SQ apenas para o MT4. Ou estou enganado?

Enyx

vamos dar uma olhada nas diferenças de teste.

Enyx escreveu:

Para completar. A menos que eu esteja errado, há um conjunto de testes fornecido pelo SQ apenas para o MT4. Ou estou enganado?

o conjunto de testes compara dados, e você pode exportar dados de indicadores também do Tradestation/MultiCharts. Tenho que verificar se temos uma função ou exemplo para isso, sinceramente não sei agora.

Marca,

Vamos ignorar meus gritos por enquanto.

O fornecedor precisa garantir a funcionalidade do indicador integrado para MT4/MT5 e assegurar que os testes de validação sejam concluídos e aprovados em todas as plataformas compatíveis.

E, é claro, o ideal é ter um script oficial (MT é fácil) que gere vários casos de teste em diferentes períodos de tempo e intervalos de parâmetros e, em seguida, instruções fáceis de seguir para fazer a validação cruzada desses casos. Não me interessa se são 20.000 testes a serem executados em uma hora, a menos que seja semiautomático.

Pode haver uma função sqcli para uma autoverificação rápida?

Adendo: os snippets incorporados (e indiretamente os do usuário) já têm definições de metadados (intervalos, tipo etc.). Já pensou em estender isso um pouco e gerar conjuntos de testes automaticamente?

Enyx

Então, como eu tinha um código de exportação do meu indicador personalizado, testei o indicador MT5 SqADX com parâmetros de entrada variáveis usando todos os dados disponíveis no MQ (conjunto de testes de 77 MB).

A taxa de aprovação no teste de sucesso é de 41%. É um problema de arredondamento.

Enyx