Closed codemzs closed 5 years ago
It seems like the core concepts of the API (IEstimator
/ITransformer
/IDataReader
) should live in Microsoft.ML
. I'd argue VBuffer
as a core data type should also live there, since vector valued columns are very important. MultiFileSource should live in same namespace as whatever IDataReader
winds up living in. That probably means Microsoft.ML.
IRowReadableAs and TypedCursorable are internal. So is ICursorable almost certainly could be internal. CursorUtils, like any utils, should be internal. Same with Role mapped data, and role mapped schema. Indeed it might be helpful when composing lists to check what things are already internal.
ColumnCursorExtensions is a fairly poor API that should be reviewed, but in principle if properly designed I'd probably, as an auxiliary method, put it in Microsoft.ML.Data
.
Regarding specific transformers, I have no idea what "Make a catalog entry in ML namespace?" means. But I'm not sure whether this should be Microsoft.ML
, Microsoft.ML.Data
, or Microsoft.ML.Transformers
, or something else altogether.
Note: to keep this helpful, might be nice if you could group the list, since obviously it is not scalable for you to list every individual class, and have someone have to tell you what to do with it. Instead maybe try to propose a general policy, some sort of set of rules that are consistent.
@sfilipi Do we care about this anymore?
I believe this has been addressed from the other angles, of checking the namespaces directly to see what types they expose.
I'd just skim over the user facing samples, like the cookbook, Microsoft.ML.Samples and the Microsoft.ML.FunctionalTests before closing it.
As part of the grand rename of namespaces, let's finalize the set of namespaces of public-facing components.
CC: @TomFinley