Hello,

I would like to buy the open and sell the close every day (effectively get rid of overnight gaps). When I coded it using the wizard and ran it on the SPY, I ended up buying every other day instead of every day. Is there a quick way to get it to buy each day? Thanks!

CODE:
Please log in to see this code.

Thank you kind sir.

you may be very interested in this link:
http://www.bloomberg.com/apps/news?pid=20601213&sid=aXhs9g9il2rk

a friend of mine pointed this out to me a few years ago. basically, the entire return of the market happens overnight (on average) and a strategy of Buying the Close every day and Shorting the Open is highly profitable when applied to the major indices. Of course it also has massive drawdown periods and very high commission costs.

ss, how does that Strategy do over the past 16 months?

Check out Holding Overnight Cubes. It too was a good strategy in 2004, when it was published in TASC magazine. Alas, that was the peak for that one.

Here are the results on SPY since 1994. I think, although I haven't taken the time to prove it, that the Buy and Hold results are overstated as i had to trick wealth-lab into allowing all the trades by setting Margin to 2.1:1 -- i think that overstates the buy and hold results. I shouldn't have needed to do that since this "system" never holds two trades at a time -- it buys the close, sells the open, shorts the open, covers at the close, etc. But i think (unless of course i made a mistake somewhere) that Wealth-Lab was dropping half the trades until I set the margin higher. It doesn't impact the results of the strategy test, just the comparison to Buy and Hold.

Finally, I don't advocate this as a strategy at all, but i do think it says something very interesting about how information comes into the market and about some of the fallacies of day trading / exiting positions at the end of the day.

Here are the results:


Performance:


and finally, the very complicated code:

CODE:
Please log in to see this code.

Here it is for the Qs:

You're using 100% equity sizing. Of course it's going to drop trades for the reasons we talk about all the time (and in the User Guide).

Well, anyway, the strategy looks flat to down for the last 3 years, but it's certainly much better than having been fully invested!

----
But you assumed $0 commissions. Bad assumption. Those results are then VERY inflated.

I have seen a few quant bloggers point this out already: a longer term bias that holding overnight can be profitable. As Cone mentioned, you will be eaten alive by transaction costs, unless you use leveraged vehicles like futures or options, however that extra leverage comes with a higher risk of busting your account.

It can also be noted that the largest spikes upward occur on downtrends and sharper moves downward occur on uptrends. This reinforces the concept of mean reversion in the market.

So, maybe your next assignment with these results is to formulate a strategy around the 'quants'.
You can use this information to make a probabilistic betting system, that adapts to the recent changes in the equity curve.
Or take an existing system that gets murdered by holding overnight, and use this data to limit or increase your exposure.

Regards,
--Mike

Mike and Cone, I absolutely agree. This is not offered as a trading system, instead it's simply an observation of the price action in the market backed up by some data. And, it was meant to point out, how the "opposite" strategy of buying the open, may not give the best results (this last statement being understated).

Mike, also,

QUOTE:
a longer term bias that holding overnight can be profitable.

Yes, but also, being short during the day (the dark red line), is profitable as well.

Cone, I used 0 commissions and 100% equity sizing because I'm trying to compare the results to the market return, not to offer a tradeable system. Clearly there are other ways of comparing to the market, wealth-lab just provided a convenient way of "doing the math". Unfortunately, the 100% equity sizing doesn't work. As you pointed out, for all the right reasons when trying to develop real trading systems that have to decide how many shares to trade before giving the order. I adapted the entry functions as the UserGuide suggested using BuyAtMarket2 / ShortAtMarket2 and it still drops trades. In fact, I even adapted the sample code provided in the UserGuide and the sample code drops trades. If I have time later today, I'll redo the analysis using excel, where 10% equity sizing can easily be achieved.

Here is the "adapted" UserGuide code that still drops trades. I think the issue is in systems that "stop and reverse" on the same bar -- as the above test needs to do, and as my adapted code below tries to do.

CODE:
Please log in to see this code.

I can't explain those skipped trades with that code, so I'm going to look into it.

I think I see what's happening here, but still investigating. For now, we'll have to remove/ignore that verbage about the "2-signal" workaround for 100% sizing in Version 5.

- ss161 would you please open a ticket with just a link to this thread? tia

Thanks for the earlier posts on the subject of how to write backtest
programs to characterize the price action of a Market. I would like
to get a better understanding for different ETF's the results of holding
positions just during the day (Buy Open and Sell Close) versus a
Buy and Hold strategy holding a position overnight. However, I have
encountered a problem with the backtesting which I would like to describe
and get feedback on. First here is the program I am using

CODE:
Please log in to see this code.

Since I am just trying to characterizing ETF Price action and not
designing a trading system I set the following settings in Preferences
No Commmissions Applied
No Activation of Slippage
No Selection of Round Lots
I also used the Backtest Raw Profit Mode with a Fixed Dollar amount
of $100,000. The objective was to compare the performance of the
ETF's SPY (1X S&P500) versus SSO (2X leverage of S&P500). The Data
Range I selected was 12/31/08 to 5/1/09. When running the program
I was very surprised to see that the first trade on 1/2/09 for
both ETF's was for an amount greater than $100,000.
SPY trade on 1/2/09 Open was 1108 Shares at 90.44 = $100,207
SSO trade on 1/2/09 Open was 3796 Shares at 26.56 = $100,821
The fact that the total amount invested for each ETF was so different
($100,821 - $100,207 = $614) also reduces the accuracy of comparison testing.
I was expecting a first entry purchase of the following ammounts
SPY expected position size = $100,000/90.44 = 1105 shares (Total = $99,936)
SSO expected position size = $100,000/26.56 = 3765 shares (Total = $99,998)
This leads to my main question. Is there a way via either code or Preference
settings to run a Backtest where the number of shares purchased is the maximum
that can be purchased without exceeding the available cash?
I tried working around this problem using the Portfolio Simulated Mode
using $100,000 of Capital and selecting a Percent of Equity = 50% to avoid
missing trades. However, the number of shares on the first trade exceeded
$50,000 and again the total dollar amounts differed significantly for the ETF's.

For AtMarket and AtClose orders, the size is based on the closing price on the bar before the entry bar. (See User Guide)

There won't be a way to do fine control of sizing in Version 5 on a Portfolio level until PosSizers are introduced later this year.

Thanks for the reply. Wondered how the Position Size was being
calculated. Looking forward to the future Version 5 that you
indicated will have Position sizing control.

Don't know if its feasible with Version 5, but my vote would be
for an option that would allow the user to write code to monitor
the Equity Level and if desired other user defined variables and
then set the Position Size on a Buy.

QUOTE:
I also used the Backtest Raw Profit Mode with a Fixed Dollar amount
of $100,000.

i think if you made the position size $1,000,000 or maybe even $10mm you'd still be off by the 600 or so dollars, but on a percentage basis it wouldn't matter nearly as much? i haven't tried this, just a thought.

Thanks for the suggestion, but I also had that thought earlier and tried
using $1,000,000 and it didn't work (ETF difference off by $6000 instead of $600).
As Cone stated, the size (number of shares bought) is based on the closing price
of the bar before the entry bar. The percentage difference between the previous
bar and the entry bar is not affected by the total dollar amount used.

of course, that makes sense.

this may not work either, as i didn't try it, but one other thought is to try Cone's suggestion to me to use "BuyAtMarket2". This is a wrapper function, that instead of calling the real BuyAtMarket, it instead calls BuyAtLimit using the opening price of the bar for which you are trying to BuyAtMarket. I believe in theory the PositionSizer should be able to accurately calculate the number of shares for a LimitOrder, and since you are passing the function the actual market price for which you should be filled anyway, it should calculate the correct number of shares and give you the same fill that you otherwise would have gotten with a market order. For me this didn't work and Cone is working on why, but I was trying to implement a "stop and reverse" type system. It may work for a system that just does one buy per day.

see below (and other posts above):

CODE:
Please log in to see this code.

Thanks. Thats a creative approach. It forces the number shares
purchased to be based on the Open of the entry bar and the Fixed
Dollar amount specified. Until we get position sizing in the next
WL release, this may be the best way to do backtesting when
comparing results for different symbols.

Here is the updated code. Thanks again for the idea.

CODE:
Please log in to see this code.

You shouldn't write code for trading signals to operate on "bar", unless you want to rewrite it later to use for actual trading.

QUOTE:
Until we get position sizing in the next WL release, this may be the best way to do backtesting when comparing results for different symbols.

This statement doesn't make sense to me. You already have several options for Position Sizing, but maybe you meant PosSizers? Even so, why would that "be the best way to do backtesting when comparing results for different symbols"?

The above code is not intended to be a trading signal,
but instead is designed to characterize the performance
(Return, %MDD, PF, etc) of different ETF's from open
to close and compare that with Buy and Hold performance.
When the entry bar price (BuyAtLimit(bar, Open[bar])
is used to calculate the number of shares, then each
symbol tested will be investing close to the same amount
each day assuming the Position Size used is large enough.
That is what makes it the best way (in my opinion) to
compare different symbols.

Going back to the skipped-trades issue from 4/23...

Finally got to the bottom of this. Review: the situation is reversing, for example, a short Position into a long Position AtMarket with 100% sizing using the BuyAtMarket2 idea (with the BuyAtLimit wrapped in the procedure).

Even though we're peeking to the opening price with the BuyAtLimit order to "perfectly size" the Position for 100% sizing, it fails occasionally because that sizing is based on the Equity amount on the close of the signal bar. However, occasionally, the Short Position can cause the account to lose equity when the price gaps higher from the close to the opening price of the next bar. The change in the account equity makes the calculated size too large to successfully put on the new Position.

The same phenomenon existed in V4 as well, it's just that no one ran or noticed this particular case.

Edited:
Knowing this, we can probably design a PosSizer to be used in v5.6 and up that will compensate for the BuyAtMarket2 sizing when exiting a previous Position on the same bar. Let's keep it in mind and we'll work on it later.