Reconciling signals in back-testing Point Figure/Regular.

Questions about MultiCharts and user contributed studies.
continue8
Posts: 13
Joined: 12 Feb 2014
Has thanked: 2 times

Reconciling signals in back-testing Point Figure/Regular.

Postby continue8 » 19 Feb 2014

Hi,
My question is probably a bit general but I will
try to be as specific as possible:

If someone were to create a strategy using Point & Figure formatted data to
use as the input for the signals, what we be the best way in Multicharts to
ensure that the signals can be replicated in the live environment?

On the top line of code in at the top of the signal "[IntrabarOrderGeneration = false] " has been inserted to hopefully this will avoid any changes to the signalat the end of the bar.

In addition the chart has been seperated by data1 = Regular 10min data2= PoinFigure 10 minute resolution. Or variations of that 5min regular/ 20 min PointFigure.

If the signal is generated from the data in data2 ( PF ) how can someone be
absolutely sure that the simulation results be reproduced live - assuming that
live testing is not yet possible ?

Personally I have not been able to reconcile the signals and trades with the signal logic
or in other words the signals seem to occur or observe rules that do not match the
parameters or conditions of the signals which have been pointed to data2, but when
I recreate the indicator ( moving average for example _) using data2 data and plot it then the
it seem to prove that the signals is not valid , so there's something else going on here.

All of the order execution is at the end of the regular bars ( data1) for the next regular bar
( open of next bar ) .
This is the buy order :
if condition1 and condition2 and condition3 and condition4 and mp =0 then
Buy quantity shares next bar at market;
( While quantity =1 and 1 in this case is 100000 USD of JPY) .
Any advice about how I can accurately reconcile signals from data2 when they are point & figure charts and while data1 is a regular bar ?

Thanks.- Continue8

continue8
Posts: 13
Joined: 12 Feb 2014
Has thanked: 2 times

Re: Reconciling signals in back-testing Point Figure/Regular

Postby continue8 » 19 Feb 2014

To give another example of the apparent mis-match, I have spotted
a "sell " signal for example on the open of the 14:55 pm bar on (data1 REGULAR 5 MIN bar).

But the conditions that create the sell signal can only be generated from data2
which is a 20 min resolution Point & Figure chart - but the data2 PF chart does not
close until 15:20 pm. How can a 14:55 pm 5 min bar get a sell signal from a bar that closes
in 25 minutes time ( after 14:55 at 15:20 pm ? ) .
Actually now that I have recharted the same scenario 20 minutes later the signal that was on the "old chart" that I have kept open - but doing a new chart now shows the sell signal on the open of the 15:30 pm which is still out because I would have expected a sell at 15:25 if data2
ends at 15:20, but the signal has shifted from 14:55 to 15:30 pm .
From what I can see is that in real-time the signals are being created before the times illustrated in the backtests, which means that the backtest is probably wrong.
Obviously my objective is to create an accurate backtest so it's difficult to continue working on this until I can be sure that the results can be replicated in real-time.

-Thanks,

User avatar
MAtricks
Posts: 789
Joined: 09 Apr 2012
Has thanked: 286 times
Been thanked: 288 times

Re: Reconciling signals in back-testing Point Figure/Regular

Postby MAtricks » 19 Feb 2014

You can build signals on these blocks just fine, but you MUST completely understand how the blocks are built.

Everything must be done with floating orders since the open and close of these blocks are ridiculously wrong. These floating orders must be calculated to be placed directly on a block size and outside of the turn around point.

If that doesn't make sense, read the description of how these blocks are built.. and then read it again.

I've suggested many things that will make these blocks easily back-testable.. sadly that is not priority. As it is now, they make a pretty historical chart.

continue8
Posts: 13
Joined: 12 Feb 2014
Has thanked: 2 times

Re: Reconciling signals in back-testing Point Figure/Regular

Postby continue8 » 19 Feb 2014

What would you describe as a floating order ? A stop order ? A limit ?

User avatar
MAtricks
Posts: 789
Joined: 09 Apr 2012
Has thanked: 286 times
Been thanked: 288 times

Re: Reconciling signals in back-testing Point Figure/Regular

Postby MAtricks » 20 Feb 2014

Yes.

continue8
Posts: 13
Joined: 12 Feb 2014
Has thanked: 2 times

Re: Reconciling signals in back-testing Point Figure/Regular

Postby continue8 » 20 Feb 2014

I have successfully created new order types and overlayed the data1/2 so that
the signals can be almost entirely reconciled now so this is great and
I found some info on the wiki page :

https://www.multicharts.com/trading-sof ... and_Figure

However there is still a little question about the "building", you mentioned reading it
and reading it again but one point is still not entirely clear...

The fundamental concept seems to be that new bars /no bars or stacks of "x"'s and
"o"'s irrelevant of time, this is great and relatively easy to understand but when
you plot it in MC their seems to be a third dimension - this time " resolution " and
the input / close or HIGH/LOW range.
The resolution seems to create a time window for an UP/DOWN stack to occur
and if there is no reversal that fits the criteria then this time resolution actually
can and very often come up blank - the time resolution window actually shows neither
an X or O stack because there was not enough movement to constitute a stack.

How does the PF logic then fit in with these resolutions ? It just ignores anything in between and comes up blank when the situation merits? Or am I really still off the track here.

User avatar
MAtricks
Posts: 789
Joined: 09 Apr 2012
Has thanked: 286 times
Been thanked: 288 times

Re: Reconciling signals in back-testing Point Figure/Regular

Postby MAtricks » 20 Feb 2014

Do not use a time input on any unique bar types. For backtesting everything should be set to a 1 tick resolution.


Return to “MultiCharts”