|
|
Home
Search
Register
Login
Recent Posts
| Viewing User Profile for: napoleon | |||||||||||||||||||||||
| About | Contact | ||||||||||||||||||||||
|
|
||||||||||||||||||||||
| Post Statistics | |||||||||||||||||||||||
|
napoleon has contributed to 9 posts out of 21183 total posts
(0.04%) in 1,117 days (0.01 posts per day).
20 Most recent posts:
Data Questions »
Adjusting Data for Stock Splits Apr 19, 2021 04:29 PM
(Total replies: 4)
Thanks, but I am not interested in this enhancement. My comment was just to suggest that if it is changed, that there is a way to make sure people can opt-out so it doesn't break applications that depend on the current behavior. I am happy with it the way it is now and don't think it is necessary to change anything.
Data Questions »
Adjusting Data for Stock Splits Apr 17, 2021 12:14 AM
(Total replies: 4)
If this is ever considered for an enhancement, I would like to suggest that it be an optional change that the user can select through the API. While it may fix issues with Ninja Trader to stop split adjusting the daily data, other users may rely on this behavior and it may break their applications if it were to be changed. I use the ratio between historical daily and minute data to detect splits in historical data. I have found this more reliable than using the last 2 splits that are available in fundamental data, and of course this method allows splits to be calculated for the entire available daily and minute history, not just the last 2 splits. So please don't change this without a way for users to opt out of the change and keep the current behavior.
Data and Content Support »
Missing historical tick data for RIDE and TSNPD Apr 1, 2021 02:31 PM
(Total replies: 15)
Yes, I agree with everything you said, except it is February 24th that has the weird formatting, not the 23rd. I agree that all other days including the last 8 that you can see during market hours are all formatted as expected.
Data and Content Support »
Missing historical tick data for RIDE and TSNPD Mar 31, 2021 11:59 PM
(Total replies: 15)
I am referring to times in Eastern Time Zone. The RIDE Volume errors were visible using your own Time and Sales app. You have to have extended hours turned on in the settings since they are after 16:00 EST. I rechecked today and they are fixed. Maybe someone from your data team read my post before you did and snuck in the correction ;) In case you want to know for preventing it in the future, here is a sample of what was downloaded yesterday (raw text data downloaded using IQML with all parsing turned off): (The last field is volume - note the reset on the first tick after 16:30 EST: Timestamp,Last,Bid,Ask,LastSize,BasisForLast,TradeConditions,TradeMarketCenter,TickID,TotalVolume 2020-10-26 16:28:49.933475,18.8100,18.8100,18.9000,1,O,874717,26,6139,4959655 2020-10-26 16:28:49.933484,18.8100,18.8100,18.9000,25,O,874717,26,6140,4959680 2020-10-26 16:28:49.933828,18.8100,18.8100,18.9000,69,O,8717,11,1987,4959749 2020-10-26 16:30:21.641880,18.8200,0.0000,0.0000,25,O,874717,26,6141,25 2020-10-26 16:30:21.642753,18.8100,0.0000,0.0000,31,O,8717,11,1988,56 2020-10-26 16:30:21.643587,18.8000,0.0000,0.0000,444,E,1747,26,6142,500 Here are the same ticks downloaded today (identical except for the volume field does not reset): Timestamp,Last,Bid,Ask,LastSize,BasisForLast,TradeConditions,TradeMarketCenter,TickID,TotalVolume 2020-10-26 16:28:49.933475,18.8100,18.8100,18.9000,1,O,874717,26,6139,4959655 2020-10-26 16:28:49.933484,18.8100,18.8100,18.9000,25,O,874717,26,6140,4959680 2020-10-26 16:28:49.933828,18.8100,18.8100,18.9000,69,O,8717,11,1987,4959749 2020-10-26 16:30:21.641880,18.8200,18.8000,18.8900,25,O,874717,26,6141,4959774 2020-10-26 16:30:21.642753,18.8100,18.8000,18.8900,31,O,8717,11,1988,4959805 2020-10-26 16:30:21.643587,18.8000,18.8000,18.8900,444,E,1747,26,6142,4960249 This reset was there yesterday on all 5 days that you just restored that were missing (Oct 26-30 2020) at the 16:30 EST transition and 17:20 EST transition. They are all fixed as of today. Also, I retested the NO DATA reliability issue I mentioned yesterday and it is also fixed. I now have perfect reliability when querying these days, whereas yesterday it was failing more than half the time (only on those 5 days for RIDE - not other days or symbols). Maybe it finished propagating to your other servers. Anyway, it is correct now so no need for further fixes for RIDE. Thank you to whoever fixed it :) The SCR formatting issues don't appear in time and sales because it appears to apply a fixed number of digits as part of it's display formatting, even if the raw underlying data does not have them. I've already fixed my parsing for SCR so it's not important to me anymore, I just mentioned it in case you want to maintain formatting consistency to prevent parsing errors for your other users. The formatting I am talking about are the raw unparsed characters as sent over the API from IQConnect and logged when queried using IQML. SCR on 2021_02_24 is the only day out of hundreds of thousands I've downloaded that is formatted this way. It is still showing up like this today after redownloading. Here is a sample (Note the inconsistent number of digits on last price ranging between 0 and 4): Timestamp,Last,Bid,Ask,LastSize,BasisForLast,TradeConditions,TradeMarketCenter,TickID,TotalVolume 2021-02-24 09:30:17.815000,31.6375,0.00,0.00,50,O,87,3,37292,2656 2021-02-24 09:30:20.038000,32,0.00,0.00,200,C,01,3,38668,2856 2021-02-24 09:30:20.099000,31.7974,0.00,0.00,50,O,87,3,38699,2906 2021-02-24 09:30:28.077000,31.5,0.00,0.00,50,O,87,3,41996,2956 2021-02-24 09:30:28.484000,31.64,0.00,0.00,50,O,87,3,42046,3006 Here is a sample from the previous day (and is consistent with all other days). Notice there that even if the price is a whole integer dollar amount, there are always exactly 4 digits after the decimal point for Last Price, and for Bid and Ask: Timestamp,Last,Bid,Ask,LastSize,BasisForLast,TradeConditions,TradeMarketCenter,TickID,TotalVolume 021-02-23 09:32:34.045000,29.3731,0.0000,0.0000,100,C,01,3,98963,46312 2021-02-23 09:32:34.046000,29.3730,0.0000,0.0000,950,C,01,3,98967,47262 2021-02-23 09:32:36.059000,29.0000,0.0000,0.0000,100,C,01,3,99346,47362 2021-02-23 09:32:36.060000,29.0000,0.0000,0.0000,75,O,87,3,99349,47437 2021-02-23 09:32:44.049000,28.8000,0.0000,0.0000,1,O,87,3,101063,47438
Data and Content Support »
Missing historical tick data for RIDE and TSNPD Mar 31, 2021 01:16 AM
(Total replies: 15)
Actually, on closer inspection, there are still problems with the RIDE and SCR data that was just made available. For RIDE tick data, the total volume field resets itself counting from 0 + the last incremental volume at 16:30 and again at 17:20 on all 5 days that were previously missing (Oct 26 -Oct 30 2020). On days before and after that week, total volume is never decreasing throughout each day. It should be impossible for total volume to ever decrease unless there is a data error, right? Also, for the same 5 days of RIDE tick data, queries for ticks on those days return empty over half the time. When querying data for other days or other symbols, I am getting 100% reliable behavior (i.e. never a NO DATA response unless there really is no data). On just these days for this symbol, over 50% of the time I get a NO DATA response. I wonder if the changes haven't propagated to all of your servers possibly? I do not see this reliability issue with the new SCR data. For SCR on 2021-02-24, there is an inconsistent number of characters after the decimal for Last, Bid, and Ask price (other days before and after this has consistently 4 decimal places). This data sometimes has no decimal at all when the price is an integer number of dollars, and doesn't have the same number of digits after the decimal between Last, Bid, and Ask, even on the same tick. While not technically wrong, it does not match the format of your other data and makes my parsing code fail, even though it has not failed before on many thousands of days of other tick data. I'll fix my parsing to handle missing decimal points for this special case, but it is still very strange that this is the only day I am aware of that has any price data without decimal points and a fixed number of trailing digits.
Data and Content Support »
Missing historical tick data for RIDE and TSNPD Mar 30, 2021 02:06 PM
(Total replies: 15)
I see that the RIDE and SCR data is fixed. Thank you! I'm not sure If I'm understanding the format of the symbol changes file. I attached a screenshot of the one from today to this post for reference so that it will still make sense after the file is overwritten. The new symbol changes file from today seems to have yesterdays changes in it as well with some modification to the NEW ISSUER fields, which were blank yesterday for BTX. The entries that are leftover from yesterday don't have the *. Will changes always be included for multiple days and appear without the * after the first day, or is this a special case? How many days will the older entries remain in the file? Can you elaborate on what the * means and the new items database? The reason I ask is because knowing this would help assign the appropriate date to changes if the file wasn't downloaded on the previous day, but one wanted to know what date the older changes were made. If they always stay in the file only one day after the first day, that would mean any entries without the * are from the first day in the date range (03/29/2021) and items with the * are from the end of the date range (03/30/2021). That is true for this particular file, but is that a valid assumption in general? Thanks for your help.
Data and Content Support »
Missing historical tick data for RIDE and TSNPD Mar 29, 2021 09:35 PM
(Total replies: 15)
Thank you. That is helpful to know about the symbol guide. Do you have a list of the possible types of changes that I can expect to be in the symbol guide? I.e. does it include delisted, mergers, acquisitions, etc? Are historical symbol guide files available, or are they lost once overwritten? Also, I would still appreciate it if your data team could also respond regarding the missing data for RIDE and SCR that are mentioned in the posts above.
Data and Content Support »
Missing historical tick data for RIDE and TSNPD Mar 29, 2021 03:02 AM
(Total replies: 15)
TSNPD is the exact ticker that I successfully used to download tick data in the last few weeks. History continuing through friday is shown here: https://sg.finance.yahoo.com/quote/TSNPD/history?p=TSNPD But the symbol has completely ceased to exist as far as IQFeed is concerned. After I wrote my original post, I found out that there have been ticker changes with TSNP->TSNPD->HMBL "HUMBL’s stock symbol will change to “TSNPD” on February 25, 2021 and then to “HMBL” on March 26, 2021." https://www.globenewswire.com/news-release/2021/02/25/2182875/0/en/HUMBL-Inc-Completes-Corporate-Actions.html From the user's perspective using IQFeed, the symbol just ceased to exist, giving the impression that the data was missing after the last day that I had downloaded. Is there any automated way for IQFeed users to be informed of such ticker changes (preferably in advance)? When downloading historical data for many symbols this can be a tedious manual job to research and keep track of delisted / changed / merged symbols. Rather than each user manually doing that through their own research, it would seem much preferred for it to be part of IQFeed's data. Or if there is a reliable web site with that info that would also help, but all that I have found are very hit and miss. As for the question about RIDE, that seems to be a different case without any symbol changes, just missing data. Also the symbol SCR has missing tick / minute data on 2021-02-24. See the attached time and sales screenshot that shows daily data but no minute data
Data and Content Support »
Missing historical tick data for RIDE and TSNPD Mar 27, 2021 02:32 AM
(Total replies: 15)
Historical tick data seems to be missing for certain symbols on certain days. Here are some example symbols and days where they are known to have trading volume based on other charting websites, but IQFeed is returning historical ticks as if they didn't: RIDE: Available as expected: Oct 23 2020 and earlier Nov 2 2020 and later Missing: Oct 26 2020 to Oct 30 2020 TSNPD: Available as expected: Sept 28 2020 to Oct 22 2020 (any missing days in this range are because there was actually 0 volume) Missing: Oct 23 2020 to Mar 26 2021 |
|||||||||||||||||||||||