Adding the MlNetMklDeps package, adding the entry point, tests and docs for OLS. #578
Conversation
| @@ -0,0 +1,5 @@ | |||
| <Project DefaultTargets="Pack"> | |||
|
|
|||
| <Import Project="Microsoft.ML.Parquet.nupkgproj" /> | |||
There was a problem hiding this comment.
Parquet [](start = 32, length = 7)
nope #Resolved
|
Have you tested MKL works as expected? #Resolved |
| </PropertyGroup> | ||
|
|
||
| <ItemGroup> | ||
| <ProjectReference Include="../Microsoft.ML/Microsoft.ML.nupkgproj" /> |
There was a problem hiding this comment.
Can we write down how exactly it's gonna work?
How it looks in my head based on conversations (can be far away from reality)
- Have a internal repo with pre build custom dlls for each OS.
- Publish them to nuget.org
- Reference them in Microsoft.ML nuget as dependency
this steps have nothing to do with this package file, so I obviously don't understand something.
#Resolved
build/Dependencies.props
Outdated
| @@ -8,5 +8,6 @@ | |||
| <SystemReflectionEmitLightweightPackageVersion>4.3.0</SystemReflectionEmitLightweightPackageVersion> | |||
| <PublishSymbolsPackageVersion>1.0.0-beta-62824-02</PublishSymbolsPackageVersion> | |||
| <LightGBMPackageVersion>2.1.2.2</LightGBMPackageVersion> | |||
| <MlNetMklDepsPackageVersion>0.0.0.1</MlNetMklDepsPackageVersion> | |||
There was a problem hiding this comment.
[](start = 0, length = 1)
ze evil tabs! #Resolved
|
Hi @sfilipi thanks for getting this started. I see we have a package definition added, I think. But I might have expected the package definition to live somewhere else in a different repository somehow (since it cannot be part of the build here), and for components in ML.Net that need it to simply reference that externally defined nuget. Is that unfair? I also feel like I might understand this better if we saw how existing component (like OLS) or upcoming ones (like #556) will actually consume this. #Resolved |
|
Hi @[email protected] ,I have tested MKL binaries by linking them with native SymSGD code in PR556 (that iteration is not posted yet) using CMAKE. The way we would do is by restoring MKL nuget before CMAKE is called by adding an external project to the sln file that package references MKL nuget, this step fetches the binaries to a known location on the drive and then we can link against the binaries in our CMAKE file. Line 23 in 8cfa2ed In reply to: 407535938 [](ancestors = 407535938) |
Adding Mkl dependency to the StandartLearners project Enabling the Ols tests, adding its EntryPoint, and documentation.
| </remarks> | ||
| <example> | ||
| <code language="csharp"> | ||
| new StochasticDualCoordinateAscentRegressor |
There was a problem hiding this comment.
new StochasticDualCoordinateAscentRegressor [](start = 9, length = 44)
I'll fix this. #Resolved
…ureEntryPointModule so that the OLS EntryPoint is visible to the Module Catalog. Updating the CSharpApi and the ep-list and manifest. Fixing the test in the documentation
sfilipi
changed the title
…ual prediction is outside of the calculated range. since we have seen quite a bit of those, set a minimum threeshold, and ignore fluctuations after the 5th decimal point.
|
The changes went in through the other PR. |
ghost
locked as resolved and limited conversation to collaborators
MKL package has been published