Support Board
Date/Time: Sun, 22 Dec 2024 13:32:04 +0000
Post From: Rollover problem
| [2015-04-26 05:55:58] |
| bekitz3 - Posts: 83 |
|
*(1)* Our comments in post 12 were related to post 6 of yours. The problem you had there, the other user could not have had at all and was unrelated because they are using TransAct and you are using TT
Well I certainly cannot dispute this. Perhaps the user was simply expressing empathy as a fellow trader in post #10 after seeing all the steps I was taking to resolve the issue on my end. *(2)* From what we understand, from the first post, the information we gave the user, resolved the problem and it was over and done with. That is usually how it works when there is a problem.
The first post was the initial communication of the issue at hand!!! They couldn't have possibly executed your suggestion since that came in post #2. That doesn't mean they didn't coincidentally re-download data anyways based on Help/FAQ's or other documentation on your website or pure trial & error, but not due to your suggestion.....unless they are a prophet. They simply said this: I think I just figured out the answer. I changed the rollover rule to date based instead of volume based and it worked.
in post #1 before you even offered any advice. That doesn't seem to imply that a data re-download was their solution. After that, I don't see any other evidence that the problem was solved on their end other than this switch to a [CB] chart....which you have communicated is not the most accurate choice for CL. If they did perform a re-download and it worked for them...great. It did not work for me. Thus, a simple illustration where 2 anonymous users experience the same initial problem......then execute the 1st step suggested by support......and experience vastly different paths to get to the final solution....normal looking charts. This could be a plausible explanation for what appears to be shared frustration as expressed in posts #4 and #10 (and it should be noted post #4 is their first response after your suggestion)This still does not explain how when switching to [CB], the missing 2 weeks suddenly appear, and when switching back to [CBV] they disappear again. This tells me that the raw data does exist within the .scid and that the software is not accurately referencing this data based on a user selection within the software. Which would seem to indicate that re-downloading data that already has all of the information needed would not be a very successful solution to the problem. *(3)* You also need to understand the Continuous Futures Contract functionality is very complex. After two years of experience with it, it is not possible for it to work 100% perfectly all the time without some manual user intervention of re-downloading data when a problem occurs.
I can tell you from a user's perspective, it is not perceived to be complex. As a non-developer user, it doesn't mean that I'm correct in that perception though. But I can say from using other platforms that offer this functionality (Tradestation, NinjaTrader, MultiCharts, etc) I haven't noticed this kind of behavior. Maybe this is because they choose to handle this concept differently and that is why they are more successful when it pertains to this functionality of trading software.The one observation I notice between these 2 approaches is that the others tend to treat this continuous contract concept with a segregated symbol identifier or separate file. How they get there and do this....I wouldn't be able to tell you. It's possibly similar to the concept I mentioned earlier where when I did the continuous contract manually (adjusting & joining data), I was in essence dealing with one file with all of the individual contract data appended appropriately within this file and then assigned the front month identifier/designation. Then upon any future changes to data feeds, price multipliers, unforeseen events by developers, etc......the software would not have to break down or cross-compare all of the individual component contracts to determine the rollover points. But I already know you are not interested in this approach and have documented this on your site. You have your reasons to stick with the current method and keep all of the individual components of the continuous contract isolated from one another. Which leads to this suggestion: Perhaps you could consider the notion that when a user requests a re-download from within a continuous contract chart, the software will automatically treat these individual contract components as if they were being requested within a non-continuous contract chart. I referred to this observation in my last post: If I re-download on a continuous chart, the file sizes for the .scid's are smaller than if I individually re-download each of these contracts on a non-continuous chart. So there is a truncation of data taking place which seems like it would be more prone to potential gaps & holes when consolidating this data for continuous contract chart display purposes. Maybe the re-download event should aim to acquire all of the data for each .scid in the continuous chart, keep these .scid's intact, then the software can do the volume analysis to determine rollover points and then create new, separate truncated files (.scidc or .idc where the last c = continuous) for each contract and use those to build the continuous chart . It seems like the reverse is happening where the software thinks it already knows the rollover point (maybe from a previous user usage of this feature), and when requesting new data, it is discarding data that may be needed to result in more accurate/consistent performance of this continuous contract feature. *(4)* There is a dependency upon the two different data files when using volume-based rollovers in Intraday charts.
This is not intuitive. This should be noted inside the continuous contract documentation then. This would be analogous to upgrading MS Word from 2007 to 2013, and then finding out all of my .ppt or .xls files are jacked up. |