> Ok, so you prefer to have us calculate high/low/close for the day from the > market book data? Or, should we still use IB to get today's high/low/close > (in the event we are recording)? > > What if our jbook is briefly turned off while a high occurs. Shouldn't we > trust IB more than ourselves due to this possibility?
There are several different ways to get this data from IB in real-time. I would have to look at my raw-recorder data again to see what comes up. I feel like there is some specific open/high/low/close data for the entire day that gets broadcast, but I am not sure. If you mess up a day then we should record something that says the data is bad. Then we can hand edit the file later (should be easy to find the values). > Regarding the GUI, I think I can do this with no GUI impact. This would > simply be another type of indicator that a Strategy can get a reference too. > This would keep things really simple for the initial impl, and reduce the > risk of any impact to the existing trading code. In the long term we would need a visual display that the index's stream is alive. At least, I would like that. As Eugene says, we would probably need some modifications to the backtesting window. > There is a much simpler way out, though. We can add another column to the > existing recording format, to record whatever we define as a "long term > trend". For example: I admire the simplicity of the idea, but I want more data. More columns could work. It would probably be a significant amount of additional time for the optimizer. Also, I'm not sure how you would read the data between strategy restarts - except for the obvious way (read the end of the file) which itself is a little tricky for really long files. On Wed, Jan 9, 2013 at 5:23 PM, Eugene Kononov <[email protected]> wrote: > >> Regarding the GUI, I think I can do this with no GUI impact. This would >> simply be another type of indicator that a Strategy can get a reference too. >> This would keep things really simple for the initial impl, and reduce the >> risk of any impact to the existing trading code. > > > > Not sure how you'd do this without affecting the GUI. Wouldn't you need to > add the corresponding controls to the backtesting and optimization dialogs > to specify the *second* historical data file? The GUI changes aside, there > is a lot more to do in the back end to somehow synchronize these data files. > > There is a much simpler way out, though. We can add another column to the > existing recording format, to record whatever we define as a "long term > trend". For example: > > # This historical data file was created by JBookTrader > # 1. date in the MMddyy format > # 2. time in the HHmmss format > # 3. book balance > # 4. price > # 5. volume > # 6. long-term trend (in relative strength units) > > timeZone=America/New_York > > 010713,080904,4.0,1455.875,10,95 > 010713,080905,4.61,1455.875,5,95 > 010713,080906,4.63,1455.875,1,95 > 010713,080907,4.64,1455.875,0,95 > 010713,080908,4.59,1455.875,1,95 > 010713,080909,4.63,1455.875,0,95 > > That way, very few things would need to change, and all components of the > system would be intacts. The downside is, of course, you've got to collect > this for a year or so, before it becomes usable. > > > > > -- > You received this message because you are subscribed to the Google Groups > "JBookTrader" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/jbooktrader?hl=en. -- You received this message because you are subscribed to the Google Groups "JBookTrader" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jbooktrader?hl=en.
