Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

transform and trainer namespaces don't need to follow the catalogs #2755

Merged
merged 4 commits into from
Feb 27, 2019

Conversation

sfilipi
Copy link
Member

@sfilipi sfilipi commented Feb 27, 2019

Microsoft.Ml.Transforms.Normalizers
Microsoft.Ml.Transforms.Categoricals
Microsoft.Ml.Transforms.Conversions
Microsoft.Ml.Transforms.Projections

into Microsoft.Ml.Transforms

Microsoft.ML.Trainers.KMeans
Microsoft.ML.Trainers.PCA
Microsoft.ML.Trainers.OnlineLearners
Microsoft.ML.Trainers.FactorizationMachine

into Microsoft.ML.Trainers

Addresses #2751.

@sfilipi sfilipi self-assigned this Feb 27, 2019
@sfilipi sfilipi added the API Issues pertaining the friendly API label Feb 27, 2019
@@ -17,6 +17,7 @@
using Microsoft.ML.Internal.Utilities;
using Microsoft.ML.Model;
using Microsoft.ML.Trainers.FastTree;
using Microsoft.ML.Transforms;
Copy link
Contributor

@TomFinley TomFinley Feb 27, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Transforms [](start = 19, length = 10)

I'm seeing a surprising number of these introductions. I don't object, but I am fairly curious what changed that they were no longer necessary in the past but are necessary now. Things like using Microsoft.ML.Transforms.Projections; changing to using Microsoft.ML.Transforms; makes total sense to me, but what happened that a totally novel using became necessary?

This is not an urgent question to be clear. Just idly curious, something to answer in your copious spare time. ;) #Pending

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! It is due to FeatureContributionCalculatingTransformer moving from Microsoft.ML.Data into Microsoft.ML.Transforms.

Ml.Data was already there.


In reply to: 260841129 [](ancestors = 260841129)

@@ -13,13 +13,13 @@
using Microsoft.ML.Model;
using Microsoft.ML.Model.OnnxConverter;
using Microsoft.ML.Numeric;
using Microsoft.ML.Trainers.KMeans;
using Microsoft.ML.Trainers;
using Float = System.Single;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugh. One of you and @jwood803 are going to make each other very unhappy with the rebase conflicts. :D

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't mind doing the merge on my pull request. :)

@sfilipi sfilipi changed the title transform namespaces don't need to follow the catalogs transform and trainer namespaces don't need to follow the catalogs Feb 27, 2019
@@ -64,7 +64,7 @@
<remarks>
<para>
This transform uses a set of aggregators to count the number of non-default values for each slot and
instantiates a <see cref="SlotsDroppingTransformer"/> to actually drop the slots.
instantiates a <see cref="T:Microsoft.ML.Transforms.SlotsDroppingTransformer"/> to actually drop the slots.
Copy link
Contributor

@TomFinley TomFinley Feb 27, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Microsoft.ML.Transforms [](start = 38, length = 23)

Similar question, not sure why this suddenly became necessary when previously it was not. Or did we only just realize it was necessary? Totally fine, consistent with everythign else I see here, just a little odd. #Pending

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was not necessary; spotted the difference when changed the namespaces below, and i guess my OCD took over :)


In reply to: 260843071 [](ancestors = 260843071)

Copy link
Contributor

@TomFinley TomFinley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good @sfilipi thanks for doing this! Note that your EntryPointCatalog test is failing -- you've changed the namespaces of many key transforms, which will likewise change the fully qualified names that appear in the catalog, so you'll have to regenerate that. But probably you've already determined this. Otherwise looks good, thank you again.

@@ -22,7 +22,7 @@

[assembly: LoadableClass(typeof(void), typeof(FeatureContributionEntryPoint), null, typeof(SignatureEntryPointModule), FeatureContributionCalculatingTransformer.LoaderSignature)]

namespace Microsoft.ML.Data
namespace Microsoft.ML.Transforms
Copy link
Member Author

@sfilipi sfilipi Feb 27, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note, this is the only class that moved from ML.Data ->ML.Transforms.

Everythign else was a sub-namespace of ML.Transforms or ML.Trainers #WontFix

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh geez. That's good that you caught it!

Copy link
Contributor

@Ivanidzo4ka Ivanidzo4ka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

Microsoft.Ml.Transforms.Normalizers
Microsoft.Ml.Transforms.Categoricals
Microsoft.Ml.Transforms.Conversions
Microsoft.Ml.Transforms.Projections

into Microsoft.Ml.Transforms
Microsoft.ML.Trainers.KMeans
Microsoft.ML.Trainers.PCA
Microsoft.ML.Trainers.OnlineLearners
Microsoft.ML.Trainers.FactorizationMachine

into Microsoft.ML.Trainers
@sfilipi sfilipi merged commit b0baf12 into dotnet:master Feb 27, 2019
@sfilipi sfilipi deleted the trainerTransformNamespaces branch February 27, 2019 18:02
@codecov
Copy link

codecov bot commented Feb 27, 2019

Codecov Report

Merging #2755 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master    #2755   +/-   ##
=======================================
  Coverage   71.65%   71.65%           
=======================================
  Files         807      807           
  Lines      142337   142337           
  Branches    16117    16117           
=======================================
  Hits       101986   101986           
+ Misses      35916    35915    -1     
- Partials     4435     4436    +1
Flag Coverage Δ
#Debug 71.65% <100%> (ø) ⬆️
#production 67.9% <ø> (ø) ⬆️
#test 85.83% <100%> (ø) ⬆️
Impacted Files Coverage Δ
src/Microsoft.ML.StaticPipe/OnlineLearnerStatic.cs 49.36% <ø> (ø) ⬆️
...L.Transforms/Text/WordHashBagProducingTransform.cs 51.7% <ø> (ø) ⬆️
...Microsoft.ML.Tests/Transformers/NormalizerTests.cs 100% <ø> (ø) ⬆️
...dLearners/Standard/Online/OnlineGradientDescent.cs 91.3% <ø> (ø) ⬆️
...t.ML.Transforms/MissingValueHandlingTransformer.cs 60.37% <ø> (ø) ⬆️
src/Microsoft.ML.PCA/PcaTrainer.cs 79.64% <ø> (ø) ⬆️
src/Microsoft.ML.FastTree/GamModelParameters.cs 46.51% <ø> (ø) ⬆️
test/Microsoft.ML.Tests/Transformers/RffTests.cs 100% <ø> (ø) ⬆️
...t.ML.Data/Transforms/ValueToKeyMappingEstimator.cs 87.03% <ø> (ø) ⬆️
...crosoft.ML.Transforms/EntryPoints/TextAnalytics.cs 41.25% <ø> (ø) ⬆️
... and 115 more

@ghost ghost locked as resolved and limited conversation to collaborators Mar 24, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
API Issues pertaining the friendly API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants