Default schema

[tlienart]

Having something like

function MLJBase.fit(model, verb, X, y)
    features = MLJBase.schema(X).names
    ...
end

will fail if, for instance, X is just a matrix. It seems that the right thing to do would be to give the default (:x1, :x2, ...) as DataFrame does?

(happy to PR if relevant)

[ablaom]

So you are requesting that we overload MLJBase.schema (a re-export of Tables.schema, if I recall) to work on matrices?

The Tables.jl people are quite insistent that matrices are not tables (and now provide a way to convert matrices to tables). While I don't see any particular harm in overloading schema, I wonder what your use case is. At present, no model accepts matrix input - only tabular (in the sense of Tables.jl) input. If there is a call to have models that accept matrix input, what would be the need to extract schema? Or are you suggesting all models that accept tabular input should also accept matrix input? Although there is a small performance cost, it is simpler to stick with tables, I think. (Or, many moons ago, we should have decided only matrix input was allowed : - ) )

[ablaom]

Another reason I generally don't like the implicit labelling (:x1, :x2, ...) is that it can have unintended consequences later on. For example, when two such objects are combined and we get a name clash. Currently we do this in our dimension reduction algorithms (invent labels for the output) and I've been wondering if it might be better to output a matrix and have the user explicitly provide the labels (which she can do with MLJ.table).

[tlienart]

I think these are all good reasons and so we can shelf this issue.

Maybe to explain where this question came from, I can imagine users new to MLJ and willing to give it a quick shot broadly wanting to do:

1. generate random X, y (matrix/vector)
2. wanting to quickly try to do a regression
3. getting bitten

and possibly being annoyed as a result.

Of course this goes away if we have clear examples of how to do exactly that, that don't require immediately understanding learning networks etc.

Edit: possibly in the future what could help is to provide (more) helpful warning or error messages of the form "did you mean ..."