x_inner_mtype#

x_inner_mtype()[source]#

The machine type(s) the transformer can deal with internally for X.

  • String name: "X_inner_mtype"

  • Extension developer tag

  • Values: str or list of string, from the list of mtype strings

  • Example: "pd.DataFrame"

  • Default: specific to estimator type, see extension template

Estimators in sktime support a variety of input data types, following one of many possible machine types, short: mtype specifications.

Internally, the estimator may support only a subset of these types, for instance due to the implementation of the estimator, or due to interfacing with external libraries that use a specific data format.

The sktime extension contracts allow the extender to specify the internal mtype support, in this case the methods the extender needs to implement guarantee that the arguments are of the correct type, by carrying out the necessary conversions and coercions.

For instance, an extender implementing _fit with an X argument and X_inner_mtype set to "pd.DataFrame" can assume that the X argument follows the pd.DataFrame mtype specification - while users can pass any supported mtype to the public fit method.

Tags named X_inner_mtype, y_inner_mtype, etc, apply this specification to the respective arguments in the method signature.

The four main patterns in using the “inner mtype” tag are as follows:

  • specifying a single string. In this case, internal methods will provide the extender with inputs in the specified machine type.

  • specifying a list of strings, of the same :mtype:`scitype`. In this case, the boilerplate layer will first attempt to find the first mtype in the list.

  • specifying a list of strings, all of different :mtype:`scitype`. This will convert the input to the mtype of the same scitype. This is especially useful if the implementer wants to deal with scitype broadcasting internally, in this case it is recommended to specify similar mtypes, such as "pd.DataFrame", "pd-multiindex", "pd_multiindex_hier, which allow dealing with the different types simultaneously.

  • specifying all possible mtypes, by setting the default to a list such as ALL_TIME_SERIES_MTYPES from the datatypes module. As all mtypes are supported, inputs will be passed through to _fit etc, without any conversion and coercion. This is useful for composites, where the extender wants to ensure that components should carry out the necessary conversions and coercions.

More generally, for an arbitrary list of mtypes, the boilerplate logic will:

  • first checks whether the mtype of the input is on the list. If yes, the input will be passed through as is.

  • if the mtype of the input is not on the list, the boilerplate will attempt to identify the first mtype of the same scitype as the input, and coerce to that.

  • if no mtype of same scitype is found, it will attempt to coerce to the “simplest” adjacent scitype, e.g., from "pd.DataFrame" to "pd-multiindex".

In all cases, ordering is important, as the first mtype in the list is the one that will be used as target type for conversions.

On this page