Nuevo MQL4 con #propiedad estricta

Buenos días,

Me pregunto acerca de este "MQL4 con #property estricta", que incluyo en el código, pero la compilación es siempre con errores. ¿Puedes explicar cómo se puede arreglar esto? Me refiero a tener un código con esta nueva condición de "#property strict".

Gracias.

Hola,

planeamos añadir soporte para la propiedad estricta para que pueda ofrecer sus estrategias y, posiblemente, cargar en el mercado MQL también. El objetivo para que esto esté disponible es la próxima compilación 129 o la siguiente. Esperamos tenerlo listo en una de estas versiones.

¡Perfecto! ¡Muchas gracias!

Buenas noticias
Excelente, ustedes siempre ofrecen lo nuevo y lo especial. Seguid así y siempre os apoyaremos.

saludos,

Buenas tardes,

Estaba revisando la nueva versión pero veo que la #property estricta sigue pendiente.

Me pregunto si estoy haciendo algo mal o si no está incluido en la nueva versión.

Gracias.

Hola, estoy de acuerdo en que es una solicitud pertinente. No se trata sólo de estricta pero como recuerdo algunos indicadores están utilizando la vieja estructura de codificación MT.

¿Existe una solicitud formal de funciones?

Enyx

Hola,

ahora se está trabajando en la implementación. Usted será capaz de proporcionar la versión especial del código de la estrategia que cumpla con los requisitos en el mercado MQL

¿será también para la licencia PROFI o sólo para la ULTIMATE?

Hola Tomas,

Gracias, señor.

Si tengo que ampliar un poco el tema.

Algunos otros productos de la competencia (como FXB) tiene una estructura de indicadores OOB muy bien definida que hace que la codificación de indicadores sea lógica y fácil. También el código exportado del asesor experto está bien estructurado y es más fácil de depurar. En la actualidad sólo las opciones de comercio son una especie de cerca de este enfoque.

Así es como me imagino la situación:

1) Los indicadores SQX se basan en OOB

2) El código experto SQX se basa en OOB

3) Una plantilla de indicador SQX basada en OOB que sigue la estructura de código Java personalizada de SQ. No olvidemos que un indicador personalizado necesita ser implementado tanto en MQL como en Java. Ya tengo un intento de codificación que estaré encantado de compartir con el equipo de SQ. Los beneficios son numerosos. Fácil intercambio de código entre la implementación de Java y MQL. Misma estructura. Menos codificación, errores y pruebas más fáciles. También permite reutilizar/incluir componentes en ambas plataformas. Para eso sirve OOB..

Código Java:

@Override
protected void OnBarUpdate() throws TradingException {
este.Calls++;

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

int tendencia = 0;

double clow = calcLow.getValue(0);
double chigh = calcHigh.getValue(0);
double cc = Entrada.Cerrar.obtener(0);

if ((cc >= clow) && (cc <= chigh)) {
// En canal
tendencia = 0;
} else {
if (cc < clow) { trend = -1; }
if (cc > chigh) { trend = 1; }
}

// Devuelve el resultado normalizado
Lower.set(0, calcLow.getValue(0,0,true));
Upper.set(0, calcHigh.getValue(0,0,true));
Tendencia.set(0, tendencia);
}
}

Código MQL:

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

int tendencia = 0;

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

if ((cc >= clow) && (cc <= chigh)) {
// En canal
tendencia = 0;
} else {
if (cc < clow) { trend = -1; }
if (cc > chigh) { trend = 1; }
}

Enyx

Enyx, no estoy seguro de seguirte. ¿Qué entiendes por OOB? ¿Orientado a objetos?

Los indicadores SQX en Java están orientados a objetos, ¿te refieres a sus versiones MQL4/5?

Es subjetivo, pero yo diría que la estructura del código Java para los indicadores en SQ es fácil de entender, es más simple que en MQL.

La razón por la que el código MQL de los indicadores personalizados en SQ a veces no está orientado a objetos es simplemente que algunos de ellos no son nuestros - los reimplementamos en Java para SQ, pero MQL es original.

No veo gran punto en la reimplementación de ellos en el diseño orientado a objetos en MQL, mi opinión es que el diseño orientado a objetos para los indicadores simples es la sobrecarga innecesaria.

Pero estoy abierto al debate y a escuchar vuestros argumentos 🙂 .

Hola Mark,

1) Estoy de acuerdo en que su punto es (en su mayoría) válida para la base de código indicador existente. Por otro lado (que yo recuerde) SQX MQL código base para MT4 y MT5 es en su mayoría diferentes. Así que tenemos 3 bases de código - SQX Java snippet, código MT4, código MT5. ¿Cómo nos aseguramos de que todo esto funciona en todos los casos (incluidos los de borde)? Existe la opción de "validación", pero digamos que no es trivial su uso y al menos en el pasado el conjunto de pruebas para los indicadores internos no pasaba completamente.

La prueba manual de un experto generado y la comprobación cruzada con MT es un esfuerzo tan minucioso. Y sí, ni siquiera es posible para MT4 multi tf/symbols. Multiplique esto por una gran cartera...

Así que deja algunas dudas sobre la mesa. Válido o no puede ser un factor subjetivo, pero los resultados deben ser idénticos en la simulación y el comercio real. Un código base idéntico haría que todo el proceso estuviera más controlado. En el comercio se puede confiar, pero hay que validar. Así que aquí está mi punto de que vale la pena unificar la base de código SQX. ¿Es un esfuerzo trivial? No, pero vale la pena en cualquier aspecto.

2) Sí, me refiero al enfoque orientado a objetos. No se trata de si el código Java snipped o MQL es más sencillo, sino del esfuerzo y el coste de soportar ambas bases de código. Y no estoy de acuerdo en que sea trivial para ambas plataformas, ya que desarrollo indicadores personalizados. ¿Necesito aportar pruebas para justificar mi punto de vista?

Enyx

Y he ejecutado rápidamente indicador de pruebas en la última versión 129dev6- Estocásticos, Fibo, Pivotes no pasan propia validación interna de SQ. ¿Hace que mi punto ahora más válida?

Enyx

Para completar. A menos que me equivoque no es SQ proporcionado conjunto de pruebas sólo para MT4. ¿O estoy equivocado?

Enyx

veremos las diferencias de las pruebas.

Enyx escribió:

Para completar. A menos que me equivoque no es SQ proporcionado conjunto de pruebas sólo para MT4. ¿O estoy equivocado?

la suite de pruebas compara datos, y puedes exportar datos de indicadores también desde Tradestation/MultiCharts. Tengo que comprobar si tenemos una función o ejemplo para esto, honestamente no lo sé ahora.

Marca,

Ignoremos mis gritos por el momento.

El proveedor debe garantizar la funcionalidad del indicador integrado para MT4/MT5 y asegurarse de que se completen y superen las pruebas de validación para todas las plataformas compatibles.

Y, por supuesto, lo ideal sería disponer de un script oficial (MT es fácil) que genere un montón de casos de prueba en diferentes marcos temporales y rangos de parámetros y, a continuación, instrucciones fáciles de seguir para validarlos de forma cruzada. No me importa que se ejecuten 20000 pruebas en una hora, a menos que sea de forma semiautomática.

¿Puede haber una función sqcli para una autocomprobación rápida?

Apéndice: Los fragmentos incorporados (e indirectamente los de usuario) ya tienen definiciones de metadatos (rangos, tipo, etc.). ¿Ha pensado alguna vez en ampliar esto un poco y generar automáticamente conjuntos de pruebas?

Enyx

Así que ... Desde que tenía un poco de mi código de exportación indicador personalizado he probado MT5 SqADX indicador con parámetros de entrada variable utilizando todos los datos disponibles en MQ (77MB conjunto de pruebas).

El porcentaje de aprobados en la prueba es de 41%. Es un problema de redondeo.

Enyx