
\newpage
\begin{center}
{\Large\bf CONTENTS}
\end{center}

\hugeskip
\begin{tabbing}
Major \= minor header \= \hs{100mm} \= p\kill
{\bf I}   \> INTRODUCTION \>                               \>\ 2 \\[3mm]
{\bf II}  \> INSTALLATION GUIDE \\[2mm]
          \> {\bf 2.1} \> Installing MaGIC                 \>\ 6 \\[3mm]
          \> {\bf 2.2} \> Installing Xmagic                \>\ 9 \\[3mm]
{\bf III} \> USER'S GUIDE TO MaGIC \\[2mm]
          \> {\bf 3.1} \> A MaGIC Tutorial                 \> 12 \\[3mm]
          \> {\bf 3.2} \> The Menu Options                 \> 18 \\[3mm]
          \> {\bf 3.3} \> The Ugly Data Format             \> 26 \\[3mm]
          \> {\bf 3.4} \> An Xmagic Tutorial               \> 29 \\[3mm]
          \> {\bf 3.5} \> Xmagic Reference Guide           \> 32 \\[3mm]
{\bf IV}  \> MODELLING LOGIC \\[2mm]
          \> {\bf 4.1} \> Propositional Structures         \> 36 \\[3mm]
          \> {\bf 4.2} \> Vocabulary                       \> 41 \\[3mm]
          \> {\bf 4.3} \> Some Postulates and Systems      \> 43 \\[3mm]
{\bf V}   \> HOW IT WORKS \\[2mm]
          \> {\bf 5.1} \> Overview of the program          \> 49 \\[3mm]
          \> {\bf 5.2} \> Generating and Testing Matrices  \> 51 \\[3mm]
          \> {\bf 5.3} \> Transferred Refutations          \> 56 \\[3mm]
          \> {\bf 5.4} \> Parallelisation                  \> 60 \\[3mm]
{\bf VI}  \> SOME PERFORMANCE DATA \\[2mm]
          \> {\bf 6.1} \> The C8 Benchmark                 \> 63 \\[3mm]
          \> {\bf 6.2} \> The R10 and R12 Benchmarks       \> 65 \\[3mm]
          \> {\bf 6.3} \> The PW5 Benchmark                \> 66
\end{tabbing}

\newpage
\begin{center}
{\Large\bf I}

\vspace{2mm}
{\large\bf INTRODUCTION}
\end{center}

\vspace{15mm}
The program MaGIC (Matrix Generator for Implication Connectives) 
is intended as a tool for logical research.  It computes small 
algebras (normally with up to 14 elements) suitable for modelling 
certain non-classical logics.  Along the way, it eliminates from 
the output any algebra isomorphic to one already generated, thus 
returning only one from each isomorphism class.  Optionally, the 
user may specify a formula which is to be {\em invalid\/} in each 
structure found.  This enables MaGIC to be used for such purposes 
as showing invalidity of unwanted formul\ae, proving one system 
stronger than another and proving the independence of axioms.  It 
can also be used to generate all the small algebras modelling 
some chosen logic.  These can then be used as input for other 
programs: for instance, they can be used as a database for many 
purposes including those of refuting non-theorems.  They can also 
be presented in a human-readable format so that they may be 
perused, for example to suggest metatheorems to an imaginative 
logician or just to gain a ``feel" for this or that system.  MaGIC 
has already been used by the first author in the course of researches 
reported in \cite{SCon}, \cite{FMOD} and \cite{CADE}, while earlier 
prototypes of the program were essential to \cite{CDM}, \cite{SDM} and 
\cite{ACT}.\@  Output from MaGIC is also being used in work on theorem 
provers for non-classical logics along the lines of \cite{ATP}.

\smallskip
Searching for matrices of this kind is extremely difficult, since 
the na\I ve search space for $n\times n$ matrices is of size $n^{n^2}$, 
meaning that the problem grows explosively as $n$ increases.  It follows 
that sheer hardware performance is insufficient to advance any simple 
solution very far.  With a sophisticated generating algorithm such as 
that used in MaGIC, however, the situation is different.  As the size 
of the matrices increases the time taken per matrix generated also 
increases, but much more slowly than even we thought possible before 
such algorithms were developed.  Thus even a linear improvement in 
processing speed can now yield a noticable advance in generating 
capacity.  The present version of MaGIC was written to run under Unix on 
almost any machine, and has been parallelised to run on a shared 
memory multiprocessor such as the Sequent Symmetry on which it was 
actually developed.  The parallel program takes full advantage of the 
coarse grain parallelism inherent in the application to achieve speeds 
not otherwise reachable at anything like the price.  Moreover, the 
parallelism will easily scale up to make use of many more processors 
should they be available on larger machines now or in the future.  In 
parallelising the algorithm we made heavy use of the Portable Monitor 
Macro Package developed at the Argonne National Laboratories by members 
of the Advanced Computer Research Facility.  This allowed quick 
production of portable and reliable high level code.

\smallskip
Two programs are shipped in the package.  The first is simply called 
`magic' and runs the matrix generator with a teletype interface which 
works on just about any terminal.  It may be invoked with a switch `$-$x' 
which suppresses system calls and simplifies certain passages of dialogue 
in order to make it easy to interface MaGIC via pipes or over a network.  
The second program shipped is `xmagic' which is an X Windows front end 
managing the interface with `magic' while providing the advantages of 
a modern window-based environment for the user.  Our preferred setup is 
to run the X Windows front end locally on a workstation and have it talk 
through a pipe to MaGIC itself which is running remotely on a more 
powerful machine, perhaps using many processors in parallel.  This 
arrangement is very easily varied however: see the Installation Guide 
below.

\smallskip
One decision which had to be made early in the piece was whether 
to maximise flexibility or power.  MaGIC really works on just one 
connective, the implication ``$\CC$".  The matrices for other 
connectives are either read in from an input file or defined in 
terms of the given ones.  This means that quite a large amount of 
logic is assumed (see \S4 for an account of how much) so the 
range of systems for which MaGIC is suitable is somewhat 
restricted---only somewhat, be it noted, since the assumed logic 
is the relatively stable base invariant over many interesting 
logics.  The pay-off for this restriction in range is a great 
gain in efficiency, since features of the target logics can be 
used to prime the search space.  The problem of matrix generation 
is, as noted above, subject to a violent combinatorial explosion which 
starts rumbling when the matrices get to size 4$\times$4 and which 
defeats most algorithms at size 5$\times$5.  Space priming using 
logical properties is thus necessary to all known methods of generating 
larger models.  An outline of the technique will be found in \S5.  
In MaGIC we have tried to strike a balance between efficiency and range; 
if we have erred it is on the side of efficiency, since a program that 
does a hundred things, or even ten things, and does them well is better 
than one that offers a million varieties of nothing.  We are acutely aware 
that a program of this type {\em could\/} be generalised to produce 
algebraic structures meeting arbitrary specifications, but we feel that 
application-specific adaptations got by changing the IO and testing 
routines while leaving the core of the program untouched would typically 
out-perform a general-purpose generator.

\smallskip
\S2 of this exposition is the Installation Guide for MaGIC 1.1\@.  
In \S3 are some tutorials which we recommend as an introduction to 
using the program together with definitions and descriptions of the 
various menu options.  \S4 contains a brief discussion of the use of 
matrices to model propositional logics and of the kind of model for 
which MaGIC searches.  It also details the logics and fragments of 
logics available.  \S5 is an overview of the algorithm instantiated 
by MaGIC.  It is intended to be explanatory, and useful to anyone 
proposing to customise or adapt the program to their own purposes or 
to write their own model-generators using other techniques in place of 
ours.  Finally we give some records of MaGIC's performance indicating 
the degree of parallelisation achieved and the effects of various ways 
of using the program's features.

\smallskip
The following is a summary of the main differences between versions 1.0 and 
1.1 of MaGIC and of xmagic.
\begin{itemize}
\item MaGIC 1.1P has as an additional feature dynamic selection of the 
number of processes via menu option `\#'\@.  Unlike MaGIC 1.0P it does not 
hang if processes fail to be forked but extricates itself gracefully.
\item MaGIC 1.1 has more efficient definitions of the pre-defined logics 
than MaGIC 1.0, so it runs over 25\% faster on certain jobs.
\item The runtime statistics given by MaGIC 1.1 include cpu time as well 
as elapsed time if the header \verb|times.h| is available.
\item Xmagic 1.1 now does more checking that its settings accord with those 
of the MaGIC it is running.  One outcome is that it displays formulas as 
parsed by MaGIC rather than simply as typed by the user.
\item Xmagic 1.1 uses release 4 of Athena Widgets instead of release 3\@. 
One difference this makes is to the speed of the text widgets.  Another 
is that RETURN suffices to send selections---this is an alternative to 
using the \framebox{change} buttons.  Another welcome difference is 
that there is now no problem in popping down the popup sub-widgets.
\item There have been numerous cosmetic changes to xmagic.  Most obvious 
is that it has default colours instead of a monochrome display.
\end{itemize}
Several bugs in 1.0 have been fixed for 1.1\@.  The most important are as 
follows.
\begin{itemize}
\item In MaGIC 1.0 the action on satisfaction of user-defined axioms was 
incorrect so that certain good matrices failed to be found.  This is 
corrected in 1.1.
\item On certain very large jobs TRANSREF was (rarely) repeating itself so 
that some matrices were found twice.  This was a small bug but potentially 
serious as TR.c has applications beyond MaGIC.
\item MaGIC 1.1, unlike 1.0, stops on time even if no matrices are found.
\item MaGIC 1.1 does much better garbage collection in the routine for 
eliminating isomorphisms than did 1.0\@.  This speeds up execution a little 
and avoids some mysterious crashes.
\end{itemize}

\smallskip
In our experience, everyone who takes an interest in a program of this type 
which does something useful soon wants to know why it doesn't do something 
else.  MaGIC is so written that it is fairly easy to adapt it to search for 
models of different systems, having different connectives for instance.  
Changing the stock of user-defined axioms quite simple though not quite 
trivially so.  Adding a new pre-defined logic is rather more complicated 
but still not a major change.  Altering the list of pre-defined connectives 
is yet more intricate but still feasible.  As we urge again in \S3 below, 
please contact us if you want to customise MaGIC in any of these ways.  We 
will either change it for you (which may take a while) or, if you are an 
experienced C programmer, advise you on how to do it yourself.  As we also 
note below, alterations in MaGIC tend to require matching alterations to 
xmagic.  Hence doing it yourself could create incompatibilities between 
MaGIC and xmagic.  While we have no wish to discourage you from experimenting 
with similar code or from amending the program to suit your purposes---it is 
a research tool, after all, not a display piece---we do recommend that you 
enlist our co-operation if only in the interests of sanity.  Our address is:

\bigskip\begin{center}
Automated Reasoning Project \\
Australian National University \\
GPO Box 4, \ Canberra, \ A.C.T. 2601 \\
Australia \\[2mm]
gustav@arp.anu.oz.au, \ or \\
jks@arp.anu.oz.au
\end{center}
