DOCSLIB.ORG

Mathematical Journals As Reasoning Agents: Literature Review Contents

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Mathematical Journals as Reasoning Agents: Literature Review Contents Introduction ........................................................................................................................ 1 ACL2 ...................................................................................................................................... 7 ActiveMath .......................................................................................................................... 13 Aldor ...................................................................................................................................... 19 ArXiv ...................................................................................................................................... 22 CoCoA .................................................................................................................................. 24 Coq ......................................................................................................................................... 31 C−CoRN ............................................................................................................................... 40 DLMF ..................................................................................................................................... 42 FDL ......................................................................................................................................... 47 GAP ........................................................................................................................................ 51 GiNaC .................................................................................................................................... 61 HELM ..................................................................................................................................... 63 Hol 4 ....................................................................................................................................... 69 HR ........................................................................................................................................... 75 ©1988−2005 Wolfram Research, Inc. All rights reserved. ILTP ........................................................................................................................................ 78 Infty ........................................................................................................................................ 81 Isabelle ................................................................................................................................. 84 Macaulay 2 .......................................................................................................................... 91 Magma .................................................................................................................................. 97 Maple ..................................................................................................................................... 107 Mathematica ....................................................................................................................... 111 MathLang ............................................................................................................................. 116 MATHsAiD ........................................................................................................................... 119 Maxima ................................................................................................................................. 124 MBase ................................................................................................................................... 129 MIZAR ................................................................................................................................... 132 Nuprl ...................................................................................................................................... 139 OMDoc .................................................................................................................................. 152 Omega .................................................................................................................................. 159 OpenMath ............................................................................................................................ 166 Plural ..................................................................................................................................... 172 PVS ........................................................................................................................................ 174 QED ........................................................................................................................................ 182 Singular ................................................................................................................................ 183 Theorema ............................................................................................................................ 190 TPTP ...................................................................................................................................... 196 Yacas ..................................................................................................................................... 206 Conclusions ....................................................................................................................... 210 References .......................................................................................................................... 210 ©1988−2005 Wolfram Research, Inc. All rights reserved. Mathematical Journals as Reasoning Agents: Literature Review Florina Piroi, Bruno Buchberger, Camelia Rosenkranz Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Schloss Hagenberg, A4232 Hagenberg, Austria {F.Piroi, Bruno.Buchberger,Camelia.Rosenkranz}@risc.uni−linz.ac.at Version 2008−03−02 Abstract This report reviews the literature relevant for the research project "Math−Agents: Mathematical Journals as Reasoning Agents" proposed by Bruno Buchberger as a technology transfer project based on the results of the SFB Project "Scientific Comput− ing", in particular the project SFB 1302, "Theorema". The project aims at computer− supporting the refereeing process of mathematical journals by tools that are mainly based on automated reasoning and also at building up the knowledge archived in mathematical journals in such a way that they can act as interactive and active reason− ing agents later on. In this report, we review current mathematical software systems with a focus on the availability of tools that can contribute to the goals of the Math− Agents project. 1 Introduction 1.1 The Goals of the Math−Agents Project For making this technical report self−contained, we summarize here the goals of the project "Math−Agents: Mathematical Journals as Reasoning Agents" proposed in [Buchberger07]: Mathematical knowledge as currently stored by journals (in printed or electronic form) is not yet accessible to any logical processing. In the past three decades, automated reasoning tech− niques and software−technology have matured to the extent that it seems to be possible to automate or, at least computer−support, the essential knowledge processing activities mathemati− cal journals. We have the technology that should enable us to construct reasoning tools and to re−organize the knowledge contained in any mathematical journal in such a way that questions of the following type can be answered automatically or, at least, with significant computer−sup− 2 of the following type can be answered automatically or, at least, with significant computer−sup− port: è Originality | Is a given mathematical result already "contained" in the journal, i.e. can it be derived from the knowledge in the journal by "easy" (automated) reasoning? è Correctness | Is a result in a paper correct, i.e. can it be formally derived from the available knowledge (using the proof "script" given in the paper)? è Importance | Is the result important, i.e. how, where, and how often can it be used in the context of the available knowledge? è Completeness | Are all "easy" consequences of a given result drawn in the available knowledge context? è Similarity | Search for structurally similar results in all areas of available knowl− edge! Create a pattern. è Complete Knowledge | Draw all consequences of the available knowledge using the currently available reasoners. è Knowledge Reduction | Given (increasingly sophisticated) automated reasoners, from time to time, the amount of mathematical knowledge to be stored can be reduced to the propositions whose proof is not "easy" (w.r.t. the available auto− mated reasoning power) whereas all other knowledge can be reproduced quickly, by the available automated reasoners, on demand. è Generalization | Extract the abstract structure from available knowledge. For this, domains, schemes, functors, categories are important abstraction tools. è Minimal Prerequisites | Analyze existing mathematical propositions for mini− mal prerequisites necessary in their proof. è Trace History | Generate the successive versions of a given result (notion, proposition, problem, method) in the knowledge base over time. è Re−organize knowledge | Take (a part of) the given knowledge and re−struc− ture
Recommended publications
  • An Implementation of Python for Racket

    An Implementation of Python for Racket

    An Implementation of Python for Racket Pedro Palma Ramos António Menezes Leitão INESC-ID, Instituto Superior Técnico, INESC-ID, Instituto Superior Técnico, Universidade de Lisboa Universidade de Lisboa Rua Alves Redol 9 Rua Alves Redol 9 Lisboa, Portugal Lisboa, Portugal [email protected] [email protected] ABSTRACT Keywords Racket is a descendent of Scheme that is widely used as a Python; Racket; Language implementations; Compilers first language for teaching computer science. To this end, Racket provides DrRacket, a simple but pedagogic IDE. On the other hand, Python is becoming increasingly popular 1. INTRODUCTION in a variety of areas, most notably among novice program- The Racket programming language is a descendent of Scheme, mers. This paper presents an implementation of Python a language that is well-known for its use in introductory for Racket which allows programmers to use DrRacket with programming courses. Racket comes with DrRacket, a ped- Python code, as well as adding Python support for other Dr- agogic IDE [2], used in many schools around the world, as Racket based tools. Our implementation also allows Racket it provides a simple and straightforward interface aimed at programs to take advantage of Python libraries, thus signif- inexperienced programmers. Racket provides different lan- icantly enlarging the number of usable libraries in Racket. guage levels, each one supporting more advanced features, that are used in different phases of the courses, allowing Our proposed solution involves compiling Python code into students to benefit from a smoother learning curve. Fur- semantically equivalent Racket source code. For the run- thermore, Racket and DrRacket support the development of time implementation, we present two different strategies: additional programming languages [13].
  • The Machine That Builds Itself: How the Strengths of Lisp Family

    The Machine That Builds Itself: How the Strengths of Lisp Family

    Khomtchouk et al. OPINION NOTE The Machine that Builds Itself: How the Strengths of Lisp Family Languages Facilitate Building Complex and Flexible Bioinformatic Models Bohdan B. Khomtchouk1*, Edmund Weitz2 and Claes Wahlestedt1 *Correspondence: [email protected] Abstract 1Center for Therapeutic Innovation and Department of We address the need for expanding the presence of the Lisp family of Psychiatry and Behavioral programming languages in bioinformatics and computational biology research. Sciences, University of Miami Languages of this family, like Common Lisp, Scheme, or Clojure, facilitate the Miller School of Medicine, 1120 NW 14th ST, Miami, FL, USA creation of powerful and flexible software models that are required for complex 33136 and rapidly evolving domains like biology. We will point out several important key Full list of author information is features that distinguish languages of the Lisp family from other programming available at the end of the article languages and we will explain how these features can aid researchers in becoming more productive and creating better code. We will also show how these features make these languages ideal tools for artificial intelligence and machine learning applications. We will specifically stress the advantages of domain-specific languages (DSL): languages which are specialized to a particular area and thus not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. DSLs are particularly easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred to as the “programmable programming language.” We are convinced that Lisp grants programmers unprecedented power to build increasingly sophisticated artificial intelligence systems that may ultimately transform machine learning and AI research in bioinformatics and computational biology.
  • Bringing GNU Emacs to Native Code

    Bringing GNU Emacs to Native Code

    Bringing GNU Emacs to Native Code Andrea Corallo Luca Nassi Nicola Manca [email protected] [email protected] [email protected] CNR-SPIN Genoa, Italy ABSTRACT such a long-standing project. Although this makes it didactic, some Emacs Lisp (Elisp) is the Lisp dialect used by the Emacs text editor limitations prevent the current implementation of Emacs Lisp to family. GNU Emacs can currently execute Elisp code either inter- be appealing for broader use. In this context, performance issues preted or byte-interpreted after it has been compiled to byte-code. represent the main bottleneck, which can be broken down in three In this work we discuss the implementation of an optimizing com- main sub-problems: piler approach for Elisp targeting native code. The native compiler • lack of true multi-threading support, employs the byte-compiler’s internal representation as input and • garbage collection speed, exploits libgccjit to achieve code generation using the GNU Com- • code execution speed. piler Collection (GCC) infrastructure. Generated executables are From now on we will focus on the last of these issues, which con- stored as binary files and can be loaded and unloaded dynamically. stitutes the topic of this work. Most of the functionality of the compiler is written in Elisp itself, The current implementation traditionally approaches the prob- including several optimization passes, paired with a C back-end lem of code execution speed in two ways: to interface with the GNU Emacs core and libgccjit. Though still a work in progress, our implementation is able to bootstrap a func- • Implementing a large number of performance-sensitive prim- tional Emacs and compile all lexically scoped Elisp files, including itive functions (also known as subr) in C.
  • Omnipresent and Low-Overhead Application Debugging

    Omnipresent and Low-Overhead Application Debugging

    Omnipresent and low-overhead application debugging Robert Strandh [email protected] LaBRI, University of Bordeaux Talence, France ABSTRACT application programmers as opposed to system programmers. The state of the art in application debugging in free Common The difference, in the context of this paper, is that the tech- Lisp implementations leaves much to be desired. In many niques that we suggest are not adapted to debugging the cases, only a backtrace inspector is provided, allowing the system itself, such as the compiler. Instead, throughout this application programmer to examine the control stack when paper, we assume that, as far as the application programmer an unhandled error is signaled. Most such implementations do is concerned, the semantics of the code generated by the not allow the programmer to set breakpoints (unconditional compiler corresponds to that of the source code. or conditional), nor to step the program after it has stopped. In this paper, we are mainly concerned with Common Furthermore, even debugging tools such as tracing or man- Lisp [1] implementations distributed as so-called FLOSS, i.e., ually calling break are typically very limited in that they do \Free, Libre, and Open Source Software". While some such not allow the programmer to trace or break in important sys- implementations are excellent in terms of the quality of the tem functions such as make-instance or shared-initialize, code that the compiler generates, most leave much to be simply because these tools impact all callers, including those desired when it comes to debugging tools available to the of the system itself, such as the compiler.
  • Axiom / Fricas

    Axiom / Fricas

    Axiom / FriCAS Christoph Koutschan Research Institute for Symbolic Computation Johannes Kepler Universit¨atLinz, Austria Computer Algebra Systems 15.11.2010 Master's Thesis: The ISAC project • initiative at Graz University of Technology • Institute for Software Technology • Institute for Information Systems and Computer Media • experimental software assembling open source components with as little glue code as possible • feasibility study for a novel kind of transparent single-stepping software for applied mathematics • experimenting with concepts and technologies from • computer mathematics (theorem proving, symbolic computation, model based reasoning, etc.) • e-learning (knowledge space theory, usability engineering, computer-supported collaboration, etc.) • The development employs academic expertise from several disciplines. The challenge for research is interdisciplinary cooperation. Rewriting, a basic CAS technique This technique is used in simplification, equation solving, and many other CAS functions, and it is intuitively comprehensible. This would make rewriting useful for educational systems|if one copes with the problem, that even elementary simplifications involve hundreds of rewrites. As an example see: http://www.ist.tugraz.at/projects/isac/www/content/ publications.html#DA-M02-main \Reverse rewriting" for comprehensible justification Many CAS functions can not be done by rewriting, for instance cancelling multivariate polynomials, factoring or integration. However, respective inverse problems can be done by rewriting and produce human readable derivations. As an example see: http://www.ist.tugraz.at/projects/isac/www/content/ publications.html#GGTs-von-Polynomen Equation solving made transparent Re-engineering equation solvers in \transparent single-stepping systems" leads to types of equations, arranged in a tree. ISAC's tree of equations are to be compared with what is produced by tracing facilities of Mathematica and/or Maple.
  • How Lisp Systems Look Different in Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008)

    How Lisp Systems Look Different in Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008)

    How Lisp Systems Look Different In Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008) Adrian Dozsa Tudor Gˆırba Radu Marinescu Politehnica University of Timis¸oara University of Berne Politehnica University of Timis¸oara Romania Switzerland Romania [email protected] [email protected] [email protected] Abstract rently used in a variety of domains, like bio-informatics (BioBike), data mining (PEPITe), knowledge-based en- Many reverse engineering approaches have been devel- gineering (Cycorp or Genworks), video games (Naughty oped to analyze software systems written in different lan- Dog), flight scheduling (ITA Software), natural language guages like C/C++ or Java. These approaches typically processing (SRI International), CAD (ICAD or OneSpace), rely on a meta-model, that is either specific for the language financial applications (American Express), web program- at hand or language independent (e.g. UML). However, one ming (Yahoo! Store or reddit.com), telecom (AT&T, British language that was hardly addressed is Lisp. While at first Telecom Labs or France Telecom R&D), electronic design sight it can be accommodated by current language inde- automation (AMD or American Microsystems) or planning pendent meta-models, Lisp has some unique features (e.g. systems (NASA’s Mars Pathfinder spacecraft mission) [16]. macros, CLOS entities) that are crucial for reverse engi- neering Lisp systems. In this paper we propose a suite of Why Lisp is Different. In spite of its almost fifty-year new visualizations that reveal the special traits of the Lisp history, and of the fact that other programming languages language and thus help in understanding complex Lisp sys- borrowed concepts from it, Lisp still presents some unique tems.
  • Lisp Tutorial

    Lisp Tutorial

    Gene Kim 9/9/2016 CSC 2/444 Lisp Tutorial About this Document This document was written to accompany an in-person Lisp tutorial. Therefore, the information on this document alone is not likely to be sufficient to get a good understanding of Lisp. However, the functions and operators that are listed here are a good starting point, so you may look up specifications and examples of usage for those functions in the Common Lisp HyperSpec (CLHS) to get an understanding of their usage. Getting Started Note on Common Lisp Implementations I will use Allegro Common Lisp since it is what is used by Len (and my research). However, for the purposes of this class we won’t be using many (if any) features that are specific to common lisp implementations so you may use any of the common lisp implementations available in the URCS servers. If you are using any libraries that are implementation-specific for assignments in this class, I would strongly urge you to rethink your approach if possible. If we (the TAs) deem any of these features to be solving to much of the assigned problem, you will not receive full credit for the assignment. To see if a function is in the Common Lisp specifications see the Common Lisp HyperSpec (CLHS). Simply google the function followed by “clhs” to see if an entry shows up. Available Common Lisp implementations (as far as I know): - Allegro Common Lisp (acl or alisp will start an Allegro REPL) - CMU Common Lisp (cmucl or lisp will start a CMUCL REPL) - Steel Bank Common Lisp (sbcl will start an SBCL REPL) IDE/Editor It is not important for this class to have an extensive IDE since we will be working on small coding projects.
  • Allegro CL User Guide

    Allegro CL User Guide

    Allegro CL User Guide Volume 1 (of 2) version 4.3 March, 1996 Copyright and other notices: This is revision 6 of this manual. This manual has Franz Inc. document number D-U-00-000-01-60320-1-6. Copyright 1985-1996 by Franz Inc. All rights reserved. No part of this pub- lication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means electronic, mechanical, by photocopying or recording, or otherwise, without the prior and explicit written permission of Franz incorpo- rated. Restricted rights legend: Use, duplication, and disclosure by the United States Government are subject to Restricted Rights for Commercial Software devel- oped at private expense as specified in DOD FAR 52.227-7013 (c) (1) (ii). Allegro CL and Allegro Composer are registered trademarks of Franz Inc. Allegro Common Windows, Allegro Presto, Allegro Runtime, and Allegro Matrix are trademarks of Franz inc. Unix is a trademark of AT&T. The Allegro CL software as provided may contain material copyright Xerox Corp. and the Open Systems Foundation. All such material is used and distrib- uted with permission. Other, uncopyrighted material originally developed at MIT and at CMU is also included. Appendix B is a reproduction of chapters 5 and 6 of The Art of the Metaobject Protocol by G. Kiczales, J. des Rivieres, and D. Bobrow. All this material is used with permission and we thank the authors and their publishers for letting us reproduce their material. Contents Volume 1 Preface 1 Introduction 1.1 The language 1-1 1.2 History 1-1 1.3 Format
  • Ring (Mathematics) 1 Ring (Mathematics)

    Ring (Mathematics) 1 Ring (Mathematics)

    Ring (mathematics) 1 Ring (mathematics) In mathematics, a ring is an algebraic structure consisting of a set together with two binary operations usually called addition and multiplication, where the set is an abelian group under addition (called the additive group of the ring) and a monoid under multiplication such that multiplication distributes over addition.a[›] In other words the ring axioms require that addition is commutative, addition and multiplication are associative, multiplication distributes over addition, each element in the set has an additive inverse, and there exists an additive identity. One of the most common examples of a ring is the set of integers endowed with its natural operations of addition and multiplication. Certain variations of the definition of a ring are sometimes employed, and these are outlined later in the article. Polynomials, represented here by curves, form a ring under addition The branch of mathematics that studies rings is known and multiplication. as ring theory. Ring theorists study properties common to both familiar mathematical structures such as integers and polynomials, and to the many less well-known mathematical structures that also satisfy the axioms of ring theory. The ubiquity of rings makes them a central organizing principle of contemporary mathematics.[1] Ring theory may be used to understand fundamental physical laws, such as those underlying special relativity and symmetry phenomena in molecular chemistry. The concept of a ring first arose from attempts to prove Fermat's last theorem, starting with Richard Dedekind in the 1880s. After contributions from other fields, mainly number theory, the ring notion was generalized and firmly established during the 1920s by Emmy Noether and Wolfgang Krull.[2] Modern ring theory—a very active mathematical discipline—studies rings in their own right.
  • Aldor Generics in Software Component Architectures

    Aldor Generics in Software Component Architectures

    Aldor Generics in Software Component Architectures (Spine title: Aldor Generics in Software Component Architectures) (Thesis Format: Monograph) by Michael Llewellyn Lloyd Graduate Program in Computer Science Submitted in partial fulfillment of the requirements for the degree of Masters Faculty of Graduate Studies The University of Western Ontario London, Ontario October, 2007 c Michael Llewellyn Lloyd 2007 THE UNIVERSITY OF WESTERN ONTARIO FACULTY OF GRADUATE STUDIES CERTIFICATE OF EXAMINATION Supervisor Examiners Dr. Stephen M. Watt Dr. David Jeffrey Supervisory Committee Dr. Hanan Lutfiyya Dr. Eric Schost The thesis by Michael Llewellyn Lloyd entitled Aldor Generics in Software Component Architectures is accepted in partial fulfillment of the requirements for the degree of Masters Date Chair of the Thesis Examination Board ii Abstract With the introduction of the Generic Interface Definition Language(GIDL), Software Component Architectures may now use Parameterized types between languages at a high level. Using GIDL, generic programming to be used between programming modules written in different programming languages. By exploiting this mechanism, GIDL creates a flexible programming environment where, each module may be coded in a language appropriate to its function. Currently the GIDL architecture has been implemented for C++ and Java, both object-oriented languages which support com- pile time binding for generic types. This thesis examines an implementation of GIDL for the Aldor language, an imperative language with some aspects of functional pro- gramming, particularly suited for representing algebraic types. In particular, we ex- periment with Aldors implementation of runtime binding for generic types, and show how GIDL allows programmers to use a rich set of generic types across language barriers.
  • Adams Operations and Symmetries of Representation Categories Arxiv

    Adams Operations and Symmetries of Representation Categories Arxiv

    Adams operations and symmetries of representation categories Ehud Meir and Markus Szymik May 2019 Abstract: Adams operations are the natural transformations of the representation ring func- tor on the category of finite groups, and they are one way to describe the usual λ–ring structure on these rings. From the representation-theoretical point of view, they codify some of the symmetric monoidal structure of the representation category. We show that the monoidal structure on the category alone, regardless of the particular symmetry, deter- mines all the odd Adams operations. On the other hand, we give examples to show that monoidal equivalences do not have to preserve the second Adams operations and to show that monoidal equivalences that preserve the second Adams operations do not have to be symmetric. Along the way, we classify all possible symmetries and all monoidal auto- equivalences of representation categories of finite groups. MSC: 18D10, 19A22, 20C15 Keywords: Representation rings, Adams operations, λ–rings, symmetric monoidal cate- gories 1 Introduction Every finite group G can be reconstructed from the category Rep(G) of its finite-dimensional representations if one considers this category as a symmetric monoidal category. This follows from more general results of Deligne [DM82, Prop. 2.8], [Del90]. If one considers the repre- sentation category Rep(G) as a monoidal category alone, without its canonical symmetry, then it does not determine the group G. See Davydov [Dav01] and Etingof–Gelaki [EG01] for such arXiv:1704.03389v3 [math.RT] 3 Jun 2019 isocategorical groups. Examples go back to Fischer [Fis88]. The representation ring R(G) of a finite group G is a λ–ring.
  • H&Uctures and Representation Rings of Compact Connected Lie Groups

    H&Uctures and Representation Rings of Compact Connected Lie Groups

    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Elsevier - Publisher Connector JOURNAL OF PURE AND APPLIED ALGEBRA ELsEMER Journal of Pure and Applied Algebra 121 (1997) 69-93 h&uctures and representation rings of compact connected Lie groups Akimou Osse UniversitC de Neuchrftel I Mathkmatiques, Rue Emile Argand II, Ch-2007 Neuchatel, Switzerland Communicated by E.M. Friedlander; received 10 November 1995 Abstract We first give an intrinsic characterization of the I-rings which are representation rings of compact connected Lie groups. Then we show that the representation ring of a compact connected Lie group G, with its I-structure, determines G up to a direct factor which is a product of groups Sp(Z) or SO(21+ 1). This result is used to show that a compact connected Lie group is determined by its classifying space; different (and independent) proofs of this result have been given by Zabrodsky-Harper, Notbohm and Msller. Our technique also yields a new proof of a result of Jackowski, McClure and Oliver on self-homotopy equivalences of classifying spaces. @ 1997 Elsevier Science B.V. 1991 Math. Subj. Class.: 55R35, 55N15, 57TlO 1. Introduction Fix a compact connected Lie group G and let R(G) denote the free abelian group generated by the isomorphism classes of complex irreducible representations of G. With the multiplication induced by tensor products of representations, R(G) becomes a commutative ring with unit; it is called the (complex) representation ring of G. The correspondence G --+ R(G) is fknctorial, so that R(G) is an invariant of the Lie group G.