Hi,

I'm puzzled by the following behavior: wealth-lab is showing executions on prices that aren't there. I run my strategy on tick data, and the strategy code only contains atMarket orders. In preferences I made sure no slippage and commissions are applied. Attached is a screenshot showing a buy at 1693.30, while the market is at 1691. What can be an explanation for this behavior? Also note that the other buys and sells are slightly off; the dot is not on the data line.

regards,

Mark

I'm almost completely sure that you are calling a SetScale* method and then executing a trade signal. This will not work, and this usually creates those distorted entry/exit points. You can only trade on the chart's base bar scale, and use SetScale/RestoreScale only to build DataSeries in a compressed scale.

Should this not be true, explanation will follow provided that we have the necessary information to reproduce:

1. The original data file (CSV/TXT).
2. Possibly the XML file of the ASCII DataSet.
3. The settings from: Backtest Settings; Slippage and Round Lots
4. The strategy code to run on the piece of data, demonstrating the issue.

Thanks, got your data and Strategy w/o SetScale* methods.

I was wondering why on your screenshot the status line indicates "12/7/2012 2:30 PM" whereas your data loading range starts on Dec 11th. To make sure no option interferes with strategy's execution, try the following:

1. Uncheck everything in "Backtest Settings" and "Slippage and Round Lots"
2. If defined in the Symbol Info Manager, temporarily disable Futures mode
3. Run the strategy in single-symbol mode, i.e. by selecting the "GCA_data" symbol and clicking "Run the Strategy"

You may still notice the distorted entry/exit signs, but it's okay. Consider this:



Looks like a "weird price" but it's definitely not. The moused over piece might suggest there's no 1698.6 price at this point yet it is, at 0:00:03. Here's an extract from the data:

QUOTE:
12/17/2012,0:00:02,1699.8,1
12/17/2012,0:00:03,1698.6,0

The price went down a big point, so the trade is correct. However, Wealth-Lab's popup and status bar do not seem to reflect this accurately. :( Possibly, this is because it does not consider seconds (as you may have noticed). Tick- and second-based data support is there but since we do not position ourselves as a HFT solution, one can't trade a bar scale less than 1 Minute in the Strategy Monitor.

That might be true for your example (it's a bit hard to check), but in my screenshot you see I have set "lines" as charting mode. You can see there is no line from 1691 to 1693.3. I also checked in the data, it's just not there at that time.

Why the simulation starts before 12/11/2012 is also weird; I set that instead of "all data" because the simulations take so long to compute. Now I know why it still takes as long as before!

The problem remained after disabling futures mode.

Any other ideas?

Mark

QUOTE:
Why the simulation starts before 12/11/2012 is also weird;

It's a result of synchronization with the other series (SIA_data) that has significiantly less bars. You shouldn't be applying that pair trading script in multi-symbol mode -- that's not how it was inteded to be executed.

QUOTE:
but in my screenshot you see I have set "lines" as charting mode.

Chart type does not matter. In my case, the chart is wrong too -- the price exists at this point of time in the data but it isn't showing up on the chart.

I think that the backtesting results are correct but there's a sort of inaccuracy on tick-based charts (potentially, with second-based too but am not sure).

At the moment, I can't determine the culprit exactly. Unfortunately, I don't see a short-term resolution for any practical purposes. If it's a bug in the ASCII provider, the respective developer is busy with a high priority project and his queue is full with long-standing bugs and requests. And if it's a Wealth-Lab client issue, then Fidelity will almost certainly prioritize it at the very end of the list since their customers (as well as the absolute majority of ours) are not concerned with Tick/Second data. Sorry.

Thanks Eugene.

Mark