\section{Introduction} The Coq Proof
Assistant~\cite{the_coq_development_team_2019} is an Interactive Theorem Prover
in which one proves lemmas using tactic scripts. Individual tactics in these
scripts represent actions that transform the proof state of the lemma currently
being proved. A wide range of tactics exist, with a wide range of
sophistication. Basic tactics such as \texttt{apply \textit{lem}} and
\texttt{rewrite \textit{lem}} use an existing lemma \textit{lem} to perform one
specific inference or rewriting step while tactics like \verb|ring| and
\verb|tauto| implement entire decision procedures that are guaranteed to succeed
within specific domains. Finally, open-ended search procedures are implemented
by tactics like \verb|auto| and \verb|firstorder|. They can be used in almost
every domain but usually only work on simple proof states or need to be
calibrated carefully. Users are also encouraged to define new tactics that
represent basic steps, decision procedures, or specialized search procedures
within their specific mathematical domain.

When proving a lemma, the user's challenge is to observe the current proof state
and select the appropriate tactic and its arguments to be used. Often the user
makes this decision based on experience with previous proofs. If the current
proof state is similar to a previously encountered situation, then one can
expect that an effective tactic in that situation might also be effective now.
Hence, the user is continuously matching patterns of proof states in their mind
and selects the correct tactic based on these matches.

That is not the only task the user performs, however. When working on a
mathematical development, the user generally has two roles: (1) As a {\em
  strategist}, the user comes up with appropriate lemmas and sometimes decides
on the main structure of complicated proofs. (2) As a {\em tactician}, the user
performs the long and somewhat mindless process of mental pattern matching on
proof states, applying corresponding tactics until the lemma is proved. Many of
the steps in the tactician's role will be considered as ``obvious'' by a
mathematician. Our system is meant to replicate the pattern matching process
performed in this role, alleviating the user from this burden. Hence, we have
aptly named it Tactician.

To perform its job, Tactician can learn from existing proofs, by looking at how
tactics modify the proof state. Then, when proving a new lemma, the user can ask
the system to recommend previously used tactics based on the current proof state
and even to complete the whole proof using a search procedure based on these
tactic recommendations.

In our previous publication, the underlying machine learning and proof search
techniques employed by Tactician and how suitable data is extracted from Coq are
described~\cite{blaauwbroek2020tactic}. It also contains an evaluation of
Tactician's current proof automation performance on Coq's standard library. We
will not repeat these details here. Instead, we will focus on the operational
aspects and description of Tactician when used as a working and research tool.
\Cref{sec:system-overview} gives a mostly non-technical overview of the system
suitable for casual Coq users. That includes Tactician's design principles, its
mode of operation, a concrete example and a discussion on using Tactician in
large projects. \Cref{sec:technical-implementation} briefly discusses some of
Tactician's technical implementation issues, and
\Cref{sec:tactician-as-a-machine-learning-platform} describes how Tactician can
be used as a machine learning platform. Finally, \Cref{sec:related-work}
compares Tactician to related work. Installation instructions of Tactician can
be found at the project's website \url{http://coq-tactician.github.io}. This
pre-print is an extended version of our CICM paper with the same
title~\cite{DBLP:conf/mkm/BlaauwbroekUG20}.

\section{System Overview}
\label{sec:system-overview}
In this section, we give a mostly non-technical overview of Tactician suitable
for casual Coq users. \Cref{sec:design-decisions} states the guiding design
principles of the project, and \Cref{sec:mode-of-operation} describes the
resulting user workflow. On the practical side, \Cref{sec:a-concrete-example}
gives a simple, concrete example of Tactician's usage, while
\Cref{sec:learning-in-the-large} discusses how to employ Tactician in large
projects.

\subsection{Design Principles}
\label{sec:design-decisions}

For our system, we start with the principal goal of learning from previous
proofs to aid the user with proving new lemmas. In Coq, there are essentially
two notions of proof: (1) proof terms expressed in the Gallina language (Coq's
version of the Calculus of Inductive
Constructions~\cite{DBLP:conf/tlca/Paulin-Mohring93}); (2) tactic proof scripts
written by the user that can then generate a Gallina term. In principle, it is
possible to use machine learning on both notions of proof. We have chosen to
learn from tactic proof scripts for two reasons:
\begin{enumerate}
\item Tactics scripts are a higher-level and forgiving environment,
  which is more suitable for machine learning. A Gallina proof term must be
  generated extremely precisely while a tactic script often still works after
  minor local mutations have occurred. Gallina terms are also usually much
  bigger than their corresponding tactic script because individual tactics can
  represent large steps in a proof.
\item We acknowledge that automation systems within a proof assistant often
  still need input from the user to fully prove a lemma. Working on the tactic
  level allows the user to introduce domain-specific information to aid the
  system. For example, one can write new tactics that represent decision
  procedures and heuristics that solve problems Tactician could not otherwise
  solve. One can teach Tactician about such new tactics merely by using them in
  hand-written proofs a couple of times, after which the system will
  automatically start to use them.
\end{enumerate}

Apart from the principal goal described above, the most important objective of
Tactician is to be usable and remain usable by actual Coq users. Hence, we
prioritize the system's ``look and feel'' over its hard performance numbers. To
achieve this usability, Tactician needs to be pleasant to all parties involved,
which we express in four basic ``friendliness'' tenets.

\begin{description}
\item[User Friendly] If the system is to be used by actual Coq users, it should
  function as seamlessly as possible. After installation, it should be ready to
  go with minimal configuration and without needing to spend countless hours
  training a sophisticated machine learning model. Instead, there should be a
  model that can learn on the fly, with a future possibility to add a more
  sophisticated model that can be trained in batch once a development has been
  finished. Finally, all interaction with the system should happen within the
  standard Coq environment, regardless of which editor is used and without the
  need to execute custom scripts.
\item[Installation Friendly] Ease of installation is essential to reach solid
  user adoption. To facilitate this, the system should be implemented in Ocaml
  (Coq's implementation language), with no dependencies on machine learning
  toolkits written in other languages like Python or Matlab. Compilation and
  installation will then be just as easy as with a regular Coq release.
\item[Integration Friendly] The system should not be a fork of the main Coq
  codebase that has to be maintained separately. A fork would deter users from
  installing it and risk falling behind the upstream code. Instead, it should
  function as a plugin that can be compiled separately and then loaded into Coq
  by the user.
\item[Maintenance Friendly] We intend for Tactician not to become abandonware
  after main development has ceased, and at least remain compatible with the
  newest release of Coq. As a first step, the plugin should be entered into the
  Coq Package Index~\cite{coq_package_index}, enabling continuous integration
  with future versions of Coq. Additionally, assuming that Tactician becomes
  wildly popular, we eventually intend for it to be absorbed into the main Coq
  codebase.
\end{description}

\subsection{Mode of Operation}
\label{sec:mode-of-operation}

Analogously to Coq's mode of operation, Tactician can function both in
interactive mode and in compilation mode.

\subsubsection{Interactive Mode}
\subfile{tactician-interactive-overview}
We illustrate the interactive mode of operation of Tactician using the schematic
in \Cref{fig:tactician-interactive-overview}. When the user starts a new Coq
development file---say \texttt{X.v}---the first thing Tactician does is create
an (in-memory) empty tactic database \texttt{X} corresponding to this file. The
user then starts to prove lemmas as usual. Behind the scenes, every executed
tactic, e.g. $tactic_{a1}$, is saved into the database accompanied by the proof
states before and after tactic execution, in this case,
$\langle\Gamma_{a1}\vdash\sigma_1, tactic_{a1}, \Gamma_{a2}\vdash\sigma_2
\rangle$. The difference between these two states represents the action
performed by the tactic, while the state before the tactic represents the
context in which it was useful. By recording many such triples for a tactic, we
create a dataset representing an approximation of that tactic's semantic
meaning. The database is kept synchronized with the user's movement within the
document throughout the entire interactive session.

After proving a few lemmas by hand, the user can start to reap the fruits of the
database. For this, the tactics \texttt{suggest} and \texttt{search} are
available. We illustrate their use in the schematic when ``Lemma z : $\omega$''
is being proven. The user first executes two normal tactics. After that, Coq's
proof state window displays a state for which the user is unsure what tactic to
use. Here Tactician's tactics come in.
\begin{description}
\item[\texttt{suggest}] This tactic can be executed to ask Tactician for a list
  of recommendations. The current proof state
  $A\!:\gamma_1,B\!:\gamma_2,\ldots,Z\!:\gamma_n\vdash \omega_3$ is fed into the
  pattern matching engine, which will perform a comparison with the states in
  the tactic database. From this, an ordered list of recommendations is
  generated and displayed in Coq's messages window, where the user can select a
  tactic to execute.
\item[\texttt{search}] Alternatively, the system can be asked to \texttt{search}
  for a complete proof. We start with the current proof state, which we rename
  to $\Phi_1 \vdash \rho_1$ for clarity. Then a search tree is formed by
  repeatedly running \texttt{suggest} on the proof state and executing the
  suggested tactics. This tree can be traversed in various ways, finishing only
  when a complete proof has been found.

  If a proof is found, two things happen. (1) The Gallina proof term that is
  found is immediately submitted to Coq's proof engine, after which the proof
  can be closed with \texttt{Qed}. (2) Tactician generates a reconstruction
  tactic \texttt{search failing $\langle \texttt{t}_{12}, \texttt{t}_{32},...
    \rangle$} which is displayed to the user (see the bottom of the figure). The
  purpose of this tactic is to provide a modification resilient proof cache that
  also functions when Tactician is not installed. Its semantics is to first try
  to use the previously found list of tactics \texttt{$\langle \texttt{t}_{12},
    \texttt{t}_{32},... \rangle$} to complete the proof immediately. ``Failing''
  that (presumably due to changes in definitions or lemmas), a new search is
  initiated to recover the proof. To use the cache, the user should copy it and
  replace the original \texttt{search} invocation with it in the source file.
\end{description}

\subsubsection{Compilation Mode}

\subfile{tactician-batch-overview}

This mode is visualized in \Cref{fig:tactician-batch-overview}. After the file
\texttt{X.v} has been finished, one might want to depend on it in other files.
This requires the file to be compiled into a binary \texttt{X.vo} file. The
compilation is performed using the command \texttt{coqc X.v}. Tactician is
integrated into this process. During compilation, the tactic database is rebuilt
in the same way as in interactive mode and then included in the \texttt{.vo}
file. When development \texttt{X.v} is then \texttt{Require}d by another
development file \texttt{Y.v}, the tactic database of \texttt{X.v} is
automatically inherited.

\subsection{A Concrete Example}
\label{sec:a-concrete-example}
We now give a simple example use-case based on lists. Starting with an empty
file, Tactician is immediately ready for action. We proceed as usual by giving a
standard inductive definition of lists of numbers with their corresponding
notation and a function for concatenation.
\begin{minted}{coq}
Inductive list :=
| nil  : list
| cons : nat -> list -> list.
Notation "[]"      := nil.
Notation "x :: ls" := (cons x ls).

Fixpoint concat ls₁ ls₂ :=
match ls₁ with
| []      => ls₂
| x::ls₁' => x::(ls₁' ++ ls₂)
end where "ls₁ ++ ls₂" := (concat ls₁ ls₂).
\end{minted}
We wish to prove some standard properties of concatenation. The first is a lemma
stating that the empty list \texttt{[]} is the right identity of concatenation
(the left identity is trivial).
\begin{minted}{coq}
Lemma concat_nil_r : ∀ ls, ls ++ [] = ls.
\end{minted}
With Tactician installed, we immediately have access to the new tactics
\texttt{suggest} and \texttt{search}. Neither tactic will produce a result when
used now since the system has not had a chance to learn from proofs yet.
Therefore, we will have to prove this lemma by hand.

\begin{minted}{coq}
Proof.
intros. induction ls.
- simpl. reflexivity.
- simpl. f_equal. apply IHls.
Qed.
\end{minted}
The system has immediately learned from this proof (it was even learning during
the proof) and is now ready to help us with a proof of the associativity of
concatenation.
\begin{minted}{coq}
Lemma concat_assoc :
  ∀ ls₁ ls₂ ls₃, (ls ++ ls₂) ++ ls₃ = ls ++ (ls₂ ++ ls₃).
\end{minted}
Now, if we execute \texttt{suggest}, it outputs the ordered list \texttt{intros,
  simpl, f\_equal, reflexivity}. Indeed, using \texttt{intros} as our next
tactic is not unreasonable. We can repeatedly ask \texttt{suggest} for a
recommendation after every tactic we input, which sometimes gives us good
tactics and sometimes bad tactics. However, we can also eliminate the middle-man
and execute the \texttt{search} tactic, which immediately finds a proof.
\begin{minted}{coq}
Proof. search. Qed.
\end{minted}
To cache the proof that is found for the future, we can copy-paste the
reconstruction tactic that Tactician prints into the source file. This example
shows how the system can quickly learn from very little data and with minimal
effort from the user. Of course, this also scales to much bigger developments.

We continue our example for more advanced Coq users to showcase how Tactician
can learn to use custom domain-specific tactics. We begin by defining an
inductive property encoding that one list is a non-contiguous sublist of
another.
\begin{minted}{coq}
Inductive sublist : list -> list -> Prop :=
| sl_nil : sublist [] []
| sl_cons₁ ls₁ ls₂ n : sublist ls₁ ls₂ -> sublist ls₁ (n::ls₂)
| sl_cons₂ ls₁ ls₂ n : sublist ls₁ ls₂ -> sublist (n::ls₁) (n::ls₂).
\end{minted}
We now wish to prove that some lists have the sublist property. For example,
\texttt{sublist (9::3::[]) (4::7::9::3::[])}. Deciding this is not entirely
trivial, because it is not possible to judge from the head of the list whether
to apply \texttt{sl\_cons₁} or \texttt{sl\_cons₂}. Instead of manually writing
these proofs, we create a domain-specific, heuristic proving tactic that
automatically tries to find a proof.
\begin{minted}{coq}
Ltac solve_sublist := solve [match goal with
| |- sublist [] [] => apply sl_nil
| |- sublist (_::_) [] => fail
| |- sublist _ _ =>
       (apply sl_cons₁ + apply sl_cons₂); solve_sublist
| |- _ => solve [auto]
end].
\end{minted}
This tactic looks at the current proof state and checks that the goal is of the
form \texttt{sublist ls₁ ls₂}. If the lists are empty, it can be finished using
\texttt{sl\_nil}. If \texttt{ls₂} is empty but \texttt{ls₁} nonempty, the
postfix is unprovable, and the tactic fails. In all other cases, we initiate a
backtracking search where we try to apply either \texttt{sl\_cons₁} or
\texttt{sl\_cons₂} and recurse. Finally, we add a simple catch-all clause that
tries to prove any side-conditions using Coq's built-in \texttt{auto}. We now
teach Tactician about the existence of our previous lemmas and the
domain-specific tactic by defining some simple examples. Finally, we ask
Tactician to solve a more complicated, compound problem.
\begin{minted}{coq}
Lemma ex1 : sublist (9::3::[]) (4::7::9::3::[]).
Proof. solve_sublist. Qed.

Lemma ex2 : ∀ ls, 1::2::ls ++ [] = 1::2::ls.
Proof. intro. rewrite concat_nil_r. reflexivity. Qed.

Lemma dec2 : ∀ ls₁ ls₂, sublist ls₁ ls₂ ->
  sublist (7::9::13::ls₁) (8::5::7::[] ++ 9::13::ls₂ ++ []).
Proof. search. Qed.
\end{minted}
The proof found by Tactician is \texttt{rewrite
  concat\_nil\_r;intros;solve\_sublist}. It has automatically figured out that
it needs to introduce the hypothesis, normalize the list and then run the
domain-specific prover. This example is somewhat contrived but should illustrate
how the user can easily teach Tactician domain-specific knowledge.

\subsection{Learning and Proving in the Large}
\label{sec:learning-in-the-large}
The examples above are fun to play with and useful for demonstration purposes.
However, when using Tactician to develop real projects, three main issues need
to be taken care of, namely (1) instrumenting dependencies, (2) instrumenting
the standard library and, (3) reproducible builds. Below, we describe how to use
Tactician in complex projects and, in particular, how these issues are solved.

Tactician itself is a collection of easily installed Opam~\cite{opam} packages
distributed through the Coq Package Index~\cite{coq_package_index}. The package
\texttt{coq-tactician} provides the main functionality. It needs to be installed
to run the examples of \Cref{sec:a-concrete-example}. These examples have no
dependencies and make minimal use of Coq's standard library. All learning is
done within one file, making them a simple use-case. Things become more
complicated when one starts to use the standard library and libraries defined in
external dependencies. Although Tactician will keep working normally in those
situations, by default, it does not learn from proofs in these libraries. Hence,
Tactician's ability to synthesize proofs for lemmas concerning the domain of
those libraries will be severely limited.

The main question to remedy this situation is where Tactician should get its
learning data from. As explained in \Cref{sec:mode-of-operation}, Tactician
saves the tactic database of a library in the compiled \texttt{.vo} binaries.
This database becomes available as soon as the compiled library is loaded.
However, this only works if the library was compiled with Tactician enabled,
which is the case neither for Coq's standard library nor most external packages.
Hence, we need to instrument these libraries by recompiling them while Tactician
is loaded. Loading Tactician amounts to finding a way of convincing Coq to
pre-load the library \texttt{Tactician.Ltac1.Record} before starting the
compilation process.

\subsubsection{External Dependency Instrumentation}
An external dependency can be any collection of Coq source files together with
an arbitrary build system. Injecting the loading of
\texttt{Tactician.Ltac1.Record} into the build process automatically is not
possible in general. However, we do provide a simple solution for the most
common situation. Coq provides package developers with a utility called
\texttt{coq\_makefile} that automatically generates a Makefile to build and
install their files. This build system is usually packaged up with Opam to be
released on the Coq Package Index. Although this package index does not require
packages to use \texttt{coq\_makefile}, most do this in practice.

Makefiles generated by \texttt{coq\_makefile} are highly customizable through
environment variables. Tactician provides command-line utilities called
\texttt{tactician enable} and \texttt{tactician disable} that configure Opam to
automatically inject Tactician through these environment variables. When
building packages without Opam, the user can modify the environment by running
\texttt{eval \$(tactician inject)} before building. This solution will suffice
to instrument most packages created using \texttt{coq\_makefile}, as long as
authors do not customize the resulting build file too heavily. We will add
support for Coq's new Dune build system~\cite{dune} when it has stabilized. For
more stubborn packages, rather aggressive methods of injecting Tactician are
also possible but, in general, packages that circumvent instrumentation are
always possible. Therefore, we do not provide built-in solutions for those
cases.

\subsubsection{Standard Library Instrumentation}
In order to instrument Coq's standard library, it also needs to be recompiled
with \texttt{Tactician.Ltac1.Record} pre-loaded. We provide the Opam package
\texttt{coq-tactician-stdlib} for this purpose. This package does not contain
any code, but simply takes the source files of the installed standard library
and recompiles them. It then promptly commits the Cardinal Sin of Package
Management by overwriting the original binary \texttt{.vo} files of the standard
library. We defend this choice by noting that (1) the original files will be
backed up and restored when \texttt{coq-tactician-stdlib} is removed and (2) the
alternative of installing the recompiled standard library in a secondary
location is even worse. This choice would cause a rift in the users local
ecosystem of packages, with some packages relying on the original standard
library and some on the recompiled one. Coq will refuse to load two packages
from the rivaling ecosystems citing ``incompatible assumptions over the standard
library,'' forever setting them apart.

Even with our choice of overwriting the standard library, an ecosystem rift
still occurs if packages depending on Coq already pre-existed. To resolve this,
Tactician ships with the command-line utility \texttt{tactician recompile} that
helps the user find and recompile these packages.

\subsubsection{Tactician Usage within Packages}
In order to use Tactician's \texttt{suggest} and \texttt{search} tactics, the
library \texttt{Tactician.Ltac1.Tactics} needs to be loaded. However, we
strongly advise against loading this library directly, for two reasons. (1) If a
development \texttt{X} that uses Tactician is submitted to the Coq Package Index
as \texttt{coq-x}, an explicit dependency on \texttt{coq-tactician} is needed.
This dependency can be undesirable due to users potentially being unwilling to
install Tactician. (2) It would undermine the build reproducibility of the
package. Even though \texttt{coq-tactician} would be installed as a dependency
when \texttt{coq-x} is installed, there is no way to ensure that Tactician has
instrumented the other dependencies of the package. Hence, it is likely that
Tactician will be operating with a smaller tactic database, reducing its ability
to prove lemmas automatically.

Instead, the package \texttt{coq-x} should depend on
\texttt{coq-tactician-dummy}. This package is extremely simple, containing one
30-line library called \texttt{Tactician.\allowbreak Ltac1Dummy}. It provides
alternative versions of Tactician tactics that act as dummies of the real
version. Tactics \texttt{suggest} and \texttt{search} will not perform any
action. However, tactic \texttt{search failing $\langle$...$\rangle$}, described
in \Cref{sec:mode-of-operation}, will still be able to complete a proof using
its cache (but without the ability to search for new proofs in case of failure).
A released package can thus only employ cached searches. This way, any build
will be reproducible.

During development, the real version of Tactician should be loaded to gain its
full power. Instead of loading it explicitly through a \texttt{Require} in
source files, we recommend that users load it through the \texttt{coqrc} file.
Coq will automatically process any vernacular defined in this file at startup.
The command-line utility \texttt{tactician enable} will assist in adding the
correct vernacular to the \texttt{coqrc} file.

\section{Technical Implementation}
\label{sec:technical-implementation}

In this section, we provide a peek behind the curtains of Tactician's technical
implementation and how it is integrated with Coq. A previous publication already
covers the following aspects of Tactician~\cite{blaauwbroek2020tactic}: (1) The
machine learning models used to suggest tactics; (2) an explanation of how data
extracted from Coq is decomposed and transformed for these models; and (3) the
search procedure to synthesize new proofs. These details are therefore omitted
here.

\subsection{Intercepting Tactics}
\label{sec:intercepting-tactics}

Tactician is implemented as a plugin that provides a new proof mode (tactic
language) to Coq. This proof mode contains precisely the same syntactical elements
as the Ltac1 tactic language~\cite{DBLP:conf/lpar/Delahaye00}. The purpose of
the proof mode is to intercept and decompose executed tactics and save them in
Tactician's database. After interception, the tactics are redirected back to the
regular Ltac1 engine. By loading the library \texttt{Tactician.Ltac1.\allowbreak
  Record}, this proof mode is activated
instead of the regular Ltac1 language.

Note that Ltac1 is the most popular but by no means the only tactic language
for
Coq~\cite{DBLP:journals/pacmpl/KaiserZKRD18,DBLP:conf/esop/MalechaB16,DBLP:journals/jfrea/GonthierM10,pedrot2019ltac2}.
All these languages are compiled into a proof monad implemented on the OCaml
level~\cite{DBLP:journals/jlp/KirchnerM10}. It would be preferable to instrument
the proof monad directly as this would enable us to record tactics from all
languages at once. It appears that this is impossible, though, because the
structure of the monadic interface does not allow us to recover high-level
tactical units such as decision procedures, even when implemented as the most
general Free Monad. As such, Tactician only supports Ltac1 at the moment. In the
future, we intent to provide improved support for
SSreflect~\cite{DBLP:journals/jfrea/GonthierM10} and support for recording the
new Ltac2 language~\cite{pedrot2019ltac2}.

\subsection{State Synchronization}
\label{sec:state-synchronization}

When recording tactics in interactive mode, it is important to synchronize the
tactic database with the undo/redo actions of the user, both from a theoretical
and practical perspective. In theory, if a user undoes a proof step, this
represents a mistake made by the user, meaning that the recorded information in
the database is also a mistake. In practice, keeping such information will lead
to problems in compilation mode because the database will be smaller due to the
lack of undo/redo actions. Therefore \texttt{search}es that succeeded in
interactive mode may not succeed in compilation mode. Below, we explain how Coq
and Tactician deal with state synchronization.

Internally, Coq ships with a state manager that keeps track of all state
information generated when vernacular commands are executed. This information
includes, for example, definitions, proofs, and custom tactic definitions. This
data is automatically synchronized with the user's interactive movement through
the document, and saved to the binary \texttt{.vo} file during compilation. All
data structures registered with the state manager are expected to be persistent
(in the functional programming sense~\cite{DBLP:journals/jcss/DriscollSST89}).
The copy-on-write semantics of such data structures allow the state manager to
easily keep a history of previous versions and revert to them on demand.

For Tactician, registering data structures with the state manager to ensure
proper synchronization is awkward, because the state manager assumes that
tactics have no side-effects outside of modifications to the proof state. Hence,
any data registered with the state manager is discarded as soon as the current
proof has been finished. Tactician solves this by tricking Coq into thinking
that tactics are side-effecting vernacular commands, convincing it to re-execute
all tactics at \texttt{Qed} time to properly register the side-effects. However,
as a consequence, these tactics will modify the proof state a second time, at a
time when this is not intended. This is a likely source of future bugs for which
a permanent solution is yet to be found.

\section{Tactician as a Machine Learning Platform}
\label{sec:tactician-as-a-machine-learning-platform}
Apart from serving as a tool for end-users, Tactician also functions as a
machine learning platform. A simple OCaml interface to add a new learning model
to Tactician is provided. The learning task of the model is to predict a list of
tactics for a given proof state. When registering a new model, Tactician will
automatically take advantage of it during proof search. Our interface hides
Coq's internal complexities while being as general as possible. We encourage
everyone to implement their favorite learning technique and try to beat the
built-in model. Tactician's performance can easily be benchmarked on the
standard library and other packages. The signature of a machine learning model
is as follows:
\begin{minted}{ocaml}
type sentence = Node of string * sentence list
type proof_state =
{ hypotheses : (id * sentence) list
; goal       : sentence }

type tactic
val tactic_sentence : tactic -> sentence
val local_variables : tactic -> id list
val substitute      : tactic -> id_map -> tactic

module type TacticianModelType = sig
  type t
  val create : unit -> t
  val add : t ->  before:proof_state -> tactic -> after:proof_state -> t
  val predict : t -> proof_state -> (float * tactic) list
end
val register_learner : string -> (module TacticianLearnerType) -> unit
\end{minted}

A \texttt{sentence} is a very general tree data type able to encode all of Coq's
internal syntax trees, such as those of terms and tactics. Node names of syntax
trees are converted into \texttt{string}s. This way, most semantic information
is preserved using a much simpler data type that is suitable for most machine
learning techniques. Proof states are encoded as a list of named hypothesis
sentences and a goal sentence. In this case, sentences represent a Gallina term.
We abstract from some of Coq's proof state complexities such as the shelf and
the unification map.

Tactician represents \texttt{tactic}s as an abstract type that can be inspected
as a sentence using \texttt{tactic\_sentence}. Since the goal of this interface
is to \textit{predict} tactics but not \textit{synthesize} tactics, it is not
possible to modify them (this would seriously complicate the interface). There
is one exception. We provide a way to extract a list of variables that refer to
the local context of a proof. The local variables of a tactic can also be
updated using a simultaneous substitution. Such substitutions will allow for a
limited form of parameter prediction.

We think that local variable prediction is the only kind of parameter prediction
that makes sense in Tactician's context. The only other major classes of
parameters are global lemma names and complete Gallina terms. Predicting
complete terms is known to be very difficult and would unnecessarily complicate
the interface. Predicting names of global lemmas is possible, but does not
appear to be very useful because lemma names are almost always directly
associated with basic tactics like \texttt{apply lem} or \texttt{rewrite lem}.
Predicting parameters for these tactics is counter-productive because their
semantics are mostly dependent on the definition of the lemma. Hence, it is
better to view the incarnations of such tactics with different lemmas as
arguments as completely separate tactics.

Finally, implementing a learning model entails implementing the module type
\texttt{TacticianModelType} and registering it with Tactician. This module
requires an implementation of a database type \texttt{t}. For reasons explained
in \Cref{sec:state-synchronization}, this database needs to be persistent.
Tactician will \texttt{add} \texttt{tactic}s to the database, together with the
\texttt{proof\_state} before and after the tactic was applied. The machine
learning task of the model is to \texttt{predict} a weighted list of tactics
that are likely applicable to a previously unseen proof state.

The current interface only allows for models that support online learning
because database entries are \texttt{add}ed one by one in interactive mode. We
justify this by the user-friendliness requirements from
\Cref{sec:design-decisions}. However, we realize that together with the
persistence requirement, this places considerable limitations on the kind of
learning models that can be employed. In the future, we intent to support a
secondary interface that can be used to create offline models employing batch
learning on large Coq packages in its entirety.

\section{Case Study}
\label{sec:case-studies}
The overall performance of our tactical search on the full Coq Standard Library
is reported in a previous publication~\cite{blaauwbroek2020tactic}, which also
reports performance on various parts of the library. The best-performing version
of our learning model can prove 34.0\% of the library lemmas when using a 40s
time limit. Six different versions together prove 39.3\%. The union with all
CoqHammer methods achieves 56.7\%.\footnote{CoqHammer's eight methods prove
  together 40.8\%, with the best proving 28.8\%.}

Here we show an example of a nontrivial proof found by Tactician. The system was
asked to automatically find the proof of the following lemma from the library
file
\texttt{Structures/GenericMinMax.v},\footnote{\url{https://coq.inria.fr/library/Coq.Structures.GenericMinMax.html}}
where facts about general definitions of \texttt{min} and \texttt{max} are
proved.
\begin{minted}{coq}
Lemma max_min_antimono f :
 Proper (eq==>eq) f -> Proper (le==>flip le) f ->
 forall x y, max (f x) (f y) == f (min x y).
\end{minted}
Tactician's learning model evaluated the following two lemmas as similar to what
has to be proven:
\begin{minted}{coq}
Lemma min_mono f :
   (Proper (eq ==> eq) f) -> (Proper (le ==> le) f) ->
   forall x y, min (f x) (f y) == f (min x y).
 intros Eqf Lef x y.
 destruct (min_spec x y) as [(H,E)|(H,E)]; rewrite E;
  destruct (min_spec (f x) (f y)) as [(H',E')|(H',E')]; auto.
 - assert (f x <= f y) by (apply Lef; order). order.
 - assert (f y <= f x) by (apply Lef; order). order.
Qed.

Lemma min_max_modular n m p :
   min n (max m (min n p)) == max (min n m) (min n p).
 intros. rewrite <- min_max_distr.
 destruct (min_spec n p) as [(C,E)|(C,E)]; rewrite E; auto with *.
 destruct (max_spec m n) as [(C',E')|(C',E')]; rewrite E'.
 - rewrite 2 min_l; try order. rewrite max_le_iff; right; order.
 - rewrite 2 min_l; try order. rewrite max_le_iff; auto.
Qed.
\end{minted}
The trace through the proof search tree that resulted in a proof is as follows:
\begin{verbatim}
max_min_antimono  .0.0.0.5.5.2.1.0.5.1.5.1
\end{verbatim}
This trace represents, for every choice point in the search tree, which of
\texttt{suggest}'s ranked suggestion was used to reach the proof. The proof
search went into depth 12 and the first three tactics used in the final proof
are those with the highest score as recommended by the learning model, which
most likely followed the proof of \texttt{min\_mono}. However, after that, it
had to diverge from that proof, using only the sixth-best ranked tactic twice in
a row. This nontrivial search continued for the next seven tactical steps,
combining mostly tactics used in the two lemmas and some other tactics. The
search finally yielded the following proof of \texttt{max\_min\_antimono}.
\begin{minted}{coq}
intros Eqf Lef x y. destruct (min_spec x y) as [(H, E)|(H, E)]. rewrite E.
destruct (max_spec (f x) (f y)) as [(H', E')| (H', E')].
assert (f y <= f x) by (apply Lef; order). order. auto. rewrite E.
destruct (max_spec (f x) (f y)) as [(H', E')| (H', E')]. auto.
assert (f x <= f y) by (apply Lef; order). order.
\end{minted}
Note that the original proof of the lemma is quite similar, but shorter and
without some redundant steps. Redundant steps are known to happen in systems
like Tactician, such as the TacticToe~\cite{DBLP:conf/lpar/GauthierKU17} system
for HOL4~\cite{DBLP:conf/tphol/SlindN08}.
\begin{minted}{coq}
intros Eqf Lef x y. destruct (min_spec x y) as [(H,E)|(H,E)]; rewrite E;
destruct (max_spec (f x) (f y)) as [(H',E')|(H',E')]; auto.
- assert (f y <= f x) by (apply Lef; order). order.
- assert (f x <= f y) by (apply Lef; order). order.
\end{minted}

\section{Related Work}
\label{sec:related-work}
There exist quite  a few machine learning systems for  Coq and other interactive
theorem  provers. The  most significant  distinguishing factor  of Tactician  to
other systems for Coq is its
user-friendliness.
There are several other systems that  are interesting, but rather challenging to
install and use for end-users. They often depend on
external tools such as machine  learning toolkits and automatic theorem provers.
Some   systems   need   a   long   time  to   train   their   machine   learning
models---preferably on  dedicated hardware. Those  are often not  geared towards
end-users at all but rather towards the Artificial Intelligence community.

Tactician       takes       its       main      inspiration       from       the
TacticToe~\cite{DBLP:conf/lpar/GauthierKU17}              system             for
HOL4~\cite{DBLP:conf/tphol/SlindN08}  which  learns  tactics  expressed  in  the
Standard ML language. Using this knowledge, it can then automatically search for
proofs by  predicting tactics and their  arguments. Our work is  similar both in
doing a  learning-guided tactic search  and by  its complete integration  in the
underlying  proof  assistant  without   relying  on  external  machine  learning
libraries and specialized hardware.

Below is a short list of machine learning systems for the Coq theorem prover.
\begin{description}
\item[ML4PG]  provides   tactic  suggestions  by  clustering   together  various
  statistics               extracted              from               interactive
  proofs~\cite{DBLP:journals/corr/abs-1212-3618}.  It  is  integrated  with  the
  Proof  General~\cite{DBLP:conf/tacas/Aspinall00}  proof  editor  and  requires
  connections to Matlab or Weka.
\item[SEPIA]  provides  proof  search  using  tactic  predictions  and  is  also
  integrated   with   Proof  General~\cite{DBLP:conf/cade/GransdenWR15}.   Note,
  however, that  its proof search  is only based on  tactic traces and  does not
  make predictions based on the proof state.
\item[Gamepad] is a  framework that integrates with the Coq  codebase and allows
  machine learning  to be performed  in Python~\cite{DBLP:conf/iclr/HuangDSS19}.
  It uses  recurrent neural networks to  make tactic prediction and  to evaluate
  the quality of a  proof state. The system is able to  synthesize proofs in the
  domain of algebraic rewriting. Gamepad is not geared towards end-users.
\item[CoqGym] extracts tactic  and proof state information on a  large scale and
  uses it to  construct a deep learning model capable  of generating full tactic
  scripts~\cite{DBLP:conf/icml/YangD19}.  CoqGym's evaluation  is  using a  time
  limit of 600s, which is impractically high for Coq practitioners. Still, it is
  significantly weaker than CoqHammer. A probable  cause is the slowness of deep
  neural networks which is common to most proving experiments geared towards the
  deep learning community.

\item[Proverbot9001]  is  a proof  search  system  for  Coq  based on  a  neural
  architecture~\cite{DBLP:journals/corr/abs-1907-07794}. The system is evaluated
  on  the verified  CompCert  compiler~\cite{DBLP:journals/cacm/Leroy09}. It  is
  reported that  Proverbot9001's architecture is a  significant improvement over
  CoqGym.
\item[CoqHammer]  is  a  machine  learning  and  proving  tool  in  the  general
  \emph{hammers}~\cite{DBLP:journals/jfrea/BlanchetteKPU16,DBLP:journals/jar/KaliszykU14,DBLP:journals/jar/BlanchetteGKKU16,DBLP:journals/jar/KaliszykU15a}
  category   designed    for   Coq~\cite{DBLP:journals/jar/CzajkaK18}.   Hammers
  capitalize      on     the      capabilities     of      automatic     theorem
  provers~\cite{DBLP:conf/lpar/Schulz13,DBLP:conf/tacas/MouraB08,DBLP:conf/cade/RiazanovV99}
  to assist  ITP's. To  this end,  learning-based premise  selection is  used to
  translate an ITP  problem to the ATP's target language  (typically First Order
  Logic).  A proof  found by  the ATP  can then  be reconstructed  in the  proof
  assistant. CoqHammer is  a maintained system that is  well-integrated into Coq
  and only requires a connection to an ATP.
  It has  similar performance as  Tactician but proves different  lemmas, making
  these systems complementary~\cite{blaauwbroek2020tactic}.
\end{description}

\section{Further Work and Conclusion}
\label{sec:conclusion}
We have presented Tactician, a seamless and interactive tactic learner and
prover for Coq. The machine learning perspective has been described in a
previous publication~\cite{blaauwbroek2020tactic}. We showed how Tactician is an
easy-to-use tool that can be employed by the user with minimal installation
effort. A clear approach to using the system in large developments has also been
outlined. With its current machine learning capabilities, we expect Tactician to
help the user with its proving efforts significantly. Finally, we presented a
powerful machine learning interface that will allow researchers to bring their
advanced learning models to Coq users while being isolated from Coq's internal
complexities. We expect this to be of considerable utility to both the
artificial intelligence community and Coq users.

There are many future research directions. There is a never-ending quest to
improve the built-in learning model. With better features and stronger (but
still fast) learners such as boosted trees (used in
ENIGMA-NG~\cite{DBLP:conf/cade/ChvalovskyJ0U19})
we hope to push Tactician's performance
over the standard library towards 50\%. Apart from this, we expect to improve
support for SSreflect and to introduce support for the new Ltac2 language. In
the future, the machine learning interface will be expanded to allow for batch
learning. Additionally, we would like to incorporate the tactic history
(\textit{memory}) of the current lemma into the learning model, similar to
SEPIA. Short-term memory will allow Tactician to modify its suggestions based on
the tactics that were previously executed in the current proof.

\bibliographystyle{plainurl}


\section{Introduction}

\whizard\ is a multi-purpose event generator for collider
physics~\cite{Kilian:2007gr}. It is a very general framework for all
types of colliders, but with a special emphasis on the physics program
at lepton colliders, and has been used for many studies and design
reports for e.g. ILC, CLIC and
FCC-ee~\cite{Fujii:2015jha,deBlas:2018mhx,Baer:2013cma,Behnke:2013lya,Abada:2019zxq}.
Hard scattering process matrix elements are generated with \whizard's
intrinsic (tree-level) matrix element generator
\texttt{O'Mega}~\cite{Moretti:2001zz}, using the color-flow formalism
for QCD~\cite{Kilian:2012pz}. It supports all particles up to spin 2,
and also fermion-number violating
vertices~\cite{Ohl:2002jp,AguilarSaavedra:2005pw,Hagiwara:2005wg,Kalinowski:2008fk}.
\texttt{O'Mega} can write matrix-element code as compiled process code
(libraries) or as byte-code instructions in the form of a virtual
machine~\cite{Nejad:2014sqa}. The latter produces very small and
efficient matrix element instructions. The NLO automation will be discussed in
Sec.~\ref{sec:nlo}. \whizard\ comes with two different final- and
initial-state parton shower implementations, a $k_T$-ordered shower as
well as an analytic parton shower~\cite{Kilian:2011ka}. For LC
simulations, \whizard\ ships with the final \texttt{Pythia6}
version~\cite{Sjostrand:2006za} for shower and hadronization; it also
has a full-fledged interface to
\texttt{Pythia8}~\cite{Sjostrand:2014zea}. This is very handy as it
directly transfers data between the two event records of the
generators and allows \whizard\ to use all of \texttt{Pythia8}'s
machinery for matching and merching. \whizard\ also automatically
assigns underlying resonances to full off-shell processes and gives
the correct information of resonant shower systems to the parton
shower.

One of the special features of \whizard\ is its framework for the
support of lepton collider physics, including electron PDFs with
resummation of soft photons to all orders and hard-collinear photons
up to third order in $\alpha$, the generation of ISR photon $p_T$
spectra, sampling of lepton collider beam spectra~\cite{Ohl:1996fi},
proper simulation of polarized beams, crossing angles and
photon-induced background processes.

\whizard\ has a large number of hard-coded Beyond the Standard Model
(BSM) models. The newest development for new physics, especially
regarding completely general Lorentz tensor structures, will be
described in Sec.~\ref{sec:bsm}.

\section{New physics and technical features}

\subsection{Performance and integration, technical features}

\whizard\ has a very modular infrastructure that allows to easily
exchange different components: there are several different phase-space
algorithms implemented, as well as several different Monte Carlo
integration options. Besides the traditional \texttt{VAMP}
integrator~\cite{Ohl:1998jn}, there is now a conceptually identical
implementation generalized to an MPI-based parallelization. In
contrast to event generation which can always be trivially
parallelized, adaptive phase space integration cannot so easily
parallelized, and is a major bottleneck for high-multiplicity tree-
and especially loop-level processes. This
\texttt{VAMP2} integrator~\cite{Brass:2018xbv} will now be further
improved with a dynamic load balancer that allows for non-blocking
communication between the different workers. The new setup will be
released in version 3.0$\alpha$, cf. below. Even without the load
balancer speed-ups between 10 and 100 are observed, depending on the
complexity of processes.

Further technical improvements are the finalization of the proper event
headers for the LCIO event interface for the LC software framework, as
well as the completion of the interface to \texttt{HepMC3}. Rescanning
of event files in order to recalculate hard matrix elements without
recalculating the phase space, now also work with beam spectra and
structure functions. Alternative weights (squared matrix elements) can
now be written out not only in LHE and HepMC formats, but also to LCIO.

\subsection{Beyond the standard model physics}
\label{sec:bsm}

Besides of the full SM samples for TESLA, ILC, CLIC and CEPC,
\whizard\ has been extensively used for BSM simulations where it
contains e.g. complete implementations of Little Higgs
models~\cite{Kilian:2003xt,Kilian:2004pp,Kilian:2006eh,Reuter:2012sd,Reuter:2013iya,Dercks:2018hgz}. Another
interesting feature is
\whizard's ability to calculate unitarity constraints for vector boson
scattering (VBS) and multi-boson processes and to deliver unitarized
\begin{table}

\begin{tiny}
  \def1.05{1.05}
  \begin{tabular}{l l l l}
    \toprule{}%
    Process & $\sigma^{\text{LO}}[{\ensuremath\rm pb}]$ & $\sigma^{\text{NLO}}[{\ensuremath\rm pb}]$ & $K$ \\
    \midrule{
    $pp\to  jj$ & \tablelinepp{1.157}{2}{1.604}{7}{6} \\

    \midrule{}%
     $pp\to  Z$  & \tablelinepp{4.2536}{3}{5.4067}{2}{4} \\
     $pp\to  Zj$ & \tablelinepp{7.207}{2}{9.720}{17}{3} \\
     $pp\to  Zjj$ & \tablelinepp{2.352}{8}{2.735}{9}{3} \\
     \midrule{}%
     $pp\to  W^\pm$   & \tablelinepp{1.3750}{5}{1.7696}{9}{5} \\
     $pp\to  W^\pm j$ & \tablelinepp{2.043}{1}{2.845}{6}{4} \\
     $pp\to  W^\pm jj$ & \tablelinepp{6.798}{7}{7.93}{3}{3} \\
     \midrule{}%
     $pp\to  ZZ$ & \tablelinepp{1.094}{2}{1.4192}{32}{1} \\
     $pp\to  ZZj$ & \tablelinepp{3.659}{2}{4.820}{11}{0} \\
     $pp\to  ZW^\pm$ & \tablelinepp{2.775}{2}{4.488}{4}{1} \\
     $pp\to  ZW^\pm j$ & \tablelinepp{1.604}{6}{2.103}{4}{1} \\
     $pp \to W^+W^- (4f)$ & \tablelinepp{0.7349}{7}{1.027}{1}{2} \\
     $pp \to W^+W^-j \;(4f)$ & \tablelinepp{2.868}{1}{3.733}{8}{1} \\
     $pp \to W^+W^+jj$ & \tablelinepp{1.483}{4}{2.238}{6}{-1} \\
     $pp \to W^-W^-jj$ & \tablelinepp{6.755}{4}{9.97}{3}{-1} \\
     \midrule{}%
     $pp \to W^+W^-W^\pm (4f)$ & \tablelinepp{1.309}{1}{2.117}{2}{-1} \\
     $pp \to ZW^+W^-(4f)$ & \tablelinepp{0.966}{2}{1.682}{2}{-1} \\
     $pp \to W^+W^-W^\pm Z (4f)$ & \tablelinepp{0.642}{2}{1.240}{2}{-3} \\
     $pp \to W^\pm ZZZ$ & \tablelinepp{0.588}{2}{1.229}{2}{-5} \\
     \midrule{}%
     $pp\to  \ttb$ & \tablelinepp{4.588}{2}{6.740}{9}{2} \\
     $pp\to  \ttb j$ & \tablelinepp{3.131}{3}{4.194}{9}{2} \\
     $pp\to  \ttb\ttb$ & \tablelinepp{4.511}{2}{9.070}{9}{-3} \\
     $pp\to  \ttb Z$ & \tablelinepp{5.281}{8}{7.639}{9}{-1} \\
     & \\ & \\ & \\
     \bottomrule{}
  \end{tabular}
  \quad%
 \def1.05{1.05}
  \begin{tabular}{l l l l}
    \toprule{}%
    Process & $\sigma^{\text{LO}}[{\ensuremath\rm fb}]$ & $\sigma^{\text{NLO}}[{\ensuremath\rm fb}]$ & $K$ \\
    \midrule{}%
    $e^+e^-\to jj$ & \tableline{622.73}{4}{639.41}{9}{} \\
     $e^+e^-\to jjj$ & \tableline{342.4}{5}{318.6}{7}{} \\
     $e^+e^-\to jjjj$ & \tableline{105.1}{4}{103.0}{6}{} \\
     $e^+e^-\to jjjjj$ & \tableline{22.80}{2}{24.35}{15}{} \\

    \midrule{}%
     $e^+e^-\to\bbb$ & \tableline{92.32}{1}{94.78}{7}{} \\
     $e^+e^-\to\bbb \bbb$ & \tableline{1.64}{2}{3.67}{4}{1} \\
     $e^+e^-\to\ttb$ & \tableline{166.4}{1}{174.53}{6}{} \\
     $e^+e^-\to\ttb j$ & \tableline{48.3}{2}{53.25}{6}{} \\
     $e^+e^-\to\ttb jj$ & \tableline{8.612}{8}{10.46}{6}{} \\
     $e^+e^-\to\ttb jjj$ & \tableline{1.040}{1}{1.414}{10}{} \\
     $e^+e^-\to\ttb \ttb$ & \tableline{6.463}{2}{11.91}{2}{4} \\
     $e^+e^-\to\ttb \ttb j$ & \tableline{2.722}{1}{5.250}{14}{5} \\
     $e^+e^-\to\ttb \bbb$ & \tableline{0.186}{1}{0.293}{2}{} \\
     \midrule{}%
     $e^+e^-\to \ttb H$ & \tableline{2.022}{3}{1.912}{3}{} \\
     $e^+e^-\to \ttb Hj$ & \tableline{0.2540}{9}{0.2664}{5}{} \\
     $e^+e^-\to \ttb Hjj$ & \tableline{2.666}{4}{3.144}{9}{2} \\
     $e^+e^-\to \ttb \gamma$ & \tableline{12.71}{4}{13.78}{4}{} \\
     $e^+e^-\to \ttb Z$ & \tableline{4.64}{1}{4.94}{1}{}\\
     $e^+e^-\to\ttb Z j$ & \tableline{0.610}{4}{0.6927}{14}{}\\
     $e^+e^- \to\ttb Z jj$ & \tableline{6.233}{8}{8.201}{14}{2}\\
     $e^+e^-\to\ttb W^\pm jj$ & \tableline{2.41}{1}{3.695}{9}{4}\\
     $e^+e^-\to\ttb \gamma \gamma$ & \tableline{0.382}{3}{0.420}{3}{} \\
     $e^+e^-\to \ttb \gamma Z$ & \tableline{0.220}{1}{0.240}{2}{}\\
     $e^+e^-\to\ttb \gamma H$ & \tableline{9.748}{6}{9.58}{7}{2} \\
     $e^+e^-\to \ttb Z Z$ & \tableline{3.756}{4}{4.005}{2}{2} \\
     $e^+e^-\to \ttb W^+ W^-$ & \tableline{0.1370}{4}{0.1538}{4}{} \\
     $e^+e^-\to \ttb H H$ & \tableline{1.367}{1}{1.218}{1}{2} \\
     $e^+e^-\to \tth Z$ & \tableline{3.596}{1}{3.581}{2}{2}\\
    \bottomrule{}
  \end{tabular}
\end{tiny}
\caption{\label{tab:nlo_comp}
  Selection of validated processes at LO and NLO QCD with
  \whizard. $e^+ e^-$ processes (left) are for 1 TeV fixed beams, $pp$
  processes are for 13 TeV. The scale is the scalar transverse energy,
  $H_T$. Jets are clustered with the anti-$k_T$ algorithm and jet
  radius $\Delta R = 0.5$, with cuts of $p_T > 30 GeV$ for the Born
  jets.}
\end{table}
amplitudes for SMEFT dim-6/dim-8 operators and simplified
models~\cite{Beyer:2006hx,Alboteanu:2008my,Kilian:2014zja,Kilian:2015opv,Fleper:2016frz,Brass:2018hfw},
while precision SM predictions for VBS
can be found in~\cite{Ballestrero:2018anz}. Ongoing work deals with
the automatic calculation of unitarity limits for multiple
(transversal) vector boson production both for hadron and
(high-energy) lepton colliders.

Nowadays, new physics models are almost exclusively included via
automated interfaces, e.g. to
\texttt{FeynRules}~\cite{Christensen:2010wz,Christensen:2008py}.
These explicit interfaces have now been superseded by \whizard's
implementation of its UFO~\cite{Degrande:2011ua}
interface. \whizard\ now (with the upcoming
versions 2.8.3 and 3.0$\alpha$) supports this completely including
spins 1/2, 3/2, 0, 1, 2, 3, 4, 5, automatic construction of 5-, 6-ary
and even higher vertices, fermion-number violating vertices,
four-fermion vertices (and higher), SLHA-type input files for BSM
models and customized propagators defined in the UFO files. This makes
the old interfaces to FeynRules and SARAH~\cite{Staub:2013tta}
deprecated, however, they will be kept for backwards compatibility.

\subsection{Next-to-leading order QCD automation}
\label{sec:nlo}

\whizard\ started first with hard-coded next-to-leading order (NLO)
projects regarding QED and electroweak corrections for SUSY
production~\cite{Kilian:2006cj,Robens:2008sa} and NLO QCD correction for $pp \to
b\bar{b}b\bar{b}$~\cite{Binoth:2009rv,Greiner:2011mp}. Now,
\whizard\ is based on an automated implementation of the FKS
subtraction algorithm~\cite{Frixione:1995ms}. In this automated
implementation only the virtual amplitudes are external from one-loop
providers (OLP, there are interfaces to
\texttt{Openloops}~\cite{Cascioli:2011va,Buccioni:2019sur},
\texttt{Recola}~\cite{Actis:2016mpe} and
\texttt{GoSam}~\cite{Cullen:2014yla}), while subtraction terms are
automatically generated in \whizard.
The NLO QCD has been fully validated as can be seen from
Table~\ref{tab:nlo_comp}. First applications of this automated
interface have been devoted to linear collider top physics in the
continuum~\cite{Nejad:2016bci} and in the threshold
region~\cite{Bach:2017ggt}. These examples also show NLO calculations
with factorized processes as well as NLO QCD decays. Recently, the
selection of heavy-flavor jets in the jet clustering (bottom and charm)
as well as a veto for them has been added, and also the possibility
for photon isolation to separate perturbative QCD from nonperturbative
effects in photon-jet fragmentation. The final validation is being
finished now, there are still a few ongoing issues especially
regarding easier usage, but an alpha version of \whizard\ 3.0
officially releasing NLO QCD automation will be done in March
2020. \whizard\ allows for a completely automatized POWHEG-type
matching (and damping)~\cite{Reuter:2016qbi} to the parton shower (for
final state showering). While the corresponding matching for
initial-state showering is being implemented, the work on NLO
electroweak corrections has been started and first total cross
sections for simple processes are already available. Next steps here
are the complete validation, as well as the proper matching to the
higher-order corrections for incoming electron PDFs. Also, the work
for other NLO matching schemes has started.

\subsection{Summary and Outlook}

This is a status report of the close-to-final release version
2.8.2/2.8.3 of the \whizard\ version 2 series, showing intense work on
the complete NLO QCD automation, the completion of
automatic generation of arbitrary Lorentz tensor representations and
the UFO interface, and many technical and convenience developments
driven by the upcoming 250 GeV full SM Monte Carlo mass production for
ILC with 2 ab${}^{-1}$ integrated luminosity.

\section*{Acknowledgments}

This work was funded by the Deutsche Forschungsgemeinschaft under
Germany’s ExcellenceStrategy – EXC 2121 “Quantum Universe” –
390833306. JRR wants to thank the organizers for a fruitful and
interesting conference in Sendai, which was followed by an intense and
very productive LC generator group meeting at University of Tokyo.

\baselineskip15pt


\section{Introduction}

Gas dynamical processes are believed to play an important role in
the evolution of astrophysical systems on all length scales.
Smoothed particle hydrodynamics~(SPH) is a powerful gridless
particle method to solve complex fluid-dynamical problems. SPH
has a number of attractive features such as its low numerical
diffusion in comparison to grid based methods. An adequate
scenario for SPH application is the unbound astrophysical
problems, especially on the shock propagation~(see, e.g., Liu \&
Liu 2003). In this way, the basic principles of the SPH is
written in this paper and the simulation of isothermal and
adiabatic shocks are applied to test the ability of this numerical
simulation to produce known analytic solutions.

The program is written in Fortran and is highly portable. This
package supports only calculations for isothermal and adiabatic
shock waves. It is possible to change (to complete) the program
for a wide variety of applications ranging from astrophysics to
fluid mechanics. The program is written in modular form, in the
hope that it will provide a useful tool. I ask only that:
\begin{itemize}
  \item If you publish results obtained using some parts of this
  program, please consider acknowledging the source of the
  package.
  \item If you discover any errors in the program or
  documentation, please promptly communicate the to the author.
\end{itemize}

\section{Formulation of Shock Waves}

An extremely important problem is the behavior of gases subjected
to compression waves. This happens very often in the cases of
astrophysical interests. For example, a small region of gas
suddenly heated by the liberation of energy will expand into its
surroundings. The surroundings will be pushed and compressed.
Conservation of mass, momentum, and energy across a shock front
is given by the Rankine-Hugoniot conditions~(Dyson \& Williams
1997)
\begin{equation}\label{e:rh1}
\rho_1 v_1=\rho_2 v_2
\end{equation}
\begin{equation}
\rho_1 v_1^2+ K\rho_1^\gamma =\rho_2 v_2^2+ K\rho_2^\gamma
\end{equation}
\begin{equation}\label{e:rh3}
\frac{1}{2}v_1^2 + \frac{\gamma}{\gamma-1} K \rho_1^{\gamma-1}=
\frac{1}{2}v_2^2 + \frac{\gamma}{\gamma-1} K \rho_2^{\gamma-1} +Q
\end{equation}
where the equation of state, $p=K\rho^\gamma$, is used. In
adiabatic case, we have $Q=0$, and for isothermal shocks, we will
set $\gamma=1$.

We would interested to consider the collision of two gas sheets
with velocities $v_0$ in the rest frame of the laboratory. In this
reference frame, the post-shock will be at rest and the pre-shock
velocity is given by $v_1=v_0+v_2$, where $v_2$ is the shock front
velocity. Combining equations (\ref{e:rh1})-(\ref{e:rh3}), we have
\begin{equation}\label{e:v2}
v_2=a_0[-\frac{b}{2}+\sqrt{1+\frac{b^2}{4}+(\gamma-1)
(\frac{M_0^2}{2}-q)}]
\end{equation}
where $a_0\equiv \gamma K\rho_1 ^{\gamma-1}$ is the sound speed,
$M_0\equiv v_0/a_0$ is the Mach number, $b$ and $q$ are defined as
\begin{equation}
b\equiv \frac{3-\gamma}{2}M_0+ \frac{\gamma-1}{M_0}q\quad ;\quad
q\equiv \frac{Q}{a_0^2}.
\end{equation}
Substituting (\ref{e:v2}) into equation (\ref{e:rh1}), density of
the post-shock is given by
\begin{equation}\label{e:den}
\rho_2=\rho_1\{1+\frac{M_0}{[-\frac{b}{2}+\sqrt{1+\frac{b^2}{4}+(\gamma-1)
(\frac{M_0^2}{2}-q)}]}\}.
\end{equation}

\section{SPH Equations}

The smoothed particle hdrodynamics was invented to simulate
nonaxisymmetric phenomena in astrophysics~(Lucy 1977, Gingold \&
Monaghan 1977). In this method, fluid is represented by $N$
discrete but extended/smoothed particles (i.e. Lagrangian sample
points). The particles are overlapping, so that all the physical
quantities involved can be treated as continues functions both in
space and time. Overlapping is represented by the kernel
function, $W_{ab} \equiv W(\textbf{r}_a-\textbf{r}_b,h_{ab})$,
where $h_{ab} \equiv (h_a+h_b)/2$ is the mean smoothing length of
two particles $a$ and $b$. The continuity, momentum and energy
equation of particle $a$ are~(Monaghan 1992)
\begin{equation}
\rho_a=\sum_b m_b W_{ab}
\end{equation}
\begin{equation}
\frac{d\textbf{v}_a}{dt}=-\sum_b m_b (\frac{p_a}{\rho_a}+
\frac{p_b}{\rho_b}+ \Pi_{ab}) \nabla_a W_{ab}
\end{equation}
\begin{equation}
\frac{du_a}{dt}=\frac{1}{2} \sum_b m_b (\frac{p_a}{\rho_a}+
\frac{p_b}{\rho_b}+ \Pi_{ab}) \textbf{v}_{ab} \cdot \nabla_a
W_{ab}
\end{equation}
where $\textbf{v}_{ab}\equiv \textbf{v}_a- \textbf{v}_b$ and
\begin{equation}
\Pi_{ab}=\cases{
       \frac{\alpha v_{sig} \mu_{ab}
       +\beta \mu_{ab}^2}{\bar{\rho}_{ab}}, &
       if $\textbf{v}_{ab}.\textbf{r}_{ab}<0$,\cr
       0 , & otherwise,}
\end{equation}
is the artificial viscosity between particles $a$ and $b$, where
$\bar{\rho}_{ab}= \frac{1}{2}(\rho_a+\rho_b)$ is an average
density, $\alpha\sim 1$ and $\beta\sim 2$ are the artificial
coefficients, and $\mu_{ab}$ is defined as its usual form
\begin{equation}
\mu_{ab}=-\frac{\textbf{v}_{ab}
\cdot\textbf{r}_{ab}}{\bar{h}_{ab}}
\frac{1}{r_{ab}^2/\bar{h}_{ab}^2+\eta^2}
\end{equation}
with $\eta\sim 0.1$ and $\bar{h}_{ab}= \frac{1}{2}(h_a+h_b)$. The
signal velocity, $v_{sig}$, is
\begin{equation}
v_{sig}=\frac{1}{2}(c_a+c_b)
\end{equation}
where $c_a$ and $c_b$ are the sound speed of particles. The SPH
equations are integrated using the smallest time-steps
\begin{equation}
\Delta t_a=C_{cour}MIN[ \frac{h_a}{\mid \textbf{v}_a\mid},
(\frac{h_1}{\mid\textbf{a}_1\mid})^{0.5}, \frac{u_a}{\mid du_a/dt
\mid}, \frac{h_a}{\mid dh_a/dt \mid}, \frac{\rho_a}{\mid
d\rho_a/dt \mid}]
\end{equation}
where $C_{cour}\sim 0.25$ is the Courant number.

\section{Results and Prospects}

The chosen physical scales for length and time are $[l]=3.0 \times
10^{16} m$ and $[t]=3.0 \times 10^{13} s$, respectively, so the
velocity unit is approximately $1km.s^{-1}$. The gravity constant
is set $G= 1$ for which the calculated mass unit is $[m]=4.5
\times 10^{32} kg$. There is considered two equal one dimensional
sheets with extension $x= 0.1 [l]$, which have initial uniform
density and temperature of $\sim 4.5\times 10^8 m^{-3}$ and $\sim
10K$, respectively.

Particles with a positive x-coordinate are given an initial
negative velocity of Mach 5, and those with a negative
x-coordinate are given a Mach 5 velocity in the opposite
direction. In adiabatic shock, with $M_0=5$, the post-shock
density must be $2.9$, which is obtained from analytic solution
(\ref{e:den}) with $Q=0$ and $\gamma=2$. The Results of adiabatic
shock are shown in Fig.~1-3. In isothermal shock, with $M_0=5$,
the post-shock density must be $26.9$, which is obtained from
analytic solution Equ.~(\ref{e:den}) with $\gamma=1$. The Results
of isothermal shock are shown in Fig.~4-5. Algorithm of the
program is shown in Fig.~6.