Join the 80,000 other DTN customers who enjoy the fastest, most reliable data available. There is no better value than DTN!

(Move your cursor to this area to pause scrolling)




"There is no doubt that IQFeed is the best data provider. I am very satisfied with your services. And IQFeed is the only one that I would recommend to my friends. Now, most of them are using your product in China." - Comment from Zhezhe
"Boy, probably spent a thousand hours trying to get ******* API to work right. And now two hours to have something running with IQFeed. Hmmm, guess I was pretty stupid to fight rather than switch all this time. And have gotten more customer service from you guys already than total from them… in five years." - Comment from Jim
"IQ feed works very well, does not have all of the normal interruptions I have grown used to on *******" - Comment from Mark
"I just wanted to let u know that your data feed/service is by far the best!!! Your unfiltered tick data is excellent for reading order flow and none of your competitors delivers this quality of data!" - Comment from Peter via Email
"As a past ******* customer(and not a happy one), IQ Feed by DTN is a much better and cheaper product with great customer support. I have had no problems at all since switching over." - Comment from Public Forum
"I just wanted to let you know how fast and easy I found it to integrate IQFeed into our existing Java code using your JNI client. In my experience, such things almost never go so smoothly - great job!" - Comment from Nate
"I've never had DTN go out on me since switching. ******* would go down a couple times every month when I was using them." - Comment from Bryce in AL.
"DTN feed was the only feed that consistently matched Bloomberg feed for BID/ASK data verification work these past years......DTN feed is a must for my supply & demand based trading using Cumulative Delta" - Comment from Public Forum Post
"This is an excellent value, the system is generous (allowing for 500 stocks) and stable (and really is tick-by-tick), and the support is fantastic." - Comment from Shirin via Email
"I started a trial a few weeks back before the market went wild. DTN.IQ didn’t miss anything and beat my other provider. I decided to stay with you because of the great service through all the volatility." - Comment from Mike
Home  Search  Register  Login  Blogs Recent Posts

Information on Various DTN Products:
DTN IQFeed | DTN ProphetX | DTN Ag | NxCore
Follow DTN_IQFeed on Twitter
DTN.IQ/IQFeed on Twitter
DTN News and Analysis on Twitter
»Forums Index »Product Support »POLLS & SURVEYS »Do you want intraday equity (stocks) data to be split adjusted?
Author Topic: Do you want intraday equity (stocks) data to be split adjusted? (16 messages, Page 1 of 1)

Poll:
I DO NOT want intraday history split adjusted:
15 (65%)
I want intraday history to be split adjusted:
8 (35%)

DTN_Jay_Froscheiser
-VP, Product Operations-
Posts: 1739
Joined: May 3, 2004

DTN IQFeed/DTN.IQ/DTN NxCore


Posted: Jun 8, 2010 05:10 PM          Msg. 1 of 16
We are interested in your input regarding whether IQFeed intraday data should be split adjusted. If we do this, it will be all or nothing (once a split is processed, all data will be adjusted and there will be no way to access non-split adjusted data). Split adjusted history will be provided for both tick and minute data.

Please let us know if you would like IQFeed historical intraday data to be split adjusted or not.

Thanks!

Jay Froscheiser
DTN

taa_dtn
-DTN Evangelist-
Posts: 114
Joined: May 7, 2004


Posted: Jun 8, 2010 05:57 PM          Msg. 2 of 16
For back-testing real-time trading systems you need the historical data to match exactly what was sent on the real-time feed. That includes bad ticks, ticks that weren't properly split-adjusted, and split-adjusted trades that took place before the announcement of the split was transmitted on the feed.

My app uses intraday historical data. Every month I see some cases where a split announcement isn't transmitted until after the split actually took place. You'd definitely need to fix that or else automatically split-adjusted data would be a mess, or possibly inconsistent depending on when an app makes an historical data request.

Also, just as a matter of good software engineering practice, you shouldn't make incompatible changes that break your customers' apps unless you're forced to, in the course of fixing something even worse.

Allen

dlmeyers
-Interested User-
Posts: 1
Joined: Jun 8, 2010


Posted: Jun 8, 2010 06:24 PM          Msg. 3 of 16
Split adjusting intraday data would definitely break my software *dramatically*. My software was specifically engineered to accept only non-split adjusted data as DTN provided it. I might add that if you were to split adjust data, then some kind of a mechanism needs to take place to inform feed parsers of the split in real time.

arnonmoscona
-Interested User-
Posts: 5
Joined: Jun 8, 2010


Posted: Jun 8, 2010 06:50 PM          Msg. 4 of 16
In our case back testing is not affected. We run candidate strategies against a tick simulator that uses historical data and all of our code works with split adjusted values. So the split adjusted intraday history would only server to simplify it, which is a good thing even if we need to change code.

Arnon Moscona

russt
-Interested User-
Posts: 12
Joined: Dec 11, 2009


Posted: Jun 8, 2010 07:11 PM          Msg. 5 of 16
Please do not change the intraday data in a backward incompatible way. It would however be very nice for you to provide dividend and split histories separately from the price series.

stargrazer
-DTN Evangelist-
Posts: 242
Joined: Jun 13, 2005

Right Here & Now


Posted: Jun 8, 2010 07:22 PM          Msg. 6 of 16
I agree with taa_dtn: "For back-testing real-time trading systems you need the historical data to match exactly what was sent on the real-time feed. That includes bad ticks, ticks that weren't properly split-adjusted, and split-adjusted trades that took place before the announcement of the split was transmitted on the feed."

The historical values need to reflect what was traded in real time in order ascertain that trading algorithms are doing what they are supposed to be doing.

taa_dtn
-DTN Evangelist-
Posts: 114
Joined: May 7, 2004


Posted: Jun 8, 2010 07:24 PM          Msg. 7 of 16
Hmm. Maybe I'm missing something because I don't know your application, but I don't see how split-adjusting intraday historical data can simplify back-testing code.

The reason is that to simulate trades correctly, you need to know the actual price you would have paid ON THE DAY OF THE TRADE. You'll still have to track splits so that you can work out this NON-split-adjusted price.

Furthermore, the non-split-adjusted price might even be needed to determine IF you'll make a trade -- for example, if your system wants to trade equities that fall in a certain price range, or your money-management algorithm needs to know an accurate account balance or transaction cost to decide what size transaction to make.

I don't think there's a free lunch here. You pretty much have to pay full attention to splits, whether the price and volume data are presented as split-adjusted or not. Changing from non-adjusted to adjusted doesn't simplify things, it just breaks existing code and forces existing historical databases to be reworked to match the new semantics.

Allen

drp7804
-Interested User-
Posts: 4
Joined: Aug 27, 2009


Posted: Jun 8, 2010 08:50 PM          Msg. 8 of 16
My vote/recommendation is to keep the default historical pull as non-split adjusted, as it has been. If there's a desire to have split adjusted intraday data, provide that as an option somehow in the API (ideally in a way which doesn't force everyone to change their existing API calls).

tabele
-Interested User-
Posts: 1
Joined: Jun 9, 2010


Posted: Jun 9, 2010 12:33 AM          Msg. 9 of 16
Another way would be to add an additional field containing a SplitAdjustmentFactor, so everyone can decide what to do with it

kubilai
-Interested User-
Posts: 1
Joined: Jun 9, 2010


Posted: Jun 9, 2010 12:36 AM          Msg. 10 of 16
Agree with taa_dtn. I also have a realtime trading system that needs data as was seen on the day of the trade.

Niklas
-Interested User-
Posts: 1
Joined: Jun 9, 2010


Posted: Jun 9, 2010 03:34 AM          Msg. 11 of 16
Please do not change to split-adjusted intraday prices. They should reflect the real prices during the day and not be adjusted in any way.

But I would really like to see an extension to the API where it is possible to retrieve historical splits and dividends separately to be used by the client software on unadjusted intraday or day prices.

For example from 2010-04-02 the adjusted price is 2 times the unadjusted, from 2010-05-15 it is 2.5 times the unadjusted, etc. One row per change in the adjustment factor due to a split or dividend.

RSC
-Interested User-
Posts: 4
Joined: Feb 10, 2010


Posted: Jun 9, 2010 04:53 AM          Msg. 12 of 16
+1

"The historical values need to reflect what was traded in real time in order ascertain that trading algorithms are doing what they are supposed to be doing."

Roger Herbst
-Interested User-
Posts: 4
Joined: Jun 12, 2010


Posted: Jun 12, 2010 12:52 PM          Msg. 13 of 16
First preference is unadjusted with available table of adjustments so I can construct them

Second preference is adjusted with available table of adjustments so I can deconstruct them

Third preference is the status quo and I'll continue to use whatever sources I can scrounge
from the web to construct adjustments.

WORST CASE SCENARIO - Change to adjusted data and make me change to deconstruct when necessary. And if the adjustment is inaccurate, I have no way to verify and/or correct it.

We really need an adjustment table. That goes double if you're thinking of extending this to dividends.

Roger

taa_dtn
-DTN Evangelist-
Posts: 114
Joined: May 7, 2004


Posted: Jun 12, 2010 04:58 PM          Msg. 14 of 16
I agree that a table of split adjustments would be useful, though maybe less often than you'd first guess. All you really need to know is the adjustments that cover the maximum date range that can be fetched (30 days for ticks), and the two splits that we have today are sufficient for all the intraday cases I've seen. But other people's usage patterns may be different from mine, and of course if you're fetching daily (or longer) bars you'll almost certainly need more than the last two splits to reconstruct all the real-time prices and volumes.

I'd like to point out one more problem with split-adjusted prices: The data you get from a history request depends not only on the split history, but also on the date you make the request. For example, suppose you make a tick history request for one day at end-of-day on June 14th and store the results in a database. A split occurs on June 15th. You make another history request, this time for two days at end-of-day on June 15th. The data you get for June 14th will be different -- it won't be adjusted for the split the first time, but it will be adjusted the second time.

Why does this matter? If you're using history requests to build a database for either back-testing or recording context you need for your trading system (support and resistance levels, for example), then to interpret the data correctly you would not only need a table of splits, you would also need a table of the dates you made the history requests. (Or alternatively, you could rewrite all the old prices and volumes in your database for the equity exactly once when you see a split for the first time.)

Non-split-adjusted data is preferable because it doesn't have this extra complication. No matter when you make a history request for a given period of time, you get exactly the same data. You don't need to track your own history requests or munge your existing databases.

Allen

Gremlin123
-Interested User-
Posts: 6
Joined: Aug 18, 2010


Posted: Aug 18, 2010 06:25 PM          Msg. 15 of 16
Sorry for the late response, but I just had to deal with this issue.

As traded data is better than adjusted data for backtesting, at least when working with tick data. For one thing, the tick data we can download is way to short, only 30 days. So, we have to save it and build a tick database. If we had to deal with split and div adjustments, we would have to back adjust the tick data we already downloaded.

I tried very hard to back out the adjustments to daily data and failed. The data in the fund message is just too dirty to do it right. I finally just downloaded the data from yahoo.

Wish that there was a table of corp actions to account for dividend and splits. It would make it simpler and explicit.

AMA
-DTN Evangelist-
Posts: 179
Joined: Aug 1, 2007


Posted: Aug 22, 2011 07:06 PM          Msg. 16 of 16
Either leave as-is, or, better yet, provide both types of data with some option setting to specify.

Backwards compatibility should be assumed with this kind of software. Too many people have time & effort invested to try to retrofit their code because of a 'new and improved' changed.
 

 

Time: Sat November 18, 2017 5:11 PM CFBB v1.2.0 31 ms.
© AderSoftware 2002-2003