doc-src/isac/jrocnik/eJMT-paper/jrocnik_eJMT.tex
author Jan Rocnik <jan.rocnik@student.tugraz.at>
Fri, 31 Aug 2012 20:02:40 +0200
changeset 42463 83abf12ee6fb
child 42464 1a411c68a582
permissions -rwxr-xr-x
merged ideas
     1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     2 % Electronic Journal of Mathematics and Technology (eJMT) %
     3 % style sheet for LaTeX.  Please do not modify sections   %
     4 % or commands marked 'eJMT'.                              %
     5 %                                                         %
     6 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     7 %                                                         %
     8 % eJMT commands                                           %
     9 %                                                         %
    10 \documentclass[12pt,a4paper]{article}%                    %
    11 \usepackage{times}                                        %
    12 \usepackage{amsfonts,amsmath,amssymb}                     %
    13 \usepackage[a4paper]{geometry}                            %
    14 \usepackage{fancyhdr}                                     %
    15 \usepackage{color}                                        %
    16 \usepackage[pdftex]{hyperref} % see note below            %
    17 \usepackage{graphicx}%                                    %
    18 \hypersetup{                                              %
    19     a4paper,                                              %
    20     breaklinks                                            %
    21 }                                                         %
    22 %                                                         %
    23 \newtheorem{theorem}{Theorem}                             %
    24 \newtheorem{acknowledgement}[theorem]{Acknowledgement}    %
    25 \newtheorem{algorithm}[theorem]{Algorithm}                %
    26 \newtheorem{axiom}[theorem]{Axiom}                        %
    27 \newtheorem{case}[theorem]{Case}                          %
    28 \newtheorem{claim}[theorem]{Claim}                        %
    29 \newtheorem{conclusion}[theorem]{Conclusion}              %
    30 \newtheorem{condition}[theorem]{Condition}                %
    31 \newtheorem{conjecture}[theorem]{Conjecture}              %
    32 \newtheorem{corollary}[theorem]{Corollary}                %
    33 \newtheorem{criterion}[theorem]{Criterion}                %
    34 \newtheorem{definition}[theorem]{Definition}              %
    35 \newtheorem{example}[theorem]{Example}                    %
    36 \newtheorem{exercise}[theorem]{Exercise}                  %
    37 \newtheorem{lemma}[theorem]{Lemma}                        %
    38 \newtheorem{notation}[theorem]{Notation}                  %
    39 \newtheorem{problem}[theorem]{Problem}                    %
    40 \newtheorem{proposition}[theorem]{Proposition}            %
    41 \newtheorem{remark}[theorem]{Remark}                      %
    42 \newtheorem{solution}[theorem]{Solution}                  %
    43 \newtheorem{summary}[theorem]{Summary}                    %
    44 \newenvironment{proof}[1][Proof]{\noindent\textbf{#1.} }  %
    45 {\ \rule{0.5em}{0.5em}}                                   %
    46 %                                                         %
    47 % eJMT page dimensions                                    %
    48 %                                                         %
    49 \geometry{left=2cm,right=2cm,top=3.2cm,bottom=4cm}        %
    50 %                                                         %
    51 % eJMT header & footer                                    %
    52 %                                                         %
    53 \newcounter{ejmtFirstpage}                                %
    54 \setcounter{ejmtFirstpage}{1}                             %
    55 \pagestyle{empty}                                         %
    56 \setlength{\headheight}{14pt}                             %
    57 \geometry{left=2cm,right=2cm,top=3.2cm,bottom=4cm}        %
    58 \pagestyle{fancyplain}                                    %
    59 \fancyhf{}                                                %
    60 \fancyhead[c]{\small The Electronic Journal of Mathematics%
    61 \ and Technology, Volume 1, Number 1, ISSN 1933-2823}     %
    62 \cfoot{%                                                  %
    63   \ifnum\value{ejmtFirstpage}=0%                          %
    64     {\vtop to\hsize{\hrule\vskip .2cm\thepage}}%          %
    65   \else\setcounter{ejmtFirstpage}{0}\fi%                  %
    66 }                                                         %
    67 %                                                         %
    68 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    69 %
    70 % Please place your own definitions here
    71 %
    72 
    73 % isac logos
    74 \def\isac{${\cal I}\mkern-2mu{\cal S}\mkern-5mu{\cal AC}$}
    75 \def\sisac{\footnotesize${\cal I}\mkern-2mu{\cal S}\mkern-5mu{\cal AC}$}
    76 
    77 \usepackage{color}
    78 \definecolor{lgray}{RGB}{238,238,238}
    79 
    80 %
    81 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    82 %                                                         %
    83 % How to use hyperref                                     %
    84 % -------------------                                     %
    85 %                                                         %
    86 % Probably the only way you will need to use the hyperref %
    87 % package is as follows.  To make some text, say          %
    88 % "My Text Link", into a link to the URL                  %
    89 % http://something.somewhere.com/mystuff, use             %
    90 %                                                         %
    91 % \href{http://something.somewhere.com/mystuff}{My Text Link}
    92 %                                                         %
    93 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    94 %
    95 \begin{document}
    96 %
    97 % document title
    98 %
    99 \title{Interactive Course Material by TP-based Programming}%
   100 %
   101 % Single author.  Please supply at least your name,
   102 % email address, and affiliation here.
   103 %
   104 \author{\begin{tabular}{c}
   105 \textit{Jan Ro\v{c}nik} \\
   106 jan.rocnik@student.tugraz.at \\
   107 IST, SPSC\\
   108 University of Technologie Graz\\
   109 Austria\end{tabular}
   110 }%
   111 %
   112 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   113 %                                                         %
   114 % eJMT commands - do not change these                     %
   115 %                                                         %
   116 \date{}                                                   %
   117 \maketitle                                                %
   118 %                                                         %
   119 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   120 %
   121 % abstract
   122 %
   123 \begin{abstract}
   124 
   125 Traditional course material in engineering disciplines lacks an
   126 important component, interactive support for step-wise problem
   127 solving. \textbf{TP} (Theorem-Proving) technology is appropriate for one part
   128 of such support, in checking user-input. For the other part of such
   129 support, guiding the learner towards a solution, another kind of
   130 technology is required. %TODO ... connect to prototype ...
   131 
   132 A prototype combines TP with a programming language, the latter
   133 interpreted in a specific way: certain statements in a program, called
   134 tactics, are treated as breakpoints where control is handed over to
   135 the user. An input formula is checked by TP (using logical context
   136 built up by the interpreter); and if a learner gets stuck, a program
   137 describing the steps towards a solution of a problem ``knows the next
   138 step''. This kind of interpretation is called Lucas-Interpretation for
   139 \emph{TP-based programming languages}.
   140 
   141 This paper describes the prototype's TP-based programming language
   142 within a case study creating interactive material for an advanced
   143 course in Signal Processing: implementation of definitions and
   144 theorems in TP, formal specification of a problem and step-wise
   145 development of the program solving the problem. Experiences with the
   146 work flow in iterative development with testing and identifying errors
   147 are described, too. The description clarifies the components missing
   148 in the prototype's language as well as deficiencies experienced during
   149 programming.
   150 \par
   151 These experiences are particularly notable, because the author is the
   152 first programmer using the language beyond the core team which
   153 developed the prototype's TP-based language interpreter.
   154 %
   155 \end{abstract}%
   156 %
   157 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   158 %                                                         %
   159 % eJMT command                                            %
   160 %                                                         %
   161 \thispagestyle{fancy}                                     %
   162 %                                                         %
   163 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   164 %
   165 % Please use the following to indicate sections, subsections,
   166 % etc.  Please also use \subsubsection{...}, \paragraph{...}
   167 % and \subparagraph{...} as necessary.
   168 %
   169 
   170 \section{Introduction}
   171 
   172 \paragraph{Didactics of mathematics} faces a specific issue, a gap between (1) introduction of math concepts and skills and (2) application of these concepts and skills, which usually are separated into different units in curricula (for good reasons). For instance, (1) teaching partial fraction decomposition is separated from (2) application for inverse Z-transform in signal processing.
   173 \par
   174 This gap is an obstacle for applying math as an fundamental thinking technology in engineering: In (1) motivation is lacking because the question ``What is this stuff good for?'' cannot be treated sufficiently, and in (2) the ``stuff'' is not available to students in higher semesters as widespread experience shows.
   175 
   176 \paragraph{Motivation} taken by this didactic issue on the one hand, and ongoing research and development on a novel kind of educational mathematics assistant at Graz University of Technology~\footnote{http://www.ist.tugraz.at/isac/} promising to scope with this issue on the other hand, several institutes are planning to join their expertise: the Institute for Information Systems and Computer Media (IICM), the Institute for Software Technology (IST), the Institutes for Mathematics, the Institute for Signal Processing and Speech Communication  (SPSC), the Institute for Structural Analysis and the Institute of Electrical Measurement and Measurement Signal Processing.
   177 \par This thesis is the first attempt to tackle the above mentioned issue, it focuses on Telematics, because these specific studies focus on mathematics in \emph{STEOP}, the introductory orientation phase in Austria. \emph{STEOP} is considered an opportunity to investigate the impact of {\sisac}'s prototype on the issue and others.
   178 
   179 The paper will use the problem in Fig.\ref{fig-gclc} as a
   180 running example:
   181 \begin{figure} [htb]
   182 \begin{center}
   183 %\includegraphics[width=120mm]{fig/newgen/isac-Ztrans-math.png}
   184 \caption{Step-wise problem solving guided by the TP-based program}
   185 \label{fig-interactive}
   186 \end{center}
   187 \label{fig-gclc}
   188 \end{figure}
   189 
   190 \section{\isac's Prototype for a Programming Language}\label{PL} 
   191 The prototype's language extends the executable fragment in the
   192 language of the theorem prover
   193 Isabelle~\cite{Nipkow-Paulson-Wenzel:2002}\footnote{http://isabelle.in.tum.de/}
   194 by tactics which have a specific role in Lucas-Interpretation.
   195 
   196 \subsection{The Executable Fragment of Isabelle's Language}\label{PL-isab}
   197 The executable fragment consists of data-type and function
   198 definitions.  It's usability even suggests that fragment for
   199 introductory courses \cite{nipkow-prog-prove}. HOL is a typed logic
   200 whose type system resembles that of functional programming
   201 languages. Thus there are
   202 \begin{description}
   203 \item[base types,] in particular \textit{bool}, the type of truth
   204 values, \textit{nat}, \textit{int}, \textit{complex}, and the types of
   205 natural, integer and complex numbers respectively in mathematics.
   206 \item[type constructors] allow to define arbitrary types, from
   207 \textit{set}, \textit{list} to advanced data-structures like
   208 \textit{trees}, red-black-trees etc.
   209 \item[function types,] denoted by $\Rightarrow$.
   210 \item[type variables,] denoted by $^\prime a, ^\prime b$ etc, provide
   211 type polymorphism. Isabelle automatically computes the type of each
   212 variable in a term by use of Hindley-Milner type inference
   213 \cite{pl:hind97,Milner-78}.
   214 \end{description}
   215 
   216 \textbf{Terms} are formed as in functional programming by applying
   217 functions to arguments. If $f$ is a function of type
   218 $\tau_1\Rightarrow \tau_2$ and $t$ is a term of type $\tau_1$ then
   219 $f\;t$ is a term of type~$\tau_2$. $t\;::\;\tau$ means that term $t$
   220 has type $\tau$. There are many predefined infix symbols like $+$ and
   221 $\leq$ most of which are overloaded for various types.
   222 
   223 HOL also supports some basic constructs from functional programming:
   224 {\it\label{isabelle-stmts}
   225 \begin{tabbing} 123\=\kill
   226 \>$( \; {\tt if} \; b \; {\tt then} \; t_1 \; {\tt else} \; t_2 \;)$\\
   227 \>$( \; {\tt let} \; x=t \; {\tt in} \; u \; )$\\
   228 \>$( \; {\tt case} \; t \; {\tt of} \; {\it pat}_1
   229   \Rightarrow t_1 \; |\dots| \; {\it pat}_n\Rightarrow t_n \; )$
   230 \end{tabbing} }
   231 \noindent \textit{The running example's program uses some of these elements
   232 (marked by {\tt tt-font} on p.\pageref{expl-program}): ${\tt
   233 let}\dots{\tt in}$ in lines $02 \dots 11$, as well as {\tt last} for
   234 lists and {\tt o} for functional (forward) composition in line
   235 $10$. In fact, the whole program is an Isabelle term with specific
   236 function constants like {\sc program}, {\sc Substitute} and {\sc
   237 Rewrite\_Set\_Inst} in lines $01$ and $10$ respectively.}
   238 
   239 % Terms may also contain $\lambda$-abstractions. For example, $\lambda
   240 % x. \; x$ is the identity function.
   241 
   242 \textbf{Formula} are terms of type \textit{bool}. There are the basic
   243 constants \textit{True} and \textit{False} and the usual logical
   244 connectives (in decreasing order of precedence): $\neg, \land, \lor,
   245 \rightarrow$.
   246 
   247 \textbf{Equality} is available in the form of the infix function $=$ of type $a \Rightarrow a \Rightarrow {\it bool}$. It also works for formulas, where it means ``if and only if''.
   248 
   249 \textbf{Quantifiers} are written $\forall x. \; P$ and $\exists x. \;
   250 P$.  Quantifiers lead to non-executable functions, so functions do not
   251 always correspond to programs, for instance, if comprising \\$(
   252 \;{\it if} \; \exists x.\;P \; {\it then} \; e_1 \; {\it else} \; e_2
   253 \;)$.
   254 
   255 \subsection{\isac's Tactics for Lucas-Interpretation}\label{PL-tacs}
   256 The prototype extends Isabelle's language by specific statements
   257 called tactics~\footnote{\sisac's tactics are different from
   258 Isabelle's tactics: the former concern steps in a calculation, the
   259 latter concern proof steps.}  and tacticals. For the programmer these
   260 statements are functions with the following signatures:
   261 
   262 \begin{description}
   263 \item[Rewrite:] ${\it theorem}\Rightarrow{\it term}\Rightarrow{\it
   264 term} * {\it term}\;{\it list}$:
   265 this tactic appplies {\it theorem} to a {\it term} yielding a {\it
   266 term} and a {\it term list}, the list are assumptions generated by
   267 conditional rewriting. For instance, the {\it theorem}
   268 $b\not=0\land c\not=0\Rightarrow\frac{a\cdot c}{b\cdot c}=\frac{a}{b}$
   269 applied to the {\it term} $\frac{2\cdot x}{3\cdot x}$ yields
   270 $(\frac{2}{3}, [x\not=0])$.
   271 
   272 \item[Rewrite\_Set:] ${\it ruleset}\Rightarrow{\it
   273 term}\Rightarrow{\it term} * {\it term}\;{\it list}$:
   274 this tactic appplies {\it ruleset} to a {\it term}; {\it ruleset} is
   275 a confluent and terminating term rewrite system, in general. If
   276 none of the rules ({\it theorem}s) is applicable on interpretation
   277 of this tactic, an exception is thrown.
   278 
   279 % \item[Rewrite\_Inst:] ${\it substitution}\Rightarrow{\it
   280 % theorem}\Rightarrow{\it term}\Rightarrow{\it term} * {\it term}\;{\it
   281 % list}$:
   282 % 
   283 % \item[Rewrite\_Set\_Inst:] ${\it substitution}\Rightarrow{\it
   284 % ruleset}\Rightarrow{\it term}\Rightarrow{\it term} * {\it term}\;{\it
   285 % list}$:
   286 
   287 \item[Substitute:] ${\it substitution}\Rightarrow{\it
   288 term}\Rightarrow{\it term}$:
   289 
   290 \item[Take:] ${\it term}\Rightarrow{\it term}$:
   291 this tactic has no effect in the program; but it creates a side-effect
   292 by Lucas-Interpretation (see below) and writes {\it term} to the
   293 Worksheet.
   294 
   295 \item[Subproblem:] ${\it theory} * {\it specification} * {\it
   296 method}\Rightarrow{\it argument}\;{\it list}\Rightarrow{\it term}$:
   297 this tactic allows to enter a phase of interactive specification
   298 of a theory ($\Re$, $\cal C$, etc), a formal specification (for instance,
   299 a specific type of equation) and a method (for instance, solving an
   300 equation symbolically or numerically).
   301 
   302 \end{description}
   303 The tactics play a specific role in
   304 Lucas-Interpretation~\cite{wn:lucas-interp-12}: they are treated as
   305 break-points and control is handed over to the user. The user is free
   306 to investigate underlying knowledge, applicable theorems, etc.  And
   307 the user can proceed constructing a solution by input of a tactic to
   308 be applied or by input of a formula; in the latter case the
   309 Lucas-Interpreter has built up a logical context (initialised with the
   310 precondition of the formal specification) such that Isabelle can
   311 derive the formula from this context --- or give feedback, that no
   312 derivation can be found.
   313 
   314 \subsection{Tacticals for Control of Interpretation}
   315 The flow of control in a program can be determined by {\tt if then else}
   316 and {\tt case of} as mentioned on p.\pageref{isabelle-stmts} and also
   317 by additional tacticals:
   318 \begin{description}
   319 \item[Repeat:] ${\it tactic}\Rightarrow{\it term}\Rightarrow{\it
   320 term}$: iterates over tactics which take a {\it term} as argument as
   321 long as a tactic is applicable (for instance, {\it Rewrite\_Set} might
   322 not be applicable).
   323 
   324 \item[Try:] ${\it tactic}\Rightarrow{\it term}\Rightarrow{\it term}$:
   325 if {\it tactic} is applicable, then it is applied to {\it term},
   326 otherwise {\it term} is passed on unchanged.
   327 
   328 \item[Or:] ${\it tactic}\Rightarrow{\it tactic}\Rightarrow{\it
   329 term}\Rightarrow{\it term}$:
   330 
   331 
   332 \item[@@:] ${\it tactic}\Rightarrow{\it tactic}\Rightarrow{\it
   333 term}\Rightarrow{\it term}$:
   334 
   335 \item[While:] ${\it term::bool}\Rightarrow{\it tactic}\Rightarrow{\it
   336 term}\Rightarrow{\it term}$:
   337 
   338 \end{description}
   339 
   340 no input / output --- Lucas-Interpretation
   341 
   342 .\\.\\.\\TODO\\.\\.\\
   343 
   344 \section{Development of a Program on Trial}\label{trial}
   345 
   346 \subsection{Mechanization of Math in Isabelle/ISAC\label{isabisac}}
   347 
   348 \paragraph{As mentioned in the introduction,} a prototype of an educational math assistant called {\sisac}\footnote{{\sisac}=\textbf{Isa}belle for \textbf{C}alculations, see http://www.ist.tugraz.at/isac/.} bridges the gap between (1) introducation and (2) application of mathematics: {\sisac} is based on Computer Theorem Proving (TP), a technology which requires each fact and each action justified by formal logic, so {{\sisac{}}} makes justifications transparent to students in interactive step-wise problem solving. By that way {\sisac} already can serve both:
   349 \begin{enumerate}
   350   \item Introduction of math stuff (in e.g. partial fraction decomposition) by stepwise explaining and exercising respective symbolic calculations with ``next step guidance (NSG)'' and rigorously checking steps freely input by students  --- this also in context with advanced applications (where the stuff to be taught in higher semesters can be skimmed through by NSG), and
   351   \item Application of math stuff in advanced engineering courses (e.g. problems to be solved by inverse Z-transform in a Signal Processing Lab) and now without much ado about basic math techniques (like partial fraction decomposition): ``next step guidance'' supports students in independently (re-)adopting such techniques.
   352 \end{enumerate}
   353 Before the question is answers, how {\sisac} accomplishes this task from a technical point of view, some remarks on the state-of-the-art is given, therefor follow up Section~\ref{emas}.
   354 
   355 \subsection{Educational Mathematics Assistants (EMAs)}\label{emas}
   356 
   357 \paragraph{Educational software in mathematics} is, if at all, based on Computer Algebra Systems (CAS, for instance), Dynamic Geometry Systems (DGS, for instance \footnote{GeoGebra http://www.geogebra.org} \footnote{Cinderella http://www.cinderella.de/}\footnote{GCLC http://poincare.matf.bg.ac.rs/~janicic/gclc/}) or spread-sheets. These base technologies are used to program math lessons and sometimes even exercises. The latter are cumbersome: the steps towards a solution of such an interactive exercise need to be provided with feedback, where at each step a wide variety of possible input has to be foreseen by the programmer - so such interactive exercises either require high development efforts or the exercises constrain possible inputs.
   358 
   359 \subparagraph{A new generation} of educational math assistants (EMAs) is emerging presently, which is based on Theorem Proving (TP). TP, for instance Isabelle and Coq, is a technology which requires each fact and each action justified by formal logic. Pushed by demands for \textit{proven} correctness of safety-critical software TP advances into software engineering; from these advancements computer mathematics benefits in general, and math education in particular. Two features of TP are immediately beneficial for learning:
   360 
   361 \paragraph{TP have knowledge in human readable format,} that is in standard predicate calculus. TP following the LCF-tradition have that knowledge down to the basic definitions of set, equality, etc~\footnote{http://isabelle.in.tum.de/dist/library/HOL/HOL.html}; following the typical deductive development of math, natural numbers are defined and their properties proven~\footnote{http://isabelle.in.tum.de/dist/library/HOL/Number\_Theory/Primes.html}, etc. Present knowledge mechanized in TP exceeds high-school mathematics by far, however by knowledge required in software technology, and not in other engineering sciences.
   362 
   363 \paragraph{TP can model the whole problem solving process} in mathematical problem solving {\em within} a coherent logical framework. This is already being done by three projects, by Ralph-Johan Back, by ActiveMath and by Carnegie Mellon Tutor.
   364 \par
   365 Having the whole problem solving process within a logical coherent system, such a design guarantees correctness of intermediate steps and of the result (which seems essential for math software); and the second advantage is that TP provides a wealth of theories which can be exploited for mechanizing other features essential for educational software.
   366 
   367 \subsubsection{Generation of User Guidance in EMAs}\label{user-guid}
   368 
   369 One essential feature for educational software is feedback to user input and assistance in coming to a solution.
   370 
   371 \paragraph{Checking user input} by ATP during stepwise problem solving is being accomplished by the three projects mentioned above exclusively. They model the whole problem solving process as mentioned above, so all what happens between formalized assumptions (or formal specification) and goal (or fulfilled postcondition) can be mechanized. Such mechanization promises to greatly extend the scope of educational software in stepwise problem solving.
   372 
   373 \paragraph{NSG (Next step guidance)} comprises the system's ability to propose a next step; this is a challenge for TP: either a radical restriction of the search space by restriction to very specific problem classes is required, or much care and effort is required in designing possible variants in the process of problem solving \cite{proof-strategies-11}.
   374 \par
   375 Another approach is restricted to problem solving in engineering domains, where a problem is specified by input, precondition, output and postcondition, and where the postcondition is proven by ATP behind the scenes: Here the possible variants in the process of problem solving are provided with feedback {\em automatically}, if the problem is described in a TP-based programing language:
   376 \cite{plmms10} the programmer only describes the math algorithm without caring about interaction (the respective program is functional and even has no input or output statements!); interaction is generated as a side-effect by the interpreter --- an efficient separation of concern between math programmers and dialog designers promising application all over engineering disciplines.
   377 
   378 
   379 \subsubsection{Math Authoring in Isabelle/ISAC\label{math-auth}}
   380 Authoring new mathematics knowledge in {\sisac} can be compared with ``application programing'' of engineering problems; most of such programing uses CAS-based programing languages (CAS = Computer Algebra Systems; e.g. Mathematica's or Maple's programing language).
   381 
   382 \paragraph{A novel type of TP-based language} is used by {\sisac{}} \cite{plmms10} for describing how to construct a solution to an engineering problem and for calling equation solvers, integration, etc~\footnote{Implementation of CAS-like functionality in TP is not primarily concerned with efficiency, but with a didactic question: What to decide for: for high-brow algorithms at the state-of-the-art or for elementary algorithms comprehensible for students?} within TP; TP can ensure ``systems that never make a mistake'' \cite{casproto} - are impossible for CAS which have no logics underlying.
   383 
   384 \subparagraph{Authoring is perfect} by writing such TP based programs; the application programmer is not concerned with interaction or with user guidance: this is concern of a novel kind of program interpreter called Lucas-Interpreter. This interpreter hands over control to a dialog component at each step of calculation (like a debugger at breakpoints) and calls automated TP to check user input following personalized strategies according to a feedback module.
   385 \par
   386 However ``application programing with TP'' is not done with writing a program: according to the principles of TP, each step must be justified. Such justifications are given by theorems. So all steps must be related to some theorem, if there is no such theorem it must be added to the existing knowledge, which is organized in so-called \textbf{theories} in  Isabelle. A theorem must be proven; fortunately Isabelle comprises a mechanism (called ``axiomatization''), which allows to omit proofs. Such a theorem is shown in Example~\ref{eg:neuper1}.
   387 
   388 \vbox{
   389   \begin{example}
   390   \label{eg:neuper1}
   391   {\small\begin{tabbing}
   392   123\=123\=123\=123\=\kill
   393   \hfill \\
   394   \>axiomatization where \\
   395   \>\>  rule1: ``1 = $\delta$ [n]'' and\\
   396   \>\>  rule2: ``$\vert\vert$ z $\vert\vert$ > 1 ==> z / (z - 1) = u [n]'' and\\
   397   \>\>  rule3: ``$\vert\vert$ z $\vert\vert$ < 1 ==> z / (z - 1) = -u [-n - 1]'' and \\
   398   \>\>  rule4: ``$\vert\vert$ z $\vert\vert$ > $\vert\vert$ $\alpha$ $\vert\vert$ ==> z / (z - $\alpha$) = $\alpha^n$ $\cdot$ u [n]'' and\\
   399   \>\>  rule5: ``$\vert\vert$ z $\vert\vert$ < $\vert\vert$ $\alpha$ $\vert\vert$ ==> z / (z - $\alpha$) = -($\alpha^n$) $\cdot$ u [-n - 1]'' and\\
   400   \>\>  rule6: ``$\vert\vert$ z $\vert\vert$ > 1 ==> z/(z - 1)$^2$ = n $\cdot$ u [n]''
   401   \end{tabbing}
   402   }
   403   \end{example}
   404 }
   405 
   406 In order to provide TP with logical facts for checking user input, the Lucas-Interpreter requires a \textbf{specification}. Such a specification is shown in Example~\ref{eg:neuper2}.
   407 
   408 \vbox{
   409   \begin{example}
   410   \label{eg:neuper2}
   411   {\small\begin{tabbing}
   412   123,\=postcond \=: \= $\forall \,A^\prime\, u^\prime \,v^\prime.\,$\=\kill
   413   \hfill \\
   414   Specification no.1:\\
   415   %\>input\>: $\{\;r={\it arbitraryFix}\;\}$  \\
   416   \>input    \>: $\{\;r\;\}$  \\
   417   \>precond  \>: $0 < r$   \\
   418   \>output   \>: $\{\;A,\; u,v\;\}$ \\
   419   \>postcond \>:{\small  $\;A=2uv-u^2 \;\land\; (\frac{u}{2})^2+(\frac{v}{2})^2=r^2 \;\land$}\\
   420   \>     \>\>{\small $\;\forall \;A^\prime\; u^\prime \;v^\prime.\;(A^\prime=2u^\prime v^\prime-(u^\prime)^2 \land
   421   (\frac{u^\prime}{2})^2+(\frac{v^\prime}{2})^2=r^2) \Longrightarrow A^\prime \leq A$} \\
   422   \>props\>: $\{\;A=2uv-u^2,\;(\frac{u}{2})^2+(\frac{v}{2})^2=r^2\;\}$
   423   \end{tabbing}
   424   }
   425   \end{example}
   426 }
   427 
   428 Such a specification is checked before the execution of a program is started, the same applies for sub-programs. In the following example (Example~\ref{eg:subprob}) shows the call of such a subproblem:
   429 
   430 \vbox{
   431   \begin{example}
   432   \label{eg:subprob}
   433   \hfill \\
   434   {\ttfamily \begin{tabbing}
   435   ``(L\_L::bool list) = (\=SubProblem (\=Test','' \\
   436   ``\>\>[linear,univariate,equation,test],'' \\
   437   ``\>\>[Test,solve\_linear])'' \\
   438   ``\>[BOOL equ, REAL z])'' \\
   439   \end{tabbing}
   440   }
   441   {\small\textit{
   442     \noindent If a program requires a result which has to be calculated first we can use a subproblem to do so. In our specific case we wanted to calculate the zeros of a fraction and used a subproblem to calculate the zeros of the denominator polynom.
   443     }}
   444   \end{example}
   445 }
   446 
   447 \section{Workflow of Programming in the Prototype}\label{workflow}
   448 
   449 \subsection{Formalization of missing knowledge in Isabelle}
   450 
   451 \paragraph{A problem} behind is the mechanization of mathematic theories in TP-bases languages. There is still a huge gap between these algorithms and this what we want as a solution - in Example Signal Processing. 
   452 
   453 \vbox{
   454   \begin{example}
   455     \label{eg:gap}
   456     \[
   457       X\cdot(a+b)+Y\cdot(c+d)=aX+bX+cY+dY
   458     \]
   459     {\small\textit{
   460       \noindent A very simple example on this what we call gap is the simplification above. It is needles to say that it is correct and also Isabelle for fills it correct - \emph{always}. But sometimes we don't want expand such terms, sometimes we want another structure of them. Think of a problem were we now would need only the coefficients of $X$ and $Y$. This is what we call the gap between mechanical simplification and the solution.
   461     }}
   462   \end{example}
   463 }
   464 
   465 \paragraph{We are not able to fill this gap,} until we have to live with it but first have a look on the meaning of this statement: Mechanized math starts from mathematical models and \emph{hopefully} proceeds to match physics. Academic engineering starts from physics (experimentation, measurement) and then proceeds to mathematical modeling and formalization. The process from a physical observance to a mathematical theory is unavoidable bound of setting up a big collection of standards, rules, definition but also exceptions. These are the things making mechanization that difficult.
   466 
   467 \vbox{
   468   \begin{example}
   469     \label{eg:units}
   470     \[
   471       m,\ kg,\ s,\ldots
   472     \]
   473     {\small\textit{
   474       \noindent Think about some units like that one's above. Behind each unit there is a discerning and very accurate definition: One Meter is the distance the light travels, in a vacuum, through the time of 1 / 299.792.458 second; one kilogram is the weight of a platinum-iridium cylinder in paris; and so on. But are these definitions usable in a computer mechanized world?!
   475     }}
   476   \end{example}
   477 }
   478 
   479 \paragraph{A computer} or a TP-System builds on programs with predefined logical rules and does not know any mathematical trick (follow up example \ref{eg:trick}) or recipe to walk around difficult expressions. 
   480 
   481 \vbox{
   482   \begin{example}
   483     \label{eg:trick}
   484   \[ \frac{1}{j\omega}\cdot\left(e^{-j\omega}-e^{j3\omega}\right)= \]
   485   \[ \frac{1}{j\omega}\cdot e^{-j2\omega}\cdot\left(e^{j\omega}-e^{-j\omega}\right)=
   486      \frac{1}{\omega}\, e^{-j2\omega}\cdot\colorbox{lgray}{$\frac{1}{j}\,\left(e^{j\omega}-e^{-j\omega}\right)$}= \]
   487   \[ \frac{1}{\omega}\, e^{-j2\omega}\cdot\colorbox{lgray}{$2\, sin(\omega)$} \]
   488     {\small\textit{
   489       \noindent Sometimes it is also useful to be able to apply some \emph{tricks} to get a beautiful and particularly meaningful result, which we are able to interpret. But as seen in this example it can be hard to find out what operations have to be done to transform a result into a meaningful one.
   490     }}
   491   \end{example}
   492 }
   493 
   494 \paragraph{The only possibility,} for such a system, is to work through its known definitions and stops if none of these fits. Specified on Signal Processing or any other application it is often possible to walk through by doing simple creases. This creases are in general based on simple math operational but the challenge is to teach the machine \emph{all}\footnote{Its pride to call it \emph{all}.} of them. Unfortunately the goal of TP Isabelle is to reach a high level of \emph{all} but it in real it will still be a survey of knowledge which links to other knowledge and {\sisac{}} a trainer and helper but no human compensating calculator. 
   495 \par
   496 {{\sisac{}}} itself aims to adds an \emph{application} axis (formal specifications of problems out of topics from Signal Processing, etc.) and an \emph{algorithmic} axis to the \emph{deductive} axis of physical knowledge. The result is a three-dimensional universe of mathematics seen in Figure~\ref{fig:mathuni}.
   497 
   498   \begin{figure}
   499     \hfill \\
   500     \begin{center}
   501       \includegraphics{fig/universe}
   502       \caption{Didactic ``Math-Universe''\label{fig:mathuni}}
   503     \end{center}
   504   \end{figure}
   505 
   506 \subsection{Notes on Problems with Traditional Notation}
   507 
   508 \paragraph{During research} on these topic severely problems on traditional notations have been discovered. Some of them have been known in computer science for many years now and are still unsolved, one of them aggregates with the so called \emph{Lambda Calculus}, Example~\ref{eg:lamda} provides a look on the problem that embarrassed us.
   509 
   510 \vbox{
   511   \begin{example}
   512     \label{eg:lamda}
   513 
   514   \[ f(x)=\ldots\;  \quad R \rightarrow \quad R \]
   515 
   516 
   517   \[ f(p)=\ldots\;  p \in \quad R \]
   518 
   519     {\small\textit{
   520       \noindent Above we see two equations. The first equation aims to be a mapping of an function from the reel range to the reel one, but when we change only one letter we get the second equation which usually aims to insert a reel point $p$ into the reel function. In computer science now we have the problem to tell the machine (TP) the difference between this two notations. This Problem is called \emph{Lambda Calculus}.
   521     }}
   522   \end{example}
   523 }
   524 
   525 \paragraph{An other problem} is that terms are not full simplified in traditional notations, in {\sisac} we have to simplify them complete to check weather results are compatible or not. in e.g. the solutions of an second order linear equation is an rational in {\sisac} but in tradition we keep fractions as long as possible and as long as they aim to be \textit{beautiful} (1/8, 5/16,...).
   526 \subparagraph{The math} which should be mechanized in Computer Theorem Provers (\emph{TP}) has (almost) a problem with traditional notations (predicate calculus) for axioms, definitions, lemmas, theorems as a computer program or script is not able to interpret every Greek or Latin letter and every Greek, Latin or whatever calculations symbol. Also if we would be able to handle these symbols we still have a problem to interpret them at all. (Follow up \hbox{Example \ref{eg:symbint1}})
   527 
   528 \vbox{
   529   \begin{example}
   530     \label{eg:symbint1}
   531     \[
   532       u\left[n\right] \ \ldots \ unitstep
   533     \]
   534     {\small\textit{
   535       \noindent The unitstep is something we need to solve Signal Processing problem classes. But in {{\sisac{}}} the   rectangular brackets have a different meaning. So we abuse them for our requirements. We get something which is not defined, but usable. The Result is syntax only without semantic.
   536     }}
   537   \end{example}
   538 }
   539 
   540 In different problems, symbols and letters have different meanings and ask for different ways to get through. (Follow up \hbox{Example \ref{eg:symbint2}}) 
   541 
   542 \vbox{
   543   \begin{example}
   544     \label{eg:symbint2}
   545     \[
   546       \widehat{\ }\ \widehat{\ }\ \widehat{\ } \  \ldots \  exponent
   547     \]
   548     {\small\textit{
   549     \noindent For using exponents the three \texttt{widehat} symbols are required. The reason for that is due the development of {{\sisac{}}} the single \texttt{widehat} and also the double were already in use for different operations.
   550     }}
   551   \end{example}
   552 }
   553 
   554 \paragraph{Also the output} can be a problem. We are familiar with a specified notations and style taught in university but a computer program has no knowledge of the form proved by a professor and the machines themselves also have not yet the possibilities to print every symbol (correct) Recent developments provide proofs in a human readable format but according to the fact that there is no money for good working formal editors yet, the style is one thing we have to live with.
   555 
   556 \section{Problems rising out of the Development Environment}
   557 
   558 fehlermeldungen! TODO
   559 
   560 \section{Conclusion}
   561 
   562 TODO
   563 
   564 \bibliographystyle{alpha}
   565 \bibliography{references}
   566 
   567 \end{document}