when using historical lookup, how would I best acheive the following?

if I have a strategy that uses say 10k tick (or volume) bars, and it needs 50 of these bars to bootstrap itself.... how would I request this number of bars relative to an arbitrary date (eg if I'm booting in a simulation that runs from last year).

the only way i can think is to request 50 bars back from today, and look at the date of the oldest bar and start counting all older bars (and requesting more) until I get 50. this is really inefficient though. i could leave it up to the user, but that's error prone.

is there a better way w/iqfeed?

Take a look at the History Interval Timeframe request from the feed. You can specify a Begin Time, End Time, and interval (in either seconds, ticks, or volume).

Leave the begin date/time blank and supply your initial date as the end date with the number of bars as the max datapoints parameter. This will give you the number of bars you specified immediately prior to the date/time you specify in the end date.

The only issue you may run into here is that our tick/volume/second bars have the same limitation as tick data which means that you can currently only get the last 120 days. You can use time based interval bars (in multiples of 1min) back several years.

i think maybe you're mixing up two requests, because history interval timeframe doesn't support max datapoints.

// HIT,SYMBOL,INTERVAL,BEGINDATE BEGINTIME,ENDDATE ENDTIME,,BEGINFILTERTIME,ENDFILTERTIME,DIRECTION,REQUESTID,DATAPOINTSPERSEND,INTERVALTYPE<CR><LF>

that's sort of the reason for my question because the requests that support maxdatapoints don't support start and end times, and vice verca. be nice to see this in a future version (supporting reference dates on 'maxdatapoint' allowing commands)

at least for volume bars i could request 1min time bars using the dates and reconstruct the volume.

but to reconstruct tick bars i'd have to get ticks, which is limiting as you point out. (i guess you're doing something similiar internally if they all have the same limit)

The empty parameter between ENDDATE ENDTIME and BEGINFILTERTIME is the Max datapoint parameter. The parameter was initially included in the protocol but then removed and later re-added so there are probably a few places where the documentation I still incorrect. I have gone through the docs (and example apps) trying to eliminate this inconsistency in the next version of IQFeed (5.1). If you want to let me know where you copied/pasted that from, I'll doublecheck it.

ah, well that's great to hear.

i got it from your c# example for histsockets.

i see that the main documentation now reflects what you saying, thanks again.