Added an extension method for saving statically typed model (#1286)

[llRandom]

Added an extension method for saving statically typed model
Fixes #1286

[dnfclas]

All CLA requirements met.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@0a2ec3a). Click here to learn what that means.
The diff coverage is 42.85%.

@@            Coverage Diff            @@
##             master    #2924   +/-   ##
=========================================
  Coverage          ?   72.53%           
=========================================
  Files             ?      809           
  Lines             ?   144746           
  Branches          ?    16204           
=========================================
  Hits              ?   104987           
  Misses            ?    35347           
  Partials          ?     4412

Flag	Coverage Δ
#Debug	72.53% <42.85%> (?)
#production	68.12% <33.33%> (?)
#test	88.82% <100%> (?)

Impacted Files	Coverage Δ
...s/Scenarios/Api/CookbookSamples/CookbookSamples.cs	99.49% <100%> (ø)
....ML.StaticPipe/ModelOperationsCatalogExtensions.cs	33.33% <33.33%> (ø)

[TomFinley]

Hi @llRandom thanks for the PR!

In #2735 we expressed a change in this API that they should accept not only the model, but also some description of the inputs to that model (so as to make certain information discoverable). In the base so-called "dynamic" API, this descriptor takes the form of either:

• DataViewSchema (whose static analogue is imperfect, but we might accept as being some subclass of SchemaBearing<TShape>,
• IDataLoader<...> whose static analogue is DataLoader<TIn, TShape> (note that this happens to descend from SchemaBearing<TShape>, but due to the way overload resolution works that should be fine).

Note also the new presence of overloads for taking file paths and not just streams, for convenience sake.

Note the APIs were removed altogether and put into their final form in #3044, so I might think this code may not build at this time.

[TomFinley]

ModelOperationsCatalog [](start = 24, length = 22)

It may be preferable if the static class containing the extension methods for this did not have the same name as the type they're operating on, that is ModelOperationsCatalogExtensions or suchlike may be preferable.

[llRandom]

fixed

[TomFinley]

ModelOperationsCatalog catalog [](start = 75, length = 30)

This is an interesting question I'm not sure I know the answer to. The experimental "static" API predates the concept of the MLContext, and solved the problem MLContext seeks to solve -- that of discoverability, and (at a lower level) propagation of the IHostEnvironment, in a rather entirely different way -- that is, you apply estimators and transformers in static-pipe land through discoverability on the input data to those estimators and transformers -- that is, intellisense on the columns.

Dynamic pipe land can't do that -- there is no (and kind of cannot be) concept of a column as "separate object" in dynamic-pipe land. So we achieve discoverability of relevant instantiable components via the taxonomy as originally proposed in #1098.

Here we're, AFAIK for the first time, mixing the two metaphors. This may be appropriate. Indeed I think we might shift the static API to use more of these idioms (which, again, predates MLContext altogether during the period we were engineering its core principles).

Not asking you to answer that question, just registering my thoughts since this change brought it to my mind, if we continue to iterate on the static pipe...

[llRandom]

Are there any other changes needed for this PR?

[eerhardt]

Are there any other changes needed for this PR?

@TomFinley - were all of your comments addressed?

[eerhardt]

The static API has been removed. Closing as this PR is no longer necessary.