Skip to content

Inductive Miner Completion Tracker #55

Description

@aarkue

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.

  • concurrency / AND cut detection: cut_finder/concurrent.rs
  • loop cut detection: cut_finder/loop_cut.rs
  • xor split: splits/exclusive_choice.rs
  • sequence split: splits/sequence.rs
  • loop split: splits/redo_loop.rs

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.

  • We use a standard sequence cut; PM4Py and ProM use the strict one. Decide what the
    default should be and wire up the StrictSequenceCut parameter.
  • Concurrency gets detected later than in PM4Py/ProM. Still unclear why; could be the
    fold step, the split, or minimum self distance.
  • Set up something to actually diff our trees against PM4Py/ProM on a few logs instead
    of eyeballing it.
  • generate_default_parameters says 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

  • Re-export the entry point at the crate level and settle on naming.
  • Let callers pass their own Parameters, not just the defaults.
  • Figure out which types should be public (Cut, Split, Parameter).
  • An example or integration test would be nice.

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).

  • Switch to the activity projection instead of raw EventLog + classifier.
  • Stop cloning the whole log per split; work by reference.
  • Derive the sub-DFG instead of rediscovering it every level.
  • The recursive calls are independent, so the subtree mining could run in parallel
    (there's already a // this could be done in parallel note in the code).
  • Add a benchmark so we can tell if any of this helps.

Later

  • IMf (the infrequent variant with noise filtering); right now it's only basic IM.
  • Check the output plugs cleanly into the process-tree -> Petri net conversion from Added functionality to translate a process tree into a Petri net #48.
  • Swap the panic!/unwrap in build_tree for proper errors where it makes sense.
  • Clean up the commented-out parameter ideas.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions