Thanks for your contribution, much appreciated.

Can you please elaborate how are you identifying which forecasters support non-contiguous X and what does not? For example, if you check #8740, StatsForecastAutoARIMA does not actually fail the predict call even if passed horizon (fh) and exogenous data (X) shapes don't align, and all it checks (I think, did not verify, may be wrong) is the shape and not actual time identifiers.

So, how did you determine what all forecasters face this issue? Is it from just test failures, or did you verify by checking one by one, or some other way?

They were failing the test_predict_time_index_with_X test when fh= [2,5] , and were listed in the issue I am solving. Check #8787
I have reproduced the bug using the same [2,5] example and tried a different contiguous example to make sure the estimator actually works.

For the example you have mentioned, I believe it doesn't fail cuz from 1:3 (what the estimator managed to predict) were contiguous already, no gaps, it couldn't predict 4 and 5 cuz it doesn't have X for them. I think this might mean theat the estimator behavior when passed fh, X that doesn't align in shape is taking the min, and won't fail as long as what it is trying to predict is contiguous.

Thanks for your contribution, much appreciated.

Can you please elaborate how are you identifying which forecasters support non-contiguous X and what does not? For example, if you check #8740, StatsForecastAutoARIMA does not actually fail the predict call even if passed horizon (fh) and exogenous data (X) shapes don't align, and all it checks (I think, did not verify, may be wrong) is the shape and not actual time identifiers.

So, how did you determine what all forecasters face this issue? Is it from just test failures, or did you verify by checking one by one, or some other way?

@yarnabrina @fkiraly Regarding passing horizon (fh) and exogenous data (X) shapes that don't align, I have investigated and actually it doesn't take the min as I said, to be more precise:

• If we are using the sktime wrapper, it would actually fail, as with the wrapper implementation it requires fh and X to align. In your code you haven't used the sktime wrapper, instead you used the model directly from statsforecast.models , that's why it worked.

• This behaviour is not the same for all models btw, for example: 'ARDL' model actually doesn't require 'fh' and 'X' to align, whether you are using the sktime wrapper or not

note: the syntax I am using is arbitrary
Another interesting point that I have noticed:
fitted_model.predict(5) has different bahaviour whether you are using sktime wrapper or not

1. Without the sktime wrapper, you need to pass 'start' , 'end' parameters, it would be something like this:

y_pred = fitted_model.predict(
    start = start,
    end=end,
    exog_oos=X_oos
)

• the default value for start is the first element in the training data, and for end it's the last element in the training data, so even if we don't pass a start, given that we have X, we will manage to predict with fh=5, cuz there is no gap (in the inner calculations), for simplicity:
  fh(5) = fh([1,2,3,4,5])

2. In the other hand, with the sktime wrapper, when you say fitted_model.predict(5)
   the default values for start and end would be min , max of the passed hf respectively
   for the case: fh = 5, both start and end would equal 5, That's why it's gonna fail to predict, as now we have gaps, for simplicity:
   fh(5) = fh([5])

Just now I have tested fh = ForecastingHorizon([3,4]) with the sktime wrapper, and it worked! although if we are gonna follow the previous rules I have stated above, it's gonna fail cuz we have gaps 1,2

but what is way more weird is that I have tested fh = ForecastingHorizon([3,5]) and it also worked perfectly fine :)
I no longer make sense of what's happening, if fh=[3,5] can actually work, then I am afraid the problem wasn't actually about non-contiguous fh from the beginning, AAA, not sure any more.

@fkiraly could you please check if I am missing something? I have also checked with the exact fh = np.array([2, 5], dtype="int64") value we have in our 'TEST_OOS_FHS' that made the estimators fail in #8787 and it still worked!
here is the code I tested the above examples with

from sktime.datasets import load_longley    
from sktime.forecasting.ardl import ARDL    
from sktime.forecasting.base import ForecastingHorizon    
from sktime.split import temporal_train_test_split  
import numpy as np
  
# Load data with exogenous variables    
y, X = load_longley()    
    
# Split into train and test using temporal_train_test_split  
y_train, y_test, X_train, X_test = temporal_train_test_split(y, X, test_size=5)  

# Select specific exogenous variables    
X_train = X_train[["GNPDEFL", "GNP"]]    
X_test = X_test[["GNPDEFL", "GNP"]]    
# Create ARDL model with lags and order for exogenous variables    
ardl = ARDL(lags=2, order={"GNPDEFL": 1, "GNP": 2}, trend="c")    
    
# Fit the model    
ardl.fit(y=y_train, X=X_train)    
    
fh = ForecastingHorizon(np.array([2, 5], dtype="int64"))    
y_pred = ardl.predict(fh=fh, X=X_test)    
    
print(y_pred)

@EmanAbdelhaleem, sorry, can you be precise what you exactly tested with what? You keep saying "I have tested fh= sth sth etc", but in which context did you test it, and where, and for what?

@EmanAbdelhaleem, sorry, can you be precise what you exactly tested with what? You keep saying "I have tested fh= sth sth etc", but in which context did you test it, and where, and for what?

Just a normal case like the above code I provided, this is what I mean by I tested, I initialize a model, fit it, then try to predict with various fh values.

For what?
I have removed try,except from is_contiguous() function, and tried to cover every single case with if conditions
One of them was what if we have fh = one integer value, like fh=3, so I started checking with examples, when would it work and when it would not, I noticed a different bahviour with different error messages, so I investigated more.

Sorry to ask again, I have difficulties following you.

Can you please be very precise under which conditions you tested what, and what is failing?

Sorry to ask again, I have difficulties following you.

Can you please be very precise under which conditions you tested what, and what is failing?

Setup:

• Model: ARDL(lags=2, order={"GNPDEFL": 1, "GNP": 2}, trend="c")
• Data: Longley dataset, split with last 5 observations as test set (X_test has 5 rows)
• Training data: 11 observations (indices 0-10)

from sktime.datasets import load_longley    
from sktime.forecasting.ardl import ARDL    
from sktime.forecasting.base import ForecastingHorizon    
from sktime.split import temporal_train_test_split  
import numpy as np
  
# Load data with exogenous variables    
y, X = load_longley()    
    
# Split into train and test using temporal_train_test_split  
y_train, y_test, X_train, X_test = temporal_train_test_split(y, X, test_size=5)  

# Select specific exogenous variables    
X_train = X_train[["GNPDEFL", "GNP"]]    
X_test = X_test[["GNPDEFL", "GNP"]]    
# Create ARDL model with lags and order for exogenous variables    
ardl = ARDL(lags=2, order={"GNPDEFL": 1, "GNP": 2}, trend="c")    
    
# Fit the model    
ardl.fit(y=y_train, X=X_train)    
    
fh = ForecastingHorizon(np.array([2, 5], dtype="int64"))    
y_pred = ardl.predict(fh=fh, X=X_test)    
    
print(y_pred)

Test Results:

Testing single-element horizons:

• ForecastingHorizon(1) → ✓ Works
• ForecastingHorizon(2) → ✓ Works
• ForecastingHorizon(3) → ✗ FAILS with IndexError: index -2 is out of bounds for axis 0 with size 1
• ForecastingHorizon(4) → ✗ FAILS with IndexError: index -3 is out of bounds for axis 0 with size 1
• ForecastingHorizon(5) → ✗ FAILS with IndexError: index -4 is out of bounds for axis 0 with size 1

Testing multi-element horizons:

• ForecastingHorizon([1,2,3]) → ✓ Works
• ForecastingHorizon([3,4]) → ✓ Works
• ForecastingHorizon([3,5]) → ✓ Works
• ForecastingHorizon([2,5]) → ✓ Works
• ForecastingHorizon([4,5]) → ✗ FAILS with IndexError: index -3 is out of bounds for axis 0 with size 2
• ForecastingHorizon([1,2,3,4,5]) → ✓ Works
• ForecastingHorizon([1,4,5]) → ✓ Works
• ForecastingHorizon([1,3,5]) → ✓ Works
• ForecastingHorizon([3,4,5]) → ✓ Works

Initial Confusion:

I initially thought the issue was about non-contiguous horizons (e.g., [3] skipping 1 and 2). However, [3,5] works despite skipping 1, 2, and 4, Even [2,5] works, which was weird cuz that was the failed test case in #8787

Given that, the first hypothesis that the issue is about non-contiguous horizons is contradicted, hence, declined.

I've conducted an investigation into this behavior by examining the ARDL implementation in both sktime.forecasting.ardl and statsforecast.models. You can find some details in my following submitted issue: https://github.com/statsmodels/statsmodels/issues/9699#issue-3665426646

The key finding is that the contiguous nature of predictions is not determined by whether the forecasting horizon is contiguous or non-contiguous. Instead, the start and end parameter values exclusively control this behavior. Additionally, I identified differences in how start and end defaults are handled between statsforecast.models and the sktime wrapper, which may warrant further examination.

After ruling out the non-contiguous horizon hypothesis, and knowing that the error I got from reproducing the exact failing test from #8787 was:

ValueError: exog_oos must have at least 5 observations to produce 5 forecasts based on the model specification.

I checked the X_test data being passed to the forecasters and discovered the problem: when using fh=[2, 5], X_test only contains 2 rows (for steps 2 and 5), but the forecasters need all 5 rows (steps 1 through 5).

Why This Happens:

The test uses:

y_train, _, X_train, X_test = temporal_train_test_split(y, X, fh=fh)

When fh is passed (instead of test_size), temporal_train_test_split uses ForecastingHorizonSplitter, which has this documented behavior in sktime/split/fh.py:

"Users should note that, for non-contiguous forecasting horizons, the union of training and test sets will not cover the entire time series."

So with fh=[2, 5], it only returns data for those specific indices, creating gaps. The forecasters need contiguous X data covering all steps from 1 to 5, but they're only receiving 2 rows.

Summary:

The test fails because it's passing incomplete X_test data to forecasters that require contiguous exogenous variables.

I used some LLM help to make the text clearer, but if anything is still unclear, please point out the exact part or tell me how you would test it, and I’ll follow your steps. I realize I may be using the wrong terms as it's my first PR, my apologies for that.

I see, thanks.

So we are probably dealing with two problems:

• the "non-contiguous" issue, which I think is valid as a contribution and a fix
• additional bugs in estimators if the horizon is not contiguous, where probably the internal translation of fh to the actial indices is not properly implemented

I would do as follows:

• add the non-contiguous tag (capability not there) at least for the estimator where some non-contiguous fh fail
• open issues for estimators where you suspect there is an additional bug, e.g., some non-contiguous fh work and so do not

@fkiraly I have made some changes. Kindly, review them.
May I ask why removing capability?

May I ask why removing capability?

Sorry, can you explain what you mean?

May I ask why removing capability?

Sorry, can you explain what you mean?

@fkiraly Never mind. I think I misunderstood things, I thought you meant to remove capability from the tag name when you said "add the non-contiguous tag (capability not there)".

I see that there was a trailing whitespace and you already added a commit to remove it. We can run the checks again, right?
Sorry for the messy errors. I have pip installed pre-commit after committing my changes. I also work on a windows environment, so I kept having pre-commit modifications for all the repo files due to LF/CRLF. That's why I had to run pre-commit for each file separately and maybe I missed the statsforcast.py file.

Wow, this is my first merged PR, very happy for it. Thank you so much for the review and guidance Dr. @fkiraly !