Feat/historical_forecasts accept negative integer as start value

[madtoinou]

Summary

• Allow historical_forecasts() to receive a negative integer as start value by extending the get_index_at_value() method.
• Added a simple unit-test covering this scenario and updated the tests expecting exception in such cases

Other Information

This feature is to be used in EnsembleModel so that forecasting_models can call historical_forecasts() instead of predict(), which should improve the results depending on the models being ensembled.

[codecov-commenter]

Codecov Report

Patch coverage: 77.77% and project coverage change: -0.06% ⚠️

Comparison is base (b3463ea) 93.87% compared to head (ba13934) 93.82%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1866      +/-   ##
==========================================
- Coverage   93.87%   93.82%   -0.06%     
==========================================
  Files         132      132              
  Lines       12677    12692      +15     
==========================================
+ Hits        11901    11908       +7     
- Misses        776      784       +8     

Files Changed	Coverage Δ
darts/models/forecasting/forecasting_model.py	94.88% <50.00%> (-0.34%)	⬇️
darts/models/forecasting/regression_model.py	96.59% <50.00%> (-0.43%)	⬇️
...orical_forecasts/optimized_historical_forecasts.py	86.58% <50.00%> (-1.88%)	⬇️
darts/utils/historical_forecasts/utils.py	94.08% <91.30%> (-0.66%)	⬇️
darts/timeseries.py	92.67% <100.00%> (-0.05%)	⬇️

... and 5 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dennisbader]

That's a nice attempt at supporting start < 0.
However, changing the method get_timestamp_at_point() leads to ambiguous results as it's supposed to return the index position where the index value corresponds to the point value. For integer indexed TimeSeries that start at a negative index value, the method would result in the wrong index position.

Can we avoid this somehow?

Also when I read the historical_forecasting documentation when start is an integer:

If an ``int``, the parameter will be treated as an integer index to the time index of
`series` that will be used as first prediction time.

As far as I can tell if we have a series with RangeIndex, then start must exist in the RangeIndex. So also there having an integer start can be ambiguous as it can either mean the position of the actual index value or just the index position.

[dennisbader]

Looks very nice, thanks a lot @madtoinou , only had really minor comments.

[dennisbader]

Thanks @madtoinou this also looks great 🚀
Just some minor suggestions mainly about the documentation. After those we can merge

[dennisbader]

I would prefer ["position", "value"] to make it shorter, WDYT?

Also, can we make this only effective when the series is indexed with is a range index?
For DatetimeIndex, start is well defined for all types. I assume that most of the use cases are using DatetimeIndex, and it would be easier if they didn't have to change the start_format when they want to pass an integer.

Only for range index we need to know if it's a position or value.

[madtoinou]

Completely agree!