NinjaTrader RC2 Bid and Ask not working

[nettony]

In version RC1 when doing a analysis of an instrument you could use BID and ASK and get results of strategy in development. You could use BID price and ASK price the same as Last Price and get results.

In RC2 even after downloading historical data and checking BID ASK LAST and downloading, try the strategy analyzer does not deliver any results, no matter the logic used simple or complex.

Also back testing results using RC2 compared to RC1 using limit orders delivers radical percentage differences, the question is why ????

Market order results between RC1 and RC2 do show up about the same, but when you do limit orders the percentages are way off, what changed ?

[NinjaTrader_Jesse]

Hello,

Thank you for the post.

Out of context I would be unsure what may be causing the differences. You noted that no matter how simple the script you are still able to see this, could you provide the simple test script you had used to see the difference? I could test that script between versions with the configuration you had used to see if I get the same result.

Based on that test we can look at the syntax used and what may have changed between versions.

I look forward to being of further assistance.

[nettony]

here is the simple script run it in RC1 and RC2 Strategy Analyzer

#Run it HeiKen Ashi 5 Minutes from begging of year 2016 to Oct 14 2016 Big difference in #percentages RC2 comes up with a negative value RC1 comes up with are positive value.

#region Using declarations
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Input;
using System.Windows.Media;
using System.Xml.Serialization;
using NinjaTrader.Cbi;
using NinjaTrader.Gui;
using NinjaTrader.Gui.Chart;
using NinjaTrader.Gui.SuperDom;
using NinjaTrader.Gui.Tools;
using NinjaTrader.Data;
using NinjaTrader.NinjaScript;
using NinjaTrader.Core.FloatingPoint;
using NinjaTrader.NinjaScript.Indicators;
using NinjaTrader.NinjaScript.DrawingTools;
#endregion

//This namespace holds Strategies in this folder and is required. Do not change it.
namespace NinjaTrader.NinjaScript.Strategies
{
public class TestAskBid : Strategy
{
private MACD MACD1;

protected override void OnStateChange()
{
if (State == State.SetDefaults)
{
Description = @"Test Bid and Ask from RC1 to RC2";
Name = "TestAskBid";
Calculate = Calculate.OnBarClose;
EntriesPerDirection = 1;
EntryHandling = EntryHandling.AllEntries;
IsExitOnSessionCloseStrategy = true;
ExitOnSessionCloseSeconds = 30;
IsFillLimitOnTouch = false;
MaximumBarsLookBack = MaximumBarsLookBack.TwoHundredFiftySix;
OrderFillResolution = OrderFillResolution.Standard;
Slippage = 0;
StartBehavior = StartBehavior.WaitUntilFlat;
TimeInForce = TimeInForce.Gtc;
TraceOrders = false;
RealtimeErrorHandling = RealtimeErrorHandling.StopCancelClose;
StopTargetHandling = StopTargetHandling.PerEntryExecution;
BarsRequiredToTrade = 20;
// Disable this property for performance gains in Strategy Analyzer optimizations
// See the Help Guide for additional information
IsInstantiatedOnEachOptimizationIteration = true;
Profiter = 6;
Stopper = 12;
}
else if (State == State.Configure)
{
MACD1 = MACD(12, 24, 9);
MACD1.Plots[0].Brush = Brushes.DarkGreen;
MACD1.Plots[1].Brush = Brushes.Crimson;
MACD1.Plots[2].Brush = Brushes.DodgerBlue;
AddChartIndicator(MACD1);
SetProfitTarget("", CalculationMode.Ticks, Profiter);
SetStopLoss(CalculationMode.Ticks, Stopper);
}
}

protected override void OnBarUpdate()
{
if (CurrentBars[0] < 1)
return;

// Set 1
if (CrossAbove(MACD1.Avg, MACD1, 1))
{
EnterShortLimit(2,GetCurrentAsk(), "alllogicDown");

}
// Set 2
if (CrossBelow(MACD1.Avg, MACD1, 1))
{
EnterLongLimit(2,GetCurrentBid(), "alllogicUp");
}

}

#region Properties
[NinjaScriptProperty]
[Range(1, int.MaxValue)]
[Display(ResourceType = typeof(Custom.Resource), Name="Profiter", Description="Profit Target", Order=1, GroupName="NinjaScriptStrategyParameters")]
public int Profiter
{ get; set; }

[NinjaScriptProperty]
[Range(1, int.MaxValue)]
[Display(ResourceType = typeof(Custom.Resource), Name="Stopper", Description="Stop Target", Order=2, GroupName="NinjaScriptStrategyParameters")]
public int Stopper
{ get; set; }
#endregion

}
}

[nettony]

Major Difference using default analysis setting and same code

Driving blind all logic created all year and performing well upto RC1 just to took a major Dive for the worse, how can we have confidence in old code written when RC2 delivers such way off percentages, its like driving blind moving forward, logic that has been consistent through out all beta versions now comes up total off. Both RC1 and RC2 perform on last price, but the same code returns way off percentages

No matter what code you put limit order perform and calculate differently, Market Order perform the same.

RC1 Price Based On Bid and Ask show results. but in RC2 you only get results when setting Price Based On to Last.

Major problem when try to use Limit Orders base on GetCurrentAsk() GetCurrentBid()
We are Driving blind with old logic complied and working all year and now bombs out in backtesting.


.

[nettony]

Images of results rc1 to rc2

Attached are results for rc1 and rc2 strategy analyzer.
You can see the results are dramatically different.

As a add-on provider who depends on the analyzer to fine tune software current logic are back testing way off the market, even when using a basic limit order results are not giving confidence.

What has changed in the analyzer that gives such wide range of result deference.

Also using bid price or ask price offers no results in rc2 analyzer only last price works. Even after loading historical data with tick and last bid and ask checked. Even after delete the entire database and starting clean.

Please advice regards.

[NinjaTrader_Brett]

Nettony,

We had this release note item for RC2 located here: http://ninjatrader.com/support/helpG...s/8_0_0_14.htm

Changed
10447
Strategy
Updated Fill Engine to fill limit orders clamped to the high/low of the bar on gap up/down bars

Your likely seeing the difference in filled limit order price due to this change, we found that on gap up / down bars a limit order could be filled at a price that the market never traded. Therefore we updated the fill logic so that limit orders, like all other type of orders would be restricted to filling on actual price action seen. This is so we have consistent results based on underlying price data.

[nettony]

Clamped Down on High Lows

RC2 Limit Orders is performing way off compared to RC1, has shown with the simple script.

Meaning that all complex scripts of providers like me, who all year have been creating addons and fine tuning logic and have been getting consistent percentage till RC2, are thrown back to the stone-age. Through out the entire Beta Process the Analyzer has not thrown such way off percentage. What do now believe the numbers we got from RC1 and past versions or do we believe the new math of RC2.

I defy you to send me a limit order simple script that delivers the same percentage off by say 5% from RC1 to RC2, but I guarantee you the any logic written from RC1 to the last 4 version past will perform all within the same range.

We need some sort of assurance the current math for limit orders is better then the past, and "proof is in the pudding" show me one limit order script that will perform withing 5% of the past versions. If you can not then we have serious problem.

Back testing is one of the most important parts of any strategy, been programming for NinjaTrader for over 4 years and this is the first time I see a major issue with the Analyzer.

As for why the clamp algorithm was put in place which cause this destructive mathematical problem. Let me put it this way in math terms, there is tops 2 gaps per week if we are lucky, and in some market there are one gap per two weeks or per month.
clamping to high/low and not using Bid and ASK was a big math mistake.

You killed 98% of all the limit orders which are not gaps !!
If we download the BID ASK and the LAST, and if the analyzer has in the Price settings the settings to choose then they should be adhered to in exactitude, Limit orders are very important to study and do make the difference...

I hope you review the this clamping we are driving blind...

[DaveE]

Hello nettony,
I think the real problem here is that your script uses GetCurrentAsk() and GetCurrentBid() which in my view do not work accurately in Historical mode.

I am in full support of Brett: if NT have fixed strategy analyzer so it does not try to fill limit orders at prices that were not traded on that bar. NT should definitely NOT roll back this change. We want our back-tests to give as realistic results as possible, not historical illusions of profits.

Here's an example of the problem:
When your script does this (in Historic backtest)

EnterLongLimit(2,GetCurrentBid(), "alllogicUp");

You might assume that you are setting the limit price as the Bid at Open of the bar-being-built. But in fact you are getting the Close price of the so called 'current' bar (which might be way out of date eg if using Day TF). The documentation currently says

When accessed during State.Historical, the Close price of the evaluated bar is substituted

That means Close[0]. Call this lastClose.
Now if during the session break the market makers decides like your script that the price was going up then you will find the bar-being built has Open much higher than lastClose, and this new bar may never close the gap (so its Low never goes down to lastClose).
So RC2 correcly never fills this order, since it would not have been filled in realtime.
If RC1 was filling that order that was just causing an illusion of profit in Historical mode.

In my opinion what needs to change now is for GetCurrentBid() & GetCurrentAsk() to be fixed, so that during during State.Historical, it uses the best information it has about the Open of the bar-being-built rather than Close[0]. This request probably needs to go on a new thread, do you want to raise it or shall I?

[NinjaTrader_Brett]

Nettony,

Thanks for sharing your experience and apologies about the beta pains. We're happy with the change in RC2 from a consistency standpoint since now all order types including limit orders placed in a backtest will predictably fill based on historical price data (inside a bar). Limit orders prior to RC2 were not consistent here which resulted in a bug report which we resolved.

With that being said, I'm fully aware that this actually is a debatable topic and not everyone will want the same behavior from the fill engine. Which means that as a feature we should look at exposing options which could help customize the fills to your preferred style. This is an item I have on our list to review in the future and I will add this as a vote. That is tracked in SFT-1137 and also has your input on using Bid/Ask for fills.

-Brett

[nettony]

clamping on High/Low is also an illusion

I will start a new thread for fixing the analyzer for more Realistic Limit Order Performance in future release, which I hope it the next because back testing is very important and has been one of the best cornerstone features of Ninja.

Getting back to the current issue, if the logic was changed to clamping to the High/Low this means in candle stick math it would grab the WICK ends all the time. If using / getting the Close[0] this would mean it is no difference than market orders.

If getting the wick ends this would give an edge that currently is not what we want in a limit order, we want the current price with the nearest bid ask price to enter which normally is the price around the opening of the bar, Meaning Open[0] would be better to use then Close in this case.

This clamping is also an illusion of a greater performance that actually in reality it would not be Low/High Bias or WICKS in Candlesticks are short lived.

I think if this for now what will have to take place is that I will have to add 1/2 point to a point to get more realistic value to the Low and High,
EnterLongLimit(2,GetCurrentBid()+1, "alllogicUp"); and EnterShortLimit(2,GetCurrentBid()-1, "alllogicDown"); to get a better aspect.

In any event what what just happen is that all previous limit order historical results are thrown out the window, we need to find a mathematical patch in the mean time.
Open[0]+1 Close[0] -2 something to help in the mean time.

[NinjaTrader_Brett]

Thanks, no need to start a new thread unless you wanted to do so for discussion purposes since I already tracked your feedback.

On high/low of the bar, limit orders are still very much different then market orders in their behavior. The RC2 change would not have changed that. Also, clamping to high/low is the wrong way to think about the change since its actually the open price that matters. Meaning the scenario that the change addresses is as follows:

* Limit order at price of 100.
* Close of current bar is 50
* There is a huge gap and the open of the next bar is 150.

The question is: Where to fill the limit order that was in the market. Do you fill it at the limit price of 100 or do you fill it at the open price of the next bar which is 150. There is no right or wrong answer. In which case we default to the 150 fill price in RC2 since this is historical data driven and will give reproducible results.

-Brett