Inductive Miner Completion Tracker
This issue tracks the remaining todos for the inductive miner (branch feat/inductive-miner by @KuKuhlkrypto merged from #47).
The goal is to distribute and work on the different parts, then merge them into feat/inductive-miner to step-by-step complete everything.
Background: The basic IM (process-tree output) is in and most cuts/fallthroughs work, but there are a few empty todo!()s / stubs. Those are the priority.
What then remains is maybe switching to a more efficient backing data structure (e.g., maybe use EventLogActivityProjection or a generic trait?
Also: Some more cleanup, and making it actually usable from outside the crate.
Closing the Gaps/Stubs
These five are todo!() right now. They each already have a doc comment and a test module,
so the unit tests are red until they're done. They need to be written fresh from the paper
(Leemans, ch. 6.1) and the existing tests rather than copied from anywhere.
Check with PM4Py / ProM output
Generally there might be a few things that can be done in different ways, we do not have to necessary have 100% equality on all logs, but it's good to check and be aware of any differences.
Make it usable from outside
Architecture and performance
The current code takes the EventLog by value, clones it at every split, and rebuilds the
DFG from scratch at each recursion step. alphappp uses EventLogActivityProjection
(activities referred to by usize) for this kind of thing.
Either switch to that one as well or design a new trait etc. around that (maybe the better choice long-term).
Later
Inductive Miner Completion Tracker
This issue tracks the remaining todos for the inductive miner (branch
feat/inductive-minerby @KuKuhlkrypto merged from #47).The goal is to distribute and work on the different parts, then merge them into
feat/inductive-minerto step-by-step complete everything.Background: The basic IM (process-tree output) is in and most cuts/fallthroughs work, but there are a few empty
todo!()s / stubs. Those are the priority.What then remains is maybe switching to a more efficient backing data structure (e.g., maybe use EventLogActivityProjection or a generic trait?
Also: Some more cleanup, and making it actually usable from outside the crate.
Closing the Gaps/Stubs
These five are
todo!()right now. They each already have a doc comment and a test module,so the unit tests are red until they're done. They need to be written fresh from the paper
(Leemans, ch. 6.1) and the existing tests rather than copied from anywhere.
cut_finder/concurrent.rscut_finder/loop_cut.rssplits/exclusive_choice.rssplits/sequence.rssplits/redo_loop.rsCheck with PM4Py / ProM output
Generally there might be a few things that can be done in different ways, we do not have to necessary have 100% equality on all logs, but it's good to check and be aware of any differences.
default should be and wire up the
StrictSequenceCutparameter.fold step, the split, or minimum self distance.
of eyeballing it.
generate_default_parameterssays it uses strict sequence + fold + MSD in its doc,but only sets MSD and fallthroughs. One of the two is wrong.
Make it usable from outside
Parameters, not just the defaults.Cut,Split,Parameter).Architecture and performance
The current code takes the
EventLogby value, clones it at every split, and rebuilds theDFG from scratch at each recursion step.
alphapppusesEventLogActivityProjection(activities referred to by
usize) for this kind of thing.Either switch to that one as well or design a new trait etc. around that (maybe the better choice long-term).
EventLog+ classifier.(there's already a
// this could be done in parallelnote in the code).Later
panic!/unwrapinbuild_treefor proper errors where it makes sense.