The Communications of the TEX Users Group Volume 30 ... - TUG

More documents

Recommendations

Info

$E-m: Guidelines for Future TEX Extensions - TUG$

$TUG 2001: A TEX Odyssey PROGRAM$

$LATEX Sophisticated professional typesetting for business and ...$

$TEX and Scripting Languages - TUG$

$Geometric Diversions with TEX, METAFONT and METAPOST - TUG$

$Writing Gregg Shorthand with mEtaFoNt and LATEX - TUG$

$Generating LaTeX documents through Matlab - TUG$

190 TUGboat, Volume 30 (2009), No. 2 they do different things. Instead I decided to look at differencesinenginesandcomparerunswithdifferent numbers of pages. That way we get an idea of how startup time influences overall performance. We look at pdfTEX, which is basically an 8-bit system, XE TEX, which uses external libraries and is Unicode, and LuaTEX which is also Unicode, but stays closer to traditional TEX but has to check for callbacks. In our measurement we use a really simple test document as we only want to see how the baseline performs. As not much content is processed, we focus on loading (startup), the output routine and page building, and some basic PDF generation. After all, it’s often a quick and dirty test that gives users their first impression. When looking at the times you need to keep in mind that XE TEX pipes to DVIPDFMx and can benefit from multiple cpu cores. All systems have differentmemorymanagementandgarbagecollection might influence performance (as demonstrated in an earlier chapter of the ‘mk’ document we can trace in detail how the runtime is distributed). As terminal output is a significant slowdown for TEX we run in batchmode. The test is as follows: \starttext \dorecurse{2000}{test\page} \stoptext On my laptop (Dell M90 with 2.3Ghz T76000 Core 2 and 4MB memory running Vista) I get the following results. The test script ran each test set 5 times and we show the fastest run so we kind of avoid interference with other processes that take time. In practice runtime differs quite a bit for similar runs, depending on the system load. The time is in seconds and between parentheses the number of pages per seconds is mentioned. engine 30 300 2000 10000 xetex 1.81 (16) 2.45 (122) 6.97 (286) 29.20 (342) pdftex 1.28 (23) 2.07 (144) 6.96 (287) 30.94 (323) luatex 1.48 (20) 2.36 (127) 7.85 (254) 34.34 (291) The next table shows the same test but this time on a 2.5Ghz E5420 quad core server with 16GB memory running Linux, but with 6 virtual machines idling in the background. All binaries are 64 bit. engine 30 300 2000 10000 xetex 0.92 (32) 1.89 (158) 8.74 (228) 42.19 (237) pdftex 0.49 (61) 1.14 (262) 5.23 (382) 24.66 (405) luatex 1.07 (27) 1.99 (150) 8.32 (240) 38.22 (261) A test demonstrated that for LuaTEX the 30 and 300 page runs take 70% more runtime with 32 bit binaries (recent binaries for these engines are available on the ConTEXt wiki contextgarden.net). When you compare both tables it will be clear that it is non-trivial to come to conclusions about Hans Hagen performances. But one thing is clear: LuaTEX with ConTEXt MkIV is not performing that badly compared to its cousins. The Unicode engines perform about the same and pdfTEX beats them significantly. Okay, I have to admit that in the meantime some cleanup of code in MkIV has happened and the Lua- TEX runs benefit from this, but on the other hand, the other engines are not hindered by callbacks. As I expect to use MkII less frequently optimizing the older code makes no sense. 5 Futures There is not much chance of LuaTEX itself becoming faster, although a few days before writing this Taco managed to speed up font inclusion in the backend code significantly (we’re talking about half a second to a second for the three documents used here). On the contrary, when we open up more mechanisms and have upgraded backend code it might actually be a bit slower. On the other hand, I expect to be able to clean up some more ConTEXt code, although we already got rid of some subsystems (like the rather flexible (mixed) font encoding, where each language could have multiple hyphenation patters, etc.). Also, although initial loading of math fonts might take a bit more time (as long as we use virtual Latin Modern math), font switching is more efficient now due to fewer families. But speedups in the ConTEXt code might be compensated for by more advanced mechanisms that call out to Lua. You will be surprised by how much speed can be improved by proper document encoding and proper styles. I can try to gain a couple more pages per second by more efficient code, but a user’s style that does an inefficient massive font switch for some 10 words per page easily compensates for that. When processing the present 10 page document in an editor (Scite) it takes some 2.7 seconds between hitting the processing key and the result showing up in Acrobat. I can live with that, especially when I keep in mind that my next computer will be faster. This is where we stand now. The three reports shown before give you an impression of the impact of LuaTEX on ConTEXt. To what extent is this reflected in the code base? Eventually most MkII files (with the mkii suffix) and MkIV files (with suffix mkiv) will differ and the number of files with the tex suffix will be fewer. Because they are and will be mostly downward compatible, styles and modules will be shared as much as possible. ⋄ Hans Hagen Pragma ADE http://pragma-ade.com
TUGboat, Volume 30 (2009), No. 2 191 ProofCheck: Writing and checking complete proofs in L ATEX Bob Neveln and Bob Alps Abstract ProofCheck is a system for writing and checking mathematical proofs. Theorems and proofs are contained in a plain TEX or L ATEX document. Parsing and proof checking are accomplished through Python programs which read the source file. A general explanation of the use and structure of the system and programs is provided and a sample proof is shown in detail. The work done by the authors has been based on standard sentence logic, a non-standard predicate logic and set theory with proper classes. Theorems and proofs based on other foundations may be checked if external data files are modified. Four such data files and their possible modifications are described. In addition, the extent to which the formal language can be shaped to accommodate an author’s preferences is discussed. 1 Introduction The purpose of ProofCheck is to enable mathematicians to write readable proofs that are computer checkable. Such readable, computer-checkable proofs could also be of value in the refereeing process. In a previous article [4] the system now called ProofCheck was described. Since then the system has been extendedinseveralways. Thenumberofinferencerules and common notions has been increased. A web site at www.proofcheck.org has been developed. Further, the system now works with L ATEX in addition to plain TEX. 2 Other systems Two well-known systems to which ProofCheck might be compared are HOL [2] and Mizar [5]. HOL(HigherOrderLogic)isacomputer-assisted theoremprovingsystemoperatingwithinthe OCAML environment. OCAML(Objective CAML)isanobjectoriented programming language which can be run interactively. Mathematical objects are treated as OCAML objects and mathematical theorems are stated in OCAML. Thus both ontology and syntax are subsumed by OCAML type theory. Theorems are proved by entering commands at the OCAML prompt or by running a script. Thus a proof consists of a record of OCAML commands. Mizar is also a language for stating proofs intended to be human-readable as well as computercheckable. Proofs are entered in ASCII text in the Mizar language. The language is extensive and based on a particular axiomatization of mathematics, Tarski-Grothendieck set theory. The system can also produce L ATEX output. These systems also tend to form closed mathematical systems. Proving a theorem using these systems means showing that the given theorem is provable within that system. 3 Features and goals TEX and L ATEX convert an author’s .tex source files into DVI or PDF output. ProofCheck works with thesesame.texsourcefiles. WhenusingProofCheck the work cycle is typically to run the parser and the checkerafterasuccessfulrunofTEXorL ATEX. Errors encountered in each case throw the author back into the text editor. ProofCheck is intended to be open with respect to mathematical foundations. When ProofCheck checks the proof of a theorem it shows that the theorem follows from definitions and other theorems which have been stated and parsed but not necessarily checked. An author does not need to commit to a particular axiom system. In their own mathematical work the authors use standard sentence logic, a non-standard predicate logic, and a set theory which admits proper classes— but none of these choices is required. Of course checkable-proofs are easier to write when there is an accumulated body of accepted propositions available for referral. This does constitute an implicit pressure to use the specific development already on the ProofCheck web-site. But nothing prevents an author from creating another one. We will post any such developments we receive. 4 Mathematical language For almost a century there has been general agreement that there is no obstacle in principle to writing mathematics in a formal language and therefore to checking proofs mechanically. One of the main obstacles in practice to stating definitions and theorems in a formal language is that the required sacrifice of syntactical freedom may be more than a mathematical author is willing to tolerate. In devising a usable proof-checking system therefore it is important to maximize syntactic freedom. ProofCheck is not built on any specific mathematical language. Instead, a context-free grammar is generated on the basis of whatever definitions have been made. The rules of grammar are based on syntactical ideas of A.P. Morse [3], and include a variation on Morse’s handling of second-order variables. Definitions are presumed to take the form (p ↔ q) for formulas and (x ≡ y) for terms. The set ProofCheck: Writing and checking complete proofs in L ATEX
Page 1 and 2: The Communications of the TEX Users
Page 3 and 4: 2009 Conference Proceedings TEX Use
Page 5 and 6: Tuesday July 28 TUG2009program 8:30
Page 7 and 8: TUGboat, Volume 30 (2009), No. 2 15
Page 39: TUGboat, Volume 30 (2009), No. 2 18
Page 91 and 92:
TUGboat, Volume 30 (2009), No. 2 24
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 152 and 153:
RIVER VALLEY TECHNOLOGIES TUG 2010:
Page 154 and 155:
304 TUGboat, Volume 30 (2009), No.
Page 156 and 157:
TUGBOAT Volume 30 (2009), No. 2 Int
show all

The Communications of the TEX Users Group Volume 30 ... - TUG

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?