|
PureBytes Links
Trading Reference Links
|
----- Original Message -----
From: "Gary Fritz" <fritz@xxxxxxxx>
To: <omega-list@xxxxxxxxxx>
Sent: Saturday, February 28, 2004 3:19 PM
Subject: Re: QuantStudio
> > > > 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.
Well, I think this is what it is going to come down to. I will see if I can
duplicate this anomalie without actually giving out any of my proprietary
code. Let me see what I can dig up.
> 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.
I use the "Use Tick" resolution. However, I am aware of the boucig tick
problem.
> 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!!").
I agree. Let me see if I can reproduce some of the issues that I submitted
by actually submitting code.
> > 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.
TS would be 100 times the product if it had a real debugger.
Ivan
> Gary
>
|