I think you meant #5886 instead of #5962, so edited PR header accordingly. Please revert if that's not the case.

I think you meant #5886 instead of #5962, so edited PR header accordingly.

Yes, of course, my bad - thanks.

hm, that's quite a lot of failures - should we deal with this via tags, @yarnabrina?
Not sure how to tag, one perhaps for input and one for output?

Before I say anything, can you please help me understand what do these failures mean?

I am guessing that the failures come from the fact that some (majority I guess, if not all) forecasters do not support categorical features directly and will need some encoding (label - can't use, so one-hot?) transformation earlier. Is that it, or is there something else as well?

I am guessing that the failures come from the fact that some (majority I guess, if not all) forecasters do not support categorical features directly and will need some encoding (label - can't use, so one-hot?) transformation earlier. Is that it, or is there something else as well?

I am guessing the same, but I'm also not sure.

My understanding of the failures:

• most actually come from "within" the estimtator. That is, nothing in the boilerplate layer prevents the data from being passed to _fit etc anymore.
• they failures look very distinct, hey look like specific to individual estimators

So yes, earlier transformation could prevent the failures, the main issue for me is that it doesn't juts fail, but fails with uninformative error.

We can try to create a new boolean tag, say support-categorical-features and set it as False by default. For different subclasses, e.g. reduction ones may override these as True, as XGBoost, CatBoost, etc. can accept categorical columns directly, though they may need specification of special arguments during __init__. We can check the value for this tag in base class, and fail quickly if the requirement is not satisfied.

What I do not like is depending on previous transformations any forecaster may actually be okay, becuase what is being passed at the end will not be numeric. I don't know if that can be detected or not. We can try to set this categorical support tag separately for input/output of a transformer, but don't know how these will work for non-sktime transformers (which are sklearn-compatible and used with TabularToSeriesAdaptor).

What I do not like is depending on previous transformations any forecaster may actually be okay, becuase what is being passed at the end will not be numeric.

Can you give an example?

earlier transformation could prevent the failure

Meant this case, e.g. something like this from #5867 (comment):

pipeline = (ColumnSelect(columns=["Q"]) * OneHotEncoder()) ** (StandardScaler() * ARIMA())

(Plus output conversion tag change that you suggested in this case)

yes, but that would work, no? The pipeline has the tag set to "supports", so nothing should break?

yes, but that would work, no? The pipeline has the tag set to "supports", so nothing should break?

I'm confused, how will pipeline has "caregorical support" tag as True?

By default, ARIMA has False. We can only change tgat value for pipeline to True if there is a transformation on all categorical column(s) to make them numerical. How shall we detect these?

1. There's at least a transformation in the pipeline that can take categorical and convert to numerical (my doubt: we can't know behaviour of OneHotEncoder etc. with tags)
2. Such transformations are applied on all categorical columns (my doubt: do we store each columns and their types and what all columns are being transformed)

I'm confused, how will pipeline has "caregorical support" tag as True?

We'd just set it to True regardless, in the class.

So it would be wrong in some instances, e.g., sklearn components where we cannot detect, but the user will still receive an informative error message, namely where it first hits an sktime input check.