Skip to content

slides.md

Latest commit

 

History

History
273 lines (170 loc) · 4.64 KB

slides.md

File metadata and controls

273 lines (170 loc) · 4.64 KB
marp true
_class invert
paginate true
backgroundColor
color
theme default
footer Posthoc @ ICAPS 2025
<style> @import "base"; @import url("https://fonts.googleapis.com/css2?family=Inter&display=swap"); :root { font-size: 22px; font-family: "Inter", sans-serif; --color-fg-default: white; --color-canvas-default: white; padding: 64px; } footer, header { padding: 32px 32px; } h1 > strong { color: #f1f1f1; } </style>

Posthoc @ ICAPS 2025

  1. Set the scene (5 minutes)
  2. The Posthoc project (5 minutes)
  3. Live demos (5 minutes)
  4. What's next (5 minutes)

bg right:50% 50%

Find the slides here

https://pathfinding.ai/posthoc-icaps25/

bg right:100% 80%

bg right:100% 60%

bg top:100% 60%

"Spontaneous brilliance"

Visualisation for search

bg right:60%

InLPG Link

(Gereveni and Saetti, 2008)

bg right:60%

Web Planner Link

(Magnaguagno et al., 2017)

MovingAI Lab Demos Link

(Sturtevant, 2020)

bg right:65% 100%

MAES Link

(Andreason et al., 2022)

bg right:70% 100%

How about visualisations for my algorithm?

Search problems and algorithms come in all shapes and sizes.

  • Various domains
  • Various algorithms and procedures
  • Different programming languages
  • We want to see different things

PlanViz Link (Chan et al., 2024)

bg right:50% 100%

Existing problem solving methods we see

  • Use one of the visualisers
  • Logs
  • Debuggers
  • DIY from scratch
  • Trial and error
  • Matplotlib hacks
  • Just think harder

bg right:60%

bg right:60%

What can we do incorporate visualisation into everyday problem solving?

  • Framework that makes a minimal set of powerful assumptions
  • Way to record program behaviour
  • Way to quickly DIY visualisations

Also

  • Language agnostic

The Posthoc project

bg right:60%


https://posthoc.pathfinding.ai/

width:140px

Setting expectations

  • Simple but effective visualisations
  • Not trying to replace any tools

Two parts

  • Search trace format
  • Posthoc visualiser

bg right:60%

1. Search trace

  • Textual recording of your algorithmic procedure
  • Optional description of the visualisation model

Why YAML?

  • Standing on shoulder of giant
  • Super easy to read and write (for people and programs)

bg right:50% 60%

Producing search traces

  • Just print() / cout << / System.out.println()
  • Solvers can generate them e.g. --log
  • Write small examples by hand

bg right:60% 90%

2. Posthoc visualiser

  • Separate from the search trace
  • Toolbox/visualisation suite for search traces
  • Replay and interactive inspection
  • Tree and graph visualisations
  • Custom visualisations
  • Breakpoints for debugging,
  • etc.

bg right:40%

Live demo

  • Creating search traces
  • Posthoc quickstart
  • Tree and graph visualisations
  • How custom visualisations work
  • Playback and inspection

Follow along: https://pathfinding.ai/news/using-posthoc-with-piglet/

Posthoc: https://posthoc.pathfinding.ai/

What's next

Making search visualisations accessible

bg right:50%

Towards interoperable visualisations

@solver developers

  • Requires solver support
  • Let your algorithmic procedures be visualisable via search traces
  • Generate logs in the search trace format

@tools developers

  • Tools that take in the search trace for analysis

Making progress in search and planning discoverable

  • A place to store, share, and publish visualisations
  • Let the community discover your work

bg right:50%

The future for the Posthoc visualiser

  • Extension marketplace
  • Component libraries (higher-order components)
  • Renderers (3D, point cloud, splatting)
  • Direct solver/visualiser interactivity (automatically pull in search traces)
  • Many in-development and planned features
  • 34 open issues
  • Star us on GitHub: https://github.com/shortestpathlab/posthoc-app

bg right:40% 80%