I have coded with non-adjusted series by cheeking for the split date in the code and adjusting commissions by the appropriate factor. Results are more realistic.

@James J., There has been discovered in another thread an issue with dividends and back adjusted splits: dividend calculation looks very wrong.

The correction of this bug, when it occurs is going to have considerable impact on every investment type strategy. Note that I said "investment" type. Investment strategies, I believe, need to consciously and accurately take into account all impacts to historical price (spins, splits, dividends). Investing is long term and multi-security focused.
Trading on the other hand, again -- in my opinion, cares only for the market traded price and volume. Trading, to me, is a less than 2 week exercise in capturing blips in market behavior. And as such should ignore back adjusted prices and focus on OHLCV right here right now. The only way to accomplish this would be to pick a price type from an environment setting. Do you want to use adjusted close prices or market print prices? I see nothing wrong with offering such a capability. Market print prices would have to ignore dividend payments and split adjustments. And this would severely whack many strategies, up an down. But having always had control over which prices I streamed into my strategies I've known and built strategies that dealt with such price shocks (due to splits). Is this close to what you're speaking to above?

I think you're right on the mark there with an environment setting. Or perhaps a different function name, instead of history(), history_raw() or something similar. But in case I think it is powerful to have the option to specify what sort of data you want to work with.

The difference with raw data is there will need to be some way tackling the change in position size that does not relate to placing an order. Without stepping too far out of the current Q framework, this info could come in the same form as the dividend payouts.

In any case, I don't understand why there is not a 10x change in volume with the adjusted data, as shown in the backtest.

Why would there be a change? Presumably the volume is split-adjusted too. Which reminds me, I need to do that also.

It doesn't appear to be adjusted at all:

From Yahoo, on 3rd May 2011 the volume was reported at 43.5 million. Q reports it as 41.4 million.
From Yahoo, on 12th May 2011 the volume was report at 60.7 million. Q reports it as 57.4 million.

EDIT:
My bad, all prices online are volume and price adjusted, including Yahoo (found a database on quandl with non-adjusted data: https://www.quandl.com/data/WIKI/C-Citigroup-Inc-C-Prices-Dividends-Splits-and-Trading-Volume)

James,

So what's the conclusion here? Do commissions on a per share basis get adjusted for splits improperly? Is it a bug?

Grant

Grant,

The commissions are incorrect for any stock before a split occurred. After the split, the commissions are correct.

e.g. for C (Citigroup) on 3 May 2011 , the price was actually $4.52/share.
So for a $10,000 value position, you would need 2212 shares. You would pay 2212*$0.03 = $66.36 commission.

But using Q's back-adjusted price on 3 May 2011, the price is reported as $45.20/share.
For the same $10,000 value position, you would only need to buy 221 shares. So in the backtest you would pay 221*$0.03 = $6.63 commission.

i.e. the commission is out by a factor of the split amount, in this case 10 times out.

Its not a bug so much as a consequence of using back-adjusted prices. If it were possible to access split information for each stock, then it would be possible to calculate commission based on the real price of the stock.

Trying to fathom what should happen to price, cash, share counts, commissions, over time on the impact of Adjusted Close.

Corrected.

The un-adjusted price should drop on ex-dividend dates, yes.

It would seem that there needs to be (or probably already is) a collection of metadata that accompanies every period of every security that must be used to calculate trade impact. If we sell at "C" above, we must be charged for 3 x's the commission. Is this what James is pointing out as an error?

And your bug Simon, is also evident in this chart? If so how? If not, what to add so that this example shows the bug?

Which bug of mine are you referring to? I haven't really been keeping track.

Above reference "Dividend reference looks very wrong" Although I suppose it more Tony's bug than yours.

If I understand the dividend bug, then at point D you would receive 2*3000(shares)*$1 = $6000, due to the bug.

For dividend at point B, I'm not sure, but maybe (2/3)*1000(shares)*$5 = $3333. ?

Oh yeah, I am not sure exactly what the bug is, but something like that.

Thanks James,

That's what I thought. Well, I'd call it a "bug" since the commission charge should be accurate, and based on the number of actual (historically modeled) shares transacted of the stock, based on the dollar amount of the transaction.

I'm not aware of how to write a custom commission model in Quantopian, so even if the time-stamped split information were available, how would one account for it properly?

Grant

Corrected..... take all the split fractions (in MT's example above: start with 1:2, then 3:1, going backwards in time) and then multiple the tops and the bottoms to get a factor= 3/2. So from "adj close" to "real close" for point A is just multiplying by 3/2. Once you have the real price you can work out how many shares you need. The volume needs to be adjusted too, multiply by '1/factor'.

...I think...(for the 2nd time...)