Add tabular learning methods

[manikyabard]

Adds the implementation of DLPipelines.jl LearningMethod interface for tabular regression and tabular classification tasks.

[lorenzoh]

Some notes on integration with the data block API

Ideally the table-specific data processing functionality would be encapsulated in an Encoding called TabularPreprocessing that works on a TableRow Block. If the target variable is separated from the row, we could then write the learning tasks as:

# tabular classification
BlockMethod(
    (TableRow(catcols, contcols), Label(classes)),
    (
        TabularPreprocessing(),  # only transforms `TableRow`
        OneHot(),  # only transforms `Label`
    )
)

# tabular regression
BlockMethod(
    (TableRow(catcols, contcols), Continuous(n)),
    (
        TabularPreprocessing(),  # only transforms `TableRow`
    )
)

This would require the following changes:

• instead of using data containers with observations row, separate out target variable such that one observation is (row, target)

• move preprocessing into an encoding TabularPreprocessing

• implement block TabularRow

  Block needs to hold information on which columns are categorical and continuous, so something like

  struct TabularRow <: Block
      catcols
      contcols
  end

• implement block Continuous for regression targets

[lorenzoh]

Why is this changed?

[manikyabard]

For the encodings for which decoding isn't supported yet, like TabularTransforms (I'll rename this to TabularPreprocessing), it will give incorrect results I think.
The encoded block after applying TabularTransforms on a TableRow is EncodedTableRow, and if decoding was supported, then the decoded block should be a TableRow again. But as it isn't supported, using the fill option would make it so that EncodedTableRow is returned again (instead of nothing through the fallback method) which wouldn't be correct.
The tests after this could fail because inblock (which would be the encoded block in this situation), doesn't have to be the same as the original block. Also I'm not sure if the if condition would ever be false as of now.

[lorenzoh]

Can we use this in a constructor for TabularTransform so you can call it like TabularTransform(TableDataset(...))?

[manikyabard]

Sure, so something like this?

TabularTransform(td::TableDataset) = TabularTransform(gettransforms(td))

[lorenzoh]

Changes look good 👍

[lorenzoh]

Anything else that is missing before this can be merged?

Only thing I can think of are simple BlockMethod wrappers like those in src/fasterai/learningmethods.jl? Each should have a constructor that takes just the blocks i.e. ::Tuple{<:TableRow, <:Continuous} and one convenience constructor. They can then be registered with some block types so you can find them using findlearningmethods(s. the same file for how).

[darsnack]

Some more small nitpicks

[manikyabard]

I think the tests are failing because the model PR isn't merged yet.

[darsnack]

Is there a reason that decode(::Encoding, ::Block) defaults to nothing (same for encode)? I get that it allows us to distinguish between when a block is modified but happens to be the same type vs. when it is not affected by Encoding. But is there value in tracking that information? Could we just default to an identity map like

encodedblock(::Encoding, block::Block) = block
decodedblock(::Encoding, block::Block) = block

This seems intuitive to me. Unless we use the nothing information later in the pipeline.

[lorenzoh]

Is there a reason that decode(::Encoding, ::Block) defaults to nothing (same for encode)? I get that it allows us to distinguish between when a block is modified but happens to be the same type vs. when it is not affected by Encoding. But is there value in tracking that information? Could we just default to an identity map like

encodedblock(::Encoding, block::Block) = block
decodedblock(::Encoding, block::Block) = block

This seems intuitive to me. Unless we use the nothing information later in the pipeline.

That's the only way to know that data was not changed without running the encoding. encode and decode themselves do have an identity as the default, encodedblock and decodedblock just handle the block info.

[lorenzoh]

This looks good.

Are the tests failing due to the issue with the decoding not being implemented? In that case, we could add a definition for justdecodedblock without implementing decode. Or add a decode = true kwarg to testencoding so that it only does the decoding tests if decode == true.

[manikyabard]

This looks good.

Are the tests failing due to the issue with the decoding not being implemented? In that case, we could add a definition for justdecodedblock without implementing decode. Or add a decode = true kwarg to testencoding so that it only does the decoding tests if decode == true.

I think the tests might be failing because methodmodel is being tested as well and the model code isn't present in this branch yet.

[lorenzoh]

maybe some minor doc improvements could still be made, but let's do that in another PR that also integrates the notebook with the documentation. We still have time for that before the next release.