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)




"Thank you so much - awesome feed, awesome service!" - Comment from Greg via Email
"Thanks for the great product and support. During this week of high volume trading, my QuoteTracker + IQ Feed setup never missed a beat. Also, thanks for your swiftness in responding to data issues. I was on ******* for a few years before I made the switch over early this year, and wish I had done it a long time ago." - Comment from Ken
"Just a quick one to say I'm very impressed so far :) The documentation for developers is excellent and I've quickly managed to get an app written to do historical downloads. The system is very robust and pretty quick considering the extent of data that's available. The support guys have been very helpful too, in combination with the forums it's been plain sailing so far!" - Comment from Adam
"You have an excellent product !!!!!!" - Comment from Arely
"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
"Awesome response, as usual. It is a sincere and refreshing pleasure to do business with DTN, compared to your competition." - Comment from Ryan
"Its working FABULOUSLY for me!! Holy cow...there has been so much I've been missing lately, and with this feed and Linnsoft software...I'm in the game now." - Comment from Chris R.
"I've been using IQFeed 4 in a multi-threaded situation for the last week or two on 2600 symbols or so with 100 simultaneous daily charts, and I have had 100% responsiveness." - Comment from Scott
"I would just like to say that IQFeed version 4 is running very well and I am very happy with its performance. I would also like to extend a big thanks for the fast and efficient help that I always receive. My questions and concerns are always addressed promptly. Way to go!" - Comment from Josh in CO.
"IQFeed version 4 is a real screamer compared to anything else I have seen." - Comment from Tom
Home  Search  Register  Login  Blogs Recent Posts

Information on DTN's Industries:
DTN Oil & Gas | DTN Trading | DTN Agriculture | DTN Weather
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: 1747
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: 243
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: Fri April 20, 2018 3:44 AM CFBB v1.2.0 16 ms.
© AderSoftware 2002-2003