Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
M
ML_Operator_Decision
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Package registry
Container registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
EYHORN Konstantin
ML_Operator_Decision
Commits
31b5f944
Commit
31b5f944
authored
1 year ago
by
Konstantin Gerd Eyhorn
Browse files
Options
Downloads
Plain Diff
Merge branch 'master' of gitlab.imt-atlantique.fr:k24eyhor/ml_operator_decision
parents
f338eb3e
314a5b8c
Branches
Branches containing commit
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
README.md
+23
-0
23 additions, 0 deletions
README.md
with
23 additions
and
0 deletions
README.md
+
23
−
0
View file @
31b5f944
# ML Project - Operator Decision
# ML Project - Operator Decision
## 1st Meeting
TODO:
-
Read data
-
Read report from student
-
Reproduce the MLP model on our own
-
Check the statistical model (methods used for the first classification) -> see paper
-
Check other paper for methods for false alarm detection (See project proposal)
Additional notes:
-
we use features calculated from data rather than fill data with 0 when we have different resolutions (better performance)
-
option for later: add own features
-
database: only alarms -> classified as good/bad
-
data unit: the full profile -> reject/accept the whole profile as bad/good
-
use Pytorch
-
Meeting One day/week -> 16h friday 12.04
-
problem with database : not large
-
careful by splitting -> require class balance (reduces number of data used)
-
depending on splitting -> different performance
-
solutions: replicate database, class balance (but for now just implement it like this)
-
historical data -> from boyes; what about the other datasets ?
-
in-situ -> field study
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment