Open TrainedPro opened 1 year ago
Can you try again? Or can you submit a code example that produces the problem (in addition to the output)?
I recently wrote a bunch of tests (test_bars.py) that shows this is working for daily bars (for alpaca, polygon, pandas, and now tradier). When length is greater than zero, timestep="day" and timeshift =None, all return N bars where N == length.
Description
Using the
get_historical_prices()
function with Alpaca does not returnlength
number of time-steps. This is inconsistent with other data-sources such as Yahoo Finance which would returnlength
number of time-steps. This causes there to be a discrepancy between back-testing and live trading. This could also be why issue #258 is caused.The part of the repository that seems to cause this issue is because of: https://github.com/Lumiwealth/lumibot/blob/507c06baa41d74030f6da7237f9bd07910755b11/lumibot/data_sources/alpaca_data.py#L163-L166 This does not update the
curr_start
.This is in contrast to what Yahoo Finance does which is getting all the data and then getting the number of rows required, so the data-frame always has length number of rows: https://github.com/Lumiwealth/lumibot/blob/507c06baa41d74030f6da7237f9bd07910755b11/lumibot/tools/yahoo_helper.py#L174-L176 https://github.com/Lumiwealth/lumibot/blob/507c06baa41d74030f6da7237f9bd07910755b11/lumibot/data_sources/yahoo_data.py#L92-L95
Outputs
Alpaca
Yahoo Finance
Dates are slightly different but the point is the same as the length is vastly different between them both. This could cause major issues between back-testing and live trading.
Expected Behavior
Back-testing and live trading data should be similar, whether it is based on getting 200 time-steps of data (not necessarily 200 bars) or 200 time rows of data (may be more than 200). The documentation is also very ambiguous rather this issue where it states here that bars may not be equal to the length but that is opposed by what is stated here.