Comportamiento interno de las barras en NT8

[polxx]

En la ayuda de NinjaTrader podemos ver esto:

http://ninjatrader.com/support/helpGuid ... _fill_.htm

Que viene a decirnos que cada vez que se trata un sistema en backtest, optimización y todo eso, al no saber el comportamiento del interior de las barras, las descompone en 3 barras usando esas reglas.

Pienso que esta mal planteado, ya que lo mas probable seria:
Si una barra es alcista (cierre>apertura) entonces se puede dividir en 3:
1º baja desde apertura hasta minimo
2º sube del minimo al maximo
3º baja del maximo al cierre
Y para barras bajistas lo contrario.
No es que siempre suceda asi, pero si seria lo mas probable.
Si mirais las normas de ninjatrader son mas improbables.

Todo esto me viene a raiz de otro problema diferente, y es que si aparece un gap en el precio y tienes puesta una orden limitada, NT8 la lanza en el máximo para las compras o mínimo para las ventas, cuando deberia lanzarse en apertura. Ejemplo, pongo compra limitada a 6000 puntos, y estamos a 6010, en la siguiente barra (supongamos un gap nocturno) abre a 5900, todo broker directamente lanza la operacion a mercado, con lo cual un analisis backtest deberia colocarme la orden al precio de apertura, pero NT8 lo coloca en el maximo erroneamente.

Ambas cosas van en este hilo que tengo pendiente con ellos
http://ninjatrader.com/support/forum/sh ... p?t=103239

[Guille]

Hola polxx,
Quizás el fallo lo tengas al considerar la vela donde haces los cálculos del gap.
Si calculas el gap como Open de la vela actual - Cierre de la anterior, las ordenes las lanzará una barra después de la barra donde estás haciendo los cálculos.
Quizás este problema lo suluciones realizando los cálculos en la una barra pero refiriéndote al Open de la siguiente barra para el cáculo del gap. De esta manera, aunque te refieras al open de la siguiente barra, los cálculos los realiza en la barra actual y por tanto la órdenes las enviará justamente en la siguiente barra.
Saludos

[cls]

Hola Polxx, algo no tendrás bien diseñado en el código.
En este ejemplo que pongo se ve cómo la orden se ejecuta en la apertura.
Abre un chart del FDAX 09-17 en 60-min de los últimos 5 días. Hay un gap en la apertura del 22 de agosto.

El código lanza una orden limitada de venta a las 22:00:00 del 21 de agosto en el 12.120, que se ejecuta correctamente
en la apertura del día siguiente.

Saludos

[polxx]

Hola CLS, en ese ejemplo concreto cambia el 12120 por 12080 y dime que ves despues.

[cls]

Cuando cargues la estrategia en Order Fill Resolution pon High, y elige el timeframe de 1-tick para el filled, y te sale bien, justo en el Open.

[polxx]

Ok entonces aun lo veo peor. De partida al indicar Order Fill Resolution = Standard debería calcularlo bien ya que es algo básico.
Si me pide datos de 1 tick para no cometer errores, entonces el calculo se ralentiza mucho. De calcular barras de 60 minutos a 1 tick puede suponer una optimización de 1 minuto a 5 horas por decir algo.
Y lo peor de todo, no tengo acceso a base de datos de 10 años en 1 tick para futuros en continuo. A no ser que con un proveedor de pago descargue por separado 4 vencimientos de cada año (40 descargas) y después haga un merge para formar el continuo. Entonces si tengo que hacer eso para 10 futuros diferentes son 400 descargas, 10 merge, ralentización en los cálculos exagerada.

[Guille]

Cuando cargues la estrategia en Order Fill Resolution pon High, y elige el timeframe de 1-tick para el filled, y te sale bien, justo en el Open.

Creo que no exactamente...de esta forma la orden se ejecuta un tick después del open.
Es por la razón que puse en mi anterior post
Saludos

[polxx]

Hola Guille, no entendí tu post. En NT8 no puedes hacer referencia a una barra posterior, en casi ninguna plataforma se puede, la única es Visual Chart. Por otro lado yo no calculo ningún gap, solamente lanzo una orden de compra limitada, el precio contiene un gap, y NT8 al encontrarse con una situación poco común calcula mal.
Si me haces el favor explícamelo mejor.

[Guille]

Pensaba que estabas detectando gaps.
Pues mira a ver si a la hora de hacer back test, en algún sitio de la plataforma tiene que tener las asunciones que hace para las ódenes limite.
Como operando en live, puede ser que las órdenes límite no se ejecuten aunque el precio las toque, puede ser que tengas configurado el backtest configurado para que las ejecute a peor precio.
Normalmente motor de backtest también hace ciertas asunciones para las órdenes igual que hace para las velas y puede ser que sea esto
Saludos

[Guille]

Pero ahora que estoy pensando...las órdenes , en caso de que no se hayan ejecutado...se recalculan en cada barra.
Si una orden limit es lanzada en una barra...pero no llega a ejecutarse...en la siguiente barra se volverá a recalcular y lanzar...pero claro en el caso que pones ... el precio ya estaría por debajo del precio fijado para esa orden límite y ya no valdría poner orden de compra limitada...tendría que ser una orden stop de compra. Doy por hecho que el precio límite que pones lo tienes como variable.
en tu ejemplo...precio a 6010, se cumple las condiciones del código y lanza orden limitada de compra a 6000 ... pero no llega a ejecutarse....entonces cambia de barra....hay un gap y el precio abre a 5900... el código se vuelve a analizar y la varible que tienes para el precio de compra límite habrá cambiado
En todo caso, si fuera fijo y no variable..en esa nueva barra ya no pude ser orden limite de compra pues el precio (5900) está por debajo del precio limite fijo de compra.
A ver si van por ahí los tiros.

[cls]

Cuando cargues la estrategia en Order Fill Resolution pon High, y elige el timeframe de 1-tick para el filled, y te sale bien, justo en el Open.

Creo que no exactamente...de esta forma la orden se ejecuta un tick después del open.
Es por la razón que puse en mi anterior post
Saludos

No creo Guille, se tiene que ejecutar con el primer tick de la nueva barra. Es como si en NT7 tuvieras una estrategia multi-timeframe donde el segundo timeframe de 1-tick lo usaras para el filled. Ahora NT8 te automatiza todo el proceso. En NT7 tenías que programarlo a medida.

De todos modos lo mejor para salir de dudas es hacer una prueba. Buscarse un día con gap y que los dos primeros ticks tuvieran diferente precio y lanzar la estrategia para ver a qué precio es el filled.

Saludos

[cls]

Ok entonces aun lo veo peor. De partida al indicar Order Fill Resolution = Standard debería calcularlo bien ya que es algo básico.
Si me pide datos de 1 tick para no cometer errores, entonces el calculo se ralentiza mucho. De calcular barras de 60 minutos a 1 tick puede suponer una optimización de 1 minuto a 5 horas por decir algo.
Y lo peor de todo, no tengo acceso a base de datos de 10 años en 1 tick para futuros en continuo. A no ser que con un proveedor de pago descargue por separado 4 vencimientos de cada año (40 descargas) y después haga un merge para formar el continuo. Entonces si tengo que hacer eso para 10 futuros diferentes son 400 descargas, 10 merge, ralentización en los cálculos exagerada.

Sí, funciona mal, ya que si el precio de la limitada cae dentro de la nueva barra de apertura, el filled es correcto, pero si el precio está en el gap lo hace erróneamente en el Low. Salvo que cambies la resolución de Standard a High, lo que a priori no tiene sentido para calcular bien este filled.

A las malas, puedes subir la resolución de 1-tick a 1-minuto, que ya sí tendrás histórico y el performance no debería resentirse mucho (aunque ya los filleds no serán los reales, pero al menos sí mejores que coger sin más el High o el Low).

Por cierto, en modo Unmanaged funciona igual, o sea, mal.

A ver qué te dicen los de soporte de ninja. Has probado si en NT7 funciona así también ?

Saludos

[polxx]

Me han respondido:
This breaks down to the fact we are basing fills on the bars objects and on the close of those objects. As the historical fill processing is looking bar to bar rather than tick-by-tick it would make sense that a Buy Limit order may see the fill below the price it was submitted.

There is no means around this, but I would recommend testing this same item in the Playback Connection: http://ninjatrader.com/support/helpG...connection.htm

Please let me know if you have any questions.

Es decir:
Este gap bajista lo basamos en objetos de barras y en el cierre de estos objetos. Como el proceso de calculo va buscando barra tras barra en lugar de tick a tick, entonces tiene mas sentido que una compra limitada pueda tocar el precio mas bajo encontrado.

No hay forma de solucionarlo, pero recomendamos testear con playback connection


Osea, que aun no entienden que tienen un error. He probado en NT7 y tambien esta el fallo.

[polxx]

Una pregunta sencilla que lanzo por aqui.

¿Con NT8 se puede hacer referencia a la siguiente barra hacia la derecha?

Creo que eso solo es posible con visual chart. En caso de que se pueda hacer, este fallo de las limitadas+gap se puede arreglar, aunque sea de forma chapucera, viendo si en la siguiente barra aparece un gap.

[cls]

Una pregunta sencilla que lanzo por aqui.

¿Con NT8 se puede hacer referencia a la siguiente barra hacia la derecha?

Creo que eso solo es posible con visual chart. En caso de que se pueda hacer, este fallo de las limitadas+gap se puede arreglar, aunque sea de forma chapucera, viendo si en la siguiente barra aparece un gap.

En NT7 se puede hacer programando tu propio código para el filled de las órdenes. Con un Custom Fill Algorithm.
En NT8 han quitado esta funcionalidad. He puesto un ticket en soporte para ver si la incluyen en próximas releases.

En NT puedes acceder a cualquier barra cargada, desde cualquier otra. Pero se sale un poco de la programación estándar.

Una vez ejecutado el State.DataLoaded en el OnStateChange ya tienes en tu ninjascript todas las series de barras en memoria. Cada serie de barras es un objeto de tipo Bars. Si no estás en multitimeframe sólo habrá un objeto Bars. Puedes acceder a los datos de las barras desde el objeto Bars o bien BarsArray[n] si estás en multitimeframe.

Con el código siguiente se imprimen los valores de todas las barras en el State.DataLoaded, es decir, antes del primer OnBarUpdate, lo que demuestra que los datos ya pueden utilizarse en histórico antes de haber procesado el OnBarUpdate de la primera barra.

Código: Seleccionar todo

protected override void OnStateChange()
{

// ...

else if (State == State.DataLoaded )
{
  for (Int32 n = 0; n < Bars.Count; n++)
  {
    String str = String.Format("#{0}   O={1}   H={2}   L={3}   C={4}   V={5}   T={6}  {7}", 
    n, Bars.GetOpen(n), Bars.GetHigh(n), Bars.GetLow(n), Bars.GetClose(n), Bars.GetVolume(n), 
    Bars.GetTime(n).ToShortDateString(), Bars.GetTime(n).ToLongTimeString());
    
    Print(str);
  }
}

Para acceder a los valores característicos de las barras se usan métodos Get del objeto Bars y como índice el propio de cada barra y que refleja el valor de su CurrentBar, donde el 0 es el más antiguo y el último es Count-1. Es al revés que en la notación de NinjaScript donde [0] representa la barra actual o CurrentBar.

El código siguiente te detecta si la próxima barra abrirá con un gap de más de 10 ticks:

Código: Seleccionar todo

protected override void OnBarUpdate()
{
  if ( Math.Abs( Instrument.MasterInstrument.RoundToTickSize( ( Bars.GetOpen(CurrentBar + 1) - Bars.GetClose(CurrentBar)) / TickSize ) ) > 10 )
  {
    Print("Gap en barra " + CurrentBar);
  }

S2