|
PureBytes Links
Trading Reference Links
|
> > > 1) Take any system that exits at the end of day so that P/L for a
> > > given day is not affected by overnight trades. Go back say, one day.
> > > Go to View->performance Report->daily Tab. Note the P/L. Now, go and
> > > bring up the symbol again. Change number of days to look back to 2.
> > > Go back and look at the daily report. Look at the P/L for the day
> > > that you looked at - they are different.
> >
> > I don't understand what you mean by "go back one day, go back two
> > days."
>
> Look at what I wrote. Write a system where that EXITS at the close
> of the day and takes no positions overnight. It is IMPOSSIBLE for a
> system that takes all of it's signals for a given day from within
> that day, to have a different P/L based on what days are loaded or
> not.
Not impossible at all. I could very easily build a system that
did. E.g. if the entry is based on an xaverage that hasn't
settled, the results would change even if you are exiting at the
close.
It sounds to me like you may be using multiple signals/stops per
bar. If so, that could cause some of your problems e.g. the
different results when you stop & restart. Do you use multiple
stops per bar, e.g. a profit target AND a stop loss in the same
bar? If so, TS CAN'T know which one was hit first (unless you
run your system with higher "strategy testing resolution" turned
on, format system -> Properties tab -> Backtesting settings), and
that could cause some of your problems. But that's not TS's
fault. If it only has the OHLC to work with, there is no way for
it to know which stop gets hit first.
If you want to show us some code that demonstrates your error,
I'd like to see it. Otherwise we're likely to just degrade into
an argument here ("no it doesn't!" "yes it does!!").
> The problem is, a real programming environment would have a
> debugger, and the programmer would be able to go in, roll up his
> sleeves, signle step through the cod, and figure out what was
> happening when the unexpected happens.
Agree 100%. They should have a debugger. On the other hand, for
many (NOT all) of the debugging challenges I run into, I find
that plotting and printing values actually helps me find the
problem quicker than a debugger would. I can see the results
over many bars at once instead of one line of code at a time.
Gary
|