├── .gitignore ├── Makefile ├── README.md ├── SCRAP_references_complex.bib ├── abstract.tex ├── acks.tex ├── algorithms ├── COPYING ├── README ├── THANKS ├── algorithm.sty ├── algorithmic.sty ├── algorithms.dtx ├── algorithms.ins ├── algorithms.log └── algorithms.pdf ├── appa.tex ├── appb.tex ├── appendix.sty ├── bussproofs.sty ├── chap1-notes.tex ├── chap1.tex ├── chap2.tex ├── chap3.tex ├── chap4.tex ├── chap5.tex ├── chap6.tex ├── contents.tex ├── cover.tex ├── doublespace.sty ├── fullpage.sty ├── lgrind.sty ├── main.bib ├── main.pdf ├── main.tex ├── mainj.tex ├── mainjp.tex ├── mitthesis.cls ├── notes ├── outline.tex ├── outlines.sty ├── proposal ├── .gitignore ├── fullpage.sty ├── proposal.bib └── proposal.tex ├── tocbibind.sty └── todonotes.sty /.gitignore: -------------------------------------------------------------------------------- 1 | *.aux 2 | *.fdb_latexmk 3 | *.fls 4 | *.lof 5 | *.log 6 | *.lot 7 | *.out 8 | *.toc 9 | *.blg 10 | *.bbl 11 | 12 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | pdf: 2 | latexmk -pdf main 3 | 4 | clean: 5 | rm -vf *.aux *.fls *.fdb_latexmk *.log *.toc main.pdf 6 | 7 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/JeffBezanson/phdthesis/876be73a5aab9b034fac3eb9ea9d8f96713f786f/README.md -------------------------------------------------------------------------------- /SCRAP_references_complex.bib: -------------------------------------------------------------------------------- 1 | %% This BibTeX bibliography file was created using BibDesk. 2 | %% http://bibdesk.sourceforge.net/ 3 | 4 | 5 | %% Created for Jiahao Chen at 2014-02-01 14:33:16 -0500 6 | 7 | 8 | %% Saved with string encoding Unicode (UTF-8) 9 | 10 | 11 | 12 | @article{Hamilton:1837nr, 13 | Annote = {This is the paper presented in 1833 at the Royal Irish Academy about complex numbers. 14 | 15 | "The third part, The Theory of Conjugate Functions, or Algebraic Couples, defines complex numbers as `algebraic couples', which are ordered pairs of real numbers, with appropriately defined operations of addition, subtraction, multiplication and division. Hamilton gives a careful proof of basic properties of the exponential function, and discusses the nature of logarithms, providing a natural framework to justify results obtained by his friend John T. Graves concerning complex logarithms which had been questioned by eminent British mathematicians such as Peacock and Herschel."}, 16 | Author = {William Rowan Hamilton}, 17 | Date-Added = {2014-02-01 18:28:24 +0000}, 18 | Date-Modified = {2014-02-01 19:23:53 +0000}, 19 | Journal = {Transactions of the Royal Irish Academy}, 20 | Pages = {293-422}, 21 | Title = {Theory of Conjugate Functions, or Algebraic Couples; with a Preliminary and Elementary Essay on Algebra as the Science of Pure Time.}, 22 | Url = {http://www.maths.tcd.ie/pub/HistMath/People/Hamilton/PureTime/}, 23 | Volume = {17}, 24 | Year = {1837}} 25 | 26 | @inbook{Apostol:1967bh, 27 | Annote = {Describes the relationship between real numbers and complex numbers in two different ways: first, the complex numbers as an extension of the real numbers, and second, the real numbers as isomorphic with a subset of the complex numbers,. 28 | 29 | Could be a useful example of "leaky isomorphism": embedding two things that look superficially identical but sometimes have very different behaviors.}, 30 | Author = {Tom M Apostol}, 31 | Chapter = {9.3}, 32 | Date-Added = {2014-01-27 22:09:44 +0000}, 33 | Date-Modified = {2014-01-27 22:11:54 +0000}, 34 | Pages = {360-1}, 35 | Publisher = {Wiley}, 36 | Title = {Calculus}, 37 | Volume = {1}, 38 | Year = {1967}} 39 | -------------------------------------------------------------------------------- /abstract.tex: -------------------------------------------------------------------------------- 1 | Array-based programming environments are popular for scientific and 2 | technical computing. 3 | These systems consist of built-in function libraries paired with high-level 4 | languages for interaction. 5 | Although the libraries perform well, it is widely believed that scripting in these 6 | languages is necessarily slow, and that only heroic feats of engineering can at 7 | best partially ameliorate this problem. 8 | 9 | This thesis argues that what is really needed is a more coherent 10 | structure for this functionality. 11 | To find one, we must ask what technical computing is really about. 12 | This thesis suggests that this kind of programming is characterized by an emphasis on operator 13 | complexity and code specialization, and that a language can be designed to 14 | better fit these requirements. 15 | 16 | The key idea is to integrate code \emph{selection} with code \emph{specialization}, 17 | using generic functions and data-flow type inference. 18 | Systems like these can suffer from inefficient compilation, or from 19 | uncertainty about what to specialize on. 20 | We show that sufficiently powerful type-based dispatch addresses these problems. 21 | The resulting language, Julia, achieves a Quine-style 22 | ``explication by elimination'' of many of the productive features 23 | technical computing users expect. 24 | 25 | % we show how this can be use to greatly simplify code for demanding 26 | % scientific applications that require a mixture of binding times. 27 | 28 | % thesis stmt: integrating code selection and specialization with 29 | % type-based dynamic dispatch captures both the performance and 30 | % productivity requirements of technical computing. 31 | % leads to a simpler system which leads to consistent better performance 32 | 33 | % something about working for both domain experts and speed freaks 34 | 35 | %For this role I propose an abstraction based on an extended version of 36 | %generic functions. 37 | %The novelty of this mechanism is that it is both flexible enough to describe 38 | %the wide variety of behaviors users need in practice, while also providing 39 | %enough information to a compiler to yield good performance. 40 | 41 | 42 | % integration of selection and specialization 43 | 44 | % making data-flow and specialization-based languages practical 45 | 46 | % answers the question of what to specialize on 47 | -------------------------------------------------------------------------------- /acks.tex: -------------------------------------------------------------------------------- 1 | The three people without whom this work would not have been possible 2 | are Alan Edelman, Stefan Karpinski, and Viral Shah. 3 | Their ideas and their support have been extraordinary. 4 | I habitually mentally included them while writing this thesis in the first 5 | person plural. 6 | 7 | I am especially indebted to Steven Johnson, for 8 | explaining to me why Julia is doomed, and subsequently working as much as 9 | anybody to make it less doomed. 10 | He is the author of the code in appendix~\ref{appendix:integration} and, 11 | along with Homer Reid, is responsible for the example in section~\ref{sec:BEM}. 12 | 13 | I thank Jiahao Chen for coauthoring, contributing to nearly 14 | every aspect of our project, 15 | and even coming up with the title of this very document, 16 | Jean Yang for paper writing help, and 17 | Fernando Perez and Brian Granger for welcoming us so generously to the wonderful 18 | world of Jupyter. 19 | 20 | For their valuable feedback on drafts I am grateful to 21 | Jake Bolewski, Oscar Blumberg, Tim Holy, and my committee members 22 | Saman Amarasinghe and Gerry Sussman. 23 | 24 | It is quite a privilege to be able to cite other people's work to 25 | demonstrate and evaluate my own. 26 | In this regard I am grateful to Miles Lubin, Iain Dunning, Keno Fischer, 27 | and Andreas Noack. 28 | 29 | At this point, I need to thank so many more people that doing so requires 30 | automation. 31 | The full list can be found in our \texttt{git} history. 32 | As a partial list, I thank for their excellent contributions to the 33 | software: 34 | Jameson Nash, 35 | Tim Holy, 36 | Mike Nolta, 37 | Carlo Baldassi, 38 | Elliot Saba, 39 | Andreas Noack, 40 | Tony Kelman, 41 | Jake Bolewski, 42 | Kevin Squire, 43 | Isaiah Norton, 44 | Amit Murthy, 45 | Simon Kornblith, 46 | Patrick O'Leary, 47 | Dahua Lin, 48 | Jacob Quinn, 49 | Douglas Bates, 50 | Simon Byrne, 51 | Mike Innes, 52 | Ivar Nesje, 53 | Tanmay Mohapatra, 54 | Matt Bauman, 55 | Rafael Fourquet (largely responsible for the speed of \texttt{randn} 56 | described in section~\ref{sec:beating}), 57 | Arch Robison, 58 | Oscar Blumberg, 59 | John Myles White, 60 | Shashi Gowda, 61 | and Daniel Jones. 62 | 63 | For generally advancing the Julia community, I thank 64 | Evan Miller, Hunter Owens, James Porter, Leah Hanson, and 65 | Mykel Kochenderfer. 66 | 67 | These collaborators made this far more than a research project: they 68 | made it a formidable software project, they gave it global reach, and they 69 | made it fun. 70 | -------------------------------------------------------------------------------- /algorithms/COPYING: -------------------------------------------------------------------------------- 1 | 2 | GNU LESSER GENERAL PUBLIC LICENSE 3 | Version 2.1, February 1999 4 | 5 | Copyright (C) 1991, 1999 Free Software Foundation, Inc. 6 | 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA 7 | Everyone is permitted to copy and distribute verbatim copies 8 | of this license document, but changing it is not allowed. 9 | 10 | [This is the first released version of the Lesser GPL. It also counts 11 | as the successor of the GNU Library Public License, version 2, hence 12 | the version number 2.1.] 13 | 14 | Preamble 15 | 16 | The licenses for most software are designed to take away your 17 | freedom to share and change it. By contrast, the GNU General Public 18 | Licenses are intended to guarantee your freedom to share and change 19 | free software--to make sure the software is free for all its users. 20 | 21 | This license, the Lesser General Public License, applies to some 22 | specially designated software packages--typically libraries--of the 23 | Free Software Foundation and other authors who decide to use it. You 24 | can use it too, but we suggest you first think carefully about whether 25 | this license or the ordinary General Public License is the better 26 | strategy to use in any particular case, based on the explanations 27 | below. 28 | 29 | When we speak of free software, we are referring to freedom of use, 30 | not price. Our General Public Licenses are designed to make sure that 31 | you have the freedom to distribute copies of free software (and charge 32 | for this service if you wish); that you receive source code or can get 33 | it if you want it; that you can change the software and use pieces of 34 | it in new free programs; and that you are informed that you can do 35 | these things. 36 | 37 | To protect your rights, we need to make restrictions that forbid 38 | distributors to deny you these rights or to ask you to surrender these 39 | rights. These restrictions translate to certain responsibilities for 40 | you if you distribute copies of the library or if you modify it. 41 | 42 | For example, if you distribute copies of the library, whether gratis 43 | or for a fee, you must give the recipients all the rights that we gave 44 | you. You must make sure that they, too, receive or can get the source 45 | code. If you link other code with the library, you must provide 46 | complete object files to the recipients, so that they can relink them 47 | with the library after making changes to the library and recompiling 48 | it. And you must show them these terms so they know their rights. 49 | 50 | We protect your rights with a two-step method: (1) we copyright the 51 | library, and (2) we offer you this license, which gives you legal 52 | permission to copy, distribute and/or modify the library. 53 | 54 | To protect each distributor, we want to make it very clear that 55 | there is no warranty for the free library. Also, if the library is 56 | modified by someone else and passed on, the recipients should know 57 | that what they have is not the original version, so that the original 58 | author's reputation will not be affected by problems that might be 59 | introduced by others. 60 | 61 | Finally, software patents pose a constant threat to the existence of 62 | any free program. We wish to make sure that a company cannot 63 | effectively restrict the users of a free program by obtaining a 64 | restrictive license from a patent holder. Therefore, we insist that 65 | any patent license obtained for a version of the library must be 66 | consistent with the full freedom of use specified in this license. 67 | 68 | Most GNU software, including some libraries, is covered by the 69 | ordinary GNU General Public License. This license, the GNU Lesser 70 | General Public License, applies to certain designated libraries, and 71 | is quite different from the ordinary General Public License. We use 72 | this license for certain libraries in order to permit linking those 73 | libraries into non-free programs. 74 | 75 | When a program is linked with a library, whether statically or using 76 | a shared library, the combination of the two is legally speaking a 77 | combined work, a derivative of the original library. The ordinary 78 | General Public License therefore permits such linking only if the 79 | entire combination fits its criteria of freedom. The Lesser General 80 | Public License permits more lax criteria for linking other code with 81 | the library. 82 | 83 | We call this license the "Lesser" General Public License because it 84 | does Less to protect the user's freedom than the ordinary General 85 | Public License. It also provides other free software developers Less 86 | of an advantage over competing non-free programs. These disadvantages 87 | are the reason we use the ordinary General Public License for many 88 | libraries. However, the Lesser license provides advantages in certain 89 | special circumstances. 90 | 91 | For example, on rare occasions, there may be a special need to 92 | encourage the widest possible use of a certain library, so that it 93 | becomes a de-facto standard. To achieve this, non-free programs must 94 | be allowed to use the library. A more frequent case is that a free 95 | library does the same job as widely used non-free libraries. In this 96 | case, there is little to gain by limiting the free library to free 97 | software only, so we use the Lesser General Public License. 98 | 99 | In other cases, permission to use a particular library in non-free 100 | programs enables a greater number of people to use a large body of 101 | free software. For example, permission to use the GNU C Library in 102 | non-free programs enables many more people to use the whole GNU 103 | operating system, as well as its variant, the GNU/Linux operating 104 | system. 105 | 106 | Although the Lesser General Public License is Less protective of the 107 | users' freedom, it does ensure that the user of a program that is 108 | linked with the Library has the freedom and the wherewithal to run 109 | that program using a modified version of the Library. 110 | 111 | The precise terms and conditions for copying, distribution and 112 | modification follow. Pay close attention to the difference between a 113 | "work based on the library" and a "work that uses the library". The 114 | former contains code derived from the library, whereas the latter must 115 | be combined with the library in order to run. 116 | 117 | GNU LESSER GENERAL PUBLIC LICENSE 118 | TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 119 | 120 | 0. This License Agreement applies to any software library or other 121 | program which contains a notice placed by the copyright holder or 122 | other authorized party saying it may be distributed under the terms of 123 | this Lesser General Public License (also called "this License"). 124 | Each licensee is addressed as "you". 125 | 126 | A "library" means a collection of software functions and/or data 127 | prepared so as to be conveniently linked with application programs 128 | (which use some of those functions and data) to form executables. 129 | 130 | The "Library", below, refers to any such software library or work 131 | which has been distributed under these terms. A "work based on the 132 | Library" means either the Library or any derivative work under 133 | copyright law: that is to say, a work containing the Library or a 134 | portion of it, either verbatim or with modifications and/or translated 135 | straightforwardly into another language. (Hereinafter, translation is 136 | included without limitation in the term "modification".) 137 | 138 | "Source code" for a work means the preferred form of the work for 139 | making modifications to it. For a library, complete source code means 140 | all the source code for all modules it contains, plus any associated 141 | interface definition files, plus the scripts used to control 142 | compilation and installation of the library. 143 | 144 | Activities other than copying, distribution and modification are not 145 | covered by this License; they are outside its scope. The act of 146 | running a program using the Library is not restricted, and output from 147 | such a program is covered only if its contents constitute a work based 148 | on the Library (independent of the use of the Library in a tool for 149 | writing it). Whether that is true depends on what the Library does 150 | and what the program that uses the Library does. 151 | 152 | 1. You may copy and distribute verbatim copies of the Library's 153 | complete source code as you receive it, in any medium, provided that 154 | you conspicuously and appropriately publish on each copy an 155 | appropriate copyright notice and disclaimer of warranty; keep intact 156 | all the notices that refer to this License and to the absence of any 157 | warranty; and distribute a copy of this License along with the 158 | Library. 159 | 160 | You may charge a fee for the physical act of transferring a copy, 161 | and you may at your option offer warranty protection in exchange for a 162 | fee. 163 | 164 | 2. You may modify your copy or copies of the Library or any portion 165 | of it, thus forming a work based on the Library, and copy and 166 | distribute such modifications or work under the terms of Section 1 167 | above, provided that you also meet all of these conditions: 168 | 169 | a) The modified work must itself be a software library. 170 | 171 | b) You must cause the files modified to carry prominent notices 172 | stating that you changed the files and the date of any change. 173 | 174 | c) You must cause the whole of the work to be licensed at no 175 | charge to all third parties under the terms of this License. 176 | 177 | d) If a facility in the modified Library refers to a function or a 178 | table of data to be supplied by an application program that uses 179 | the facility, other than as an argument passed when the facility 180 | is invoked, then you must make a good faith effort to ensure that, 181 | in the event an application does not supply such function or 182 | table, the facility still operates, and performs whatever part of 183 | its purpose remains meaningful. 184 | 185 | (For example, a function in a library to compute square roots has 186 | a purpose that is entirely well-defined independent of the 187 | application. Therefore, Subsection 2d requires that any 188 | application-supplied function or table used by this function must 189 | be optional: if the application does not supply it, the square 190 | root function must still compute square roots.) 191 | 192 | These requirements apply to the modified work as a whole. If 193 | identifiable sections of that work are not derived from the Library, 194 | and can be reasonably considered independent and separate works in 195 | themselves, then this License, and its terms, do not apply to those 196 | sections when you distribute them as separate works. But when you 197 | distribute the same sections as part of a whole which is a work based 198 | on the Library, the distribution of the whole must be on the terms of 199 | this License, whose permissions for other licensees extend to the 200 | entire whole, and thus to each and every part regardless of who wrote 201 | it. 202 | 203 | Thus, it is not the intent of this section to claim rights or contest 204 | your rights to work written entirely by you; rather, the intent is to 205 | exercise the right to control the distribution of derivative or 206 | collective works based on the Library. 207 | 208 | In addition, mere aggregation of another work not based on the Library 209 | with the Library (or with a work based on the Library) on a volume of 210 | a storage or distribution medium does not bring the other work under 211 | the scope of this License. 212 | 213 | 3. You may opt to apply the terms of the ordinary GNU General Public 214 | License instead of this License to a given copy of the Library. To do 215 | this, you must alter all the notices that refer to this License, so 216 | that they refer to the ordinary GNU General Public License, version 2, 217 | instead of to this License. (If a newer version than version 2 of the 218 | ordinary GNU General Public License has appeared, then you can specify 219 | that version instead if you wish.) Do not make any other change in 220 | these notices. 221 | 222 | Once this change is made in a given copy, it is irreversible for 223 | that copy, so the ordinary GNU General Public License applies to all 224 | subsequent copies and derivative works made from that copy. 225 | 226 | This option is useful when you wish to copy part of the code of 227 | the Library into a program that is not a library. 228 | 229 | 4. You may copy and distribute the Library (or a portion or 230 | derivative of it, under Section 2) in object code or executable form 231 | under the terms of Sections 1 and 2 above provided that you accompany 232 | it with the complete corresponding machine-readable source code, which 233 | must be distributed under the terms of Sections 1 and 2 above on a 234 | medium customarily used for software interchange. 235 | 236 | If distribution of object code is made by offering access to copy 237 | from a designated place, then offering equivalent access to copy the 238 | source code from the same place satisfies the requirement to 239 | distribute the source code, even though third parties are not 240 | compelled to copy the source along with the object code. 241 | 242 | 5. A program that contains no derivative of any portion of the 243 | Library, but is designed to work with the Library by being compiled or 244 | linked with it, is called a "work that uses the Library". Such a 245 | work, in isolation, is not a derivative work of the Library, and 246 | therefore falls outside the scope of this License. 247 | 248 | However, linking a "work that uses the Library" with the Library 249 | creates an executable that is a derivative of the Library (because it 250 | contains portions of the Library), rather than a "work that uses the 251 | library". The executable is therefore covered by this License. 252 | Section 6 states terms for distribution of such executables. 253 | 254 | When a "work that uses the Library" uses material from a header file 255 | that is part of the Library, the object code for the work may be a 256 | derivative work of the Library even though the source code is not. 257 | Whether this is true is especially significant if the work can be 258 | linked without the Library, or if the work is itself a library. The 259 | threshold for this to be true is not precisely defined by law. 260 | 261 | If such an object file uses only numerical parameters, data 262 | structure layouts and accessors, and small macros and small inline 263 | functions (ten lines or less in length), then the use of the object 264 | file is unrestricted, regardless of whether it is legally a derivative 265 | work. (Executables containing this object code plus portions of the 266 | Library will still fall under Section 6.) 267 | 268 | Otherwise, if the work is a derivative of the Library, you may 269 | distribute the object code for the work under the terms of Section 6. 270 | Any executables containing that work also fall under Section 6, 271 | whether or not they are linked directly with the Library itself. 272 | 273 | 6. As an exception to the Sections above, you may also combine or 274 | link a "work that uses the Library" with the Library to produce a 275 | work containing portions of the Library, and distribute that work 276 | under terms of your choice, provided that the terms permit 277 | modification of the work for the customer's own use and reverse 278 | engineering for debugging such modifications. 279 | 280 | You must give prominent notice with each copy of the work that the 281 | Library is used in it and that the Library and its use are covered by 282 | this License. You must supply a copy of this License. If the work 283 | during execution displays copyright notices, you must include the 284 | copyright notice for the Library among them, as well as a reference 285 | directing the user to the copy of this License. Also, you must do one 286 | of these things: 287 | 288 | a) Accompany the work with the complete corresponding 289 | machine-readable source code for the Library including whatever 290 | changes were used in the work (which must be distributed under 291 | Sections 1 and 2 above); and, if the work is an executable linked 292 | with the Library, with the complete machine-readable "work that 293 | uses the Library", as object code and/or source code, so that the 294 | user can modify the Library and then relink to produce a modified 295 | executable containing the modified Library. (It is understood 296 | that the user who changes the contents of definitions files in the 297 | Library will not necessarily be able to recompile the application 298 | to use the modified definitions.) 299 | 300 | b) Use a suitable shared library mechanism for linking with the 301 | Library. A suitable mechanism is one that (1) uses at run time a 302 | copy of the library already present on the user's computer system, 303 | rather than copying library functions into the executable, and (2) 304 | will operate properly with a modified version of the library, if 305 | the user installs one, as long as the modified version is 306 | interface-compatible with the version that the work was made with. 307 | 308 | c) Accompany the work with a written offer, valid for at least 309 | three years, to give the same user the materials specified in 310 | Subsection 6a, above, for a charge no more than the cost of 311 | performing this distribution. 312 | 313 | d) If distribution of the work is made by offering access to copy 314 | from a designated place, offer equivalent access to copy the above 315 | specified materials from the same place. 316 | 317 | e) Verify that the user has already received a copy of these 318 | materials or that you have already sent this user a copy. 319 | 320 | For an executable, the required form of the "work that uses the 321 | Library" must include any data and utility programs needed for 322 | reproducing the executable from it. However, as a special exception, 323 | the materials to be distributed need not include anything that is 324 | normally distributed (in either source or binary form) with the major 325 | components (compiler, kernel, and so on) of the operating system on 326 | which the executable runs, unless that component itself accompanies 327 | the executable. 328 | 329 | It may happen that this requirement contradicts the license 330 | restrictions of other proprietary libraries that do not normally 331 | accompany the operating system. Such a contradiction means you cannot 332 | use both them and the Library together in an executable that you 333 | distribute. 334 | 335 | 7. You may place library facilities that are a work based on the 336 | Library side-by-side in a single library together with other library 337 | facilities not covered by this License, and distribute such a combined 338 | library, provided that the separate distribution of the work based on 339 | the Library and of the other library facilities is otherwise 340 | permitted, and provided that you do these two things: 341 | 342 | a) Accompany the combined library with a copy of the same work 343 | based on the Library, uncombined with any other library 344 | facilities. This must be distributed under the terms of the 345 | Sections above. 346 | 347 | b) Give prominent notice with the combined library of the fact 348 | that part of it is a work based on the Library, and explaining 349 | where to find the accompanying uncombined form of the same work. 350 | 351 | 8. You may not copy, modify, sublicense, link with, or distribute 352 | the Library except as expressly provided under this License. Any 353 | attempt otherwise to copy, modify, sublicense, link with, or 354 | distribute the Library is void, and will automatically terminate your 355 | rights under this License. However, parties who have received copies, 356 | or rights, from you under this License will not have their licenses 357 | terminated so long as such parties remain in full compliance. 358 | 359 | 9. You are not required to accept this License, since you have not 360 | signed it. However, nothing else grants you permission to modify or 361 | distribute the Library or its derivative works. These actions are 362 | prohibited by law if you do not accept this License. Therefore, by 363 | modifying or distributing the Library (or any work based on the 364 | Library), you indicate your acceptance of this License to do so, and 365 | all its terms and conditions for copying, distributing or modifying 366 | the Library or works based on it. 367 | 368 | 10. Each time you redistribute the Library (or any work based on the 369 | Library), the recipient automatically receives a license from the 370 | original licensor to copy, distribute, link with or modify the Library 371 | subject to these terms and conditions. You may not impose any further 372 | restrictions on the recipients' exercise of the rights granted herein. 373 | You are not responsible for enforcing compliance by third parties with 374 | this License. 375 | 376 | 11. If, as a consequence of a court judgment or allegation of patent 377 | infringement or for any other reason (not limited to patent issues), 378 | conditions are imposed on you (whether by court order, agreement or 379 | otherwise) that contradict the conditions of this License, they do not 380 | excuse you from the conditions of this License. If you cannot 381 | distribute so as to satisfy simultaneously your obligations under this 382 | License and any other pertinent obligations, then as a consequence you 383 | may not distribute the Library at all. For example, if a patent 384 | license would not permit royalty-free redistribution of the Library by 385 | all those who receive copies directly or indirectly through you, then 386 | the only way you could satisfy both it and this License would be to 387 | refrain entirely from distribution of the Library. 388 | 389 | If any portion of this section is held invalid or unenforceable under 390 | any particular circumstance, the balance of the section is intended to 391 | apply, and the section as a whole is intended to apply in other 392 | circumstances. 393 | 394 | It is not the purpose of this section to induce you to infringe any 395 | patents or other property right claims or to contest validity of any 396 | such claims; this section has the sole purpose of protecting the 397 | integrity of the free software distribution system which is 398 | implemented by public license practices. Many people have made 399 | generous contributions to the wide range of software distributed 400 | through that system in reliance on consistent application of that 401 | system; it is up to the author/donor to decide if he or she is willing 402 | to distribute software through any other system and a licensee cannot 403 | impose that choice. 404 | 405 | This section is intended to make thoroughly clear what is believed to 406 | be a consequence of the rest of this License. 407 | 408 | 12. If the distribution and/or use of the Library is restricted in 409 | certain countries either by patents or by copyrighted interfaces, the 410 | original copyright holder who places the Library under this License 411 | may add an explicit geographical distribution limitation excluding those 412 | countries, so that distribution is permitted only in or among 413 | countries not thus excluded. In such case, this License incorporates 414 | the limitation as if written in the body of this License. 415 | 416 | 13. The Free Software Foundation may publish revised and/or new 417 | versions of the Lesser General Public License from time to time. 418 | Such new versions will be similar in spirit to the present version, 419 | but may differ in detail to address new problems or concerns. 420 | 421 | Each version is given a distinguishing version number. If the Library 422 | specifies a version number of this License which applies to it and 423 | "any later version", you have the option of following the terms and 424 | conditions either of that version or of any later version published by 425 | the Free Software Foundation. If the Library does not specify a 426 | license version number, you may choose any version ever published by 427 | the Free Software Foundation. 428 | 429 | 14. If you wish to incorporate parts of the Library into other free 430 | programs whose distribution conditions are incompatible with these, 431 | write to the author to ask for permission. For software which is 432 | copyrighted by the Free Software Foundation, write to the Free 433 | Software Foundation; we sometimes make exceptions for this. Our 434 | decision will be guided by the two goals of preserving the free status 435 | of all derivatives of our free software and of promoting the sharing 436 | and reuse of software generally. 437 | 438 | NO WARRANTY 439 | 440 | 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO 441 | WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. 442 | EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR 443 | OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY 444 | KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE 445 | IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 446 | PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE 447 | LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME 448 | THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 449 | 450 | 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 451 | WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY 452 | AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU 453 | FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR 454 | CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE 455 | LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING 456 | RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A 457 | FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF 458 | SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH 459 | DAMAGES. 460 | 461 | END OF TERMS AND CONDITIONS 462 | 463 | How to Apply These Terms to Your New Libraries 464 | 465 | If you develop a new library, and you want it to be of the greatest 466 | possible use to the public, we recommend making it free software that 467 | everyone can redistribute and change. You can do so by permitting 468 | redistribution under these terms (or, alternatively, under the terms 469 | of the ordinary General Public License). 470 | 471 | To apply these terms, attach the following notices to the library. 472 | It is safest to attach them to the start of each source file to most 473 | effectively convey the exclusion of warranty; and each file should 474 | have at least the "copyright" line and a pointer to where the full 475 | notice is found. 476 | 477 | 478 | 479 | Copyright (C) 480 | 481 | This library is free software; you can redistribute it and/or 482 | modify it under the terms of the GNU Lesser General Public 483 | License as published by the Free Software Foundation; either 484 | version 2.1 of the License, or (at your option) any later version. 485 | 486 | This library is distributed in the hope that it will be useful, 487 | but WITHOUT ANY WARRANTY; without even the implied warranty of 488 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 489 | Lesser General Public License for more details. 490 | 491 | You should have received a copy of the GNU Lesser General Public 492 | License along with this library; if not, write to the Free Software 493 | Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA 494 | 495 | Also add information on how to contact you by electronic and paper mail. 496 | 497 | You should also get your employer (if you work as a programmer) or 498 | your school, if any, to sign a "copyright disclaimer" for the library, 499 | if necessary. Here is a sample; alter the names: 500 | 501 | Yoyodyne, Inc., hereby disclaims all copyright interest in the 502 | library `Frob' (a library for tweaking knobs) written by James 503 | Random Hacker. 504 | 505 | , 1 April 1990 506 | Ty Coon, President of Vice 507 | 508 | That's all there is to it! 509 | 510 | 511 | -------------------------------------------------------------------------------- /algorithms/README: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/JeffBezanson/phdthesis/876be73a5aab9b034fac3eb9ea9d8f96713f786f/algorithms/README -------------------------------------------------------------------------------- /algorithms/THANKS: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/JeffBezanson/phdthesis/876be73a5aab9b034fac3eb9ea9d8f96713f786f/algorithms/THANKS -------------------------------------------------------------------------------- /algorithms/algorithm.sty: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/JeffBezanson/phdthesis/876be73a5aab9b034fac3eb9ea9d8f96713f786f/algorithms/algorithm.sty -------------------------------------------------------------------------------- /algorithms/algorithmic.sty: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/JeffBezanson/phdthesis/876be73a5aab9b034fac3eb9ea9d8f96713f786f/algorithms/algorithmic.sty -------------------------------------------------------------------------------- /algorithms/algorithms.dtx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/JeffBezanson/phdthesis/876be73a5aab9b034fac3eb9ea9d8f96713f786f/algorithms/algorithms.dtx -------------------------------------------------------------------------------- /algorithms/algorithms.ins: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/JeffBezanson/phdthesis/876be73a5aab9b034fac3eb9ea9d8f96713f786f/algorithms/algorithms.ins -------------------------------------------------------------------------------- /algorithms/algorithms.log: -------------------------------------------------------------------------------- 1 | This is pdfTeX, Version 3.1415926-2.3-1.40.12 (TeX Live 2012/dev/Arch Linux) (format=latex 2012.2.24) 17 APR 2012 18:04 2 | entering extended mode 3 | restricted \write18 enabled. 4 | %&-line parsing enabled. 5 | **algorithms.ins 6 | (./algorithms.ins 7 | LaTeX2e <2011/06/27> 8 | Babel and hyphenation patterns for english, dumylang, nohyphenation, ge 9 | rman-x-2011-07-01, ngerman-x-2011-07-01, afrikaans, ancientgreek, ibycus, arabi 10 | c, armenian, basque, bulgarian, catalan, pinyin, coptic, croatian, czech, danis 11 | h, dutch, ukenglish, usenglishmax, esperanto, estonian, ethiopic, farsi, finnis 12 | h, french, galician, german, ngerman, swissgerman, monogreek, greek, hungarian, 13 | icelandic, assamese, bengali, gujarati, hindi, kannada, malayalam, marathi, or 14 | iya, panjabi, tamil, telugu, indonesian, interlingua, irish, italian, kurmanji, 15 | lao, latin, latvian, lithuanian, mongolian, mongolianlmc, bokmal, nynorsk, pol 16 | ish, portuguese, romanian, russian, sanskrit, serbian, serbianc, slovak, sloven 17 | ian, spanish, swedish, turkish, turkmen, ukrainian, uppersorbian, welsh, loaded 18 | . 19 | (/usr/share/texmf-dist/tex/latex/base/docstrip.tex 20 | \blockLevel=\count79 21 | \emptyLines=\count80 22 | \processedLines=\count81 23 | \commentsRemoved=\count82 24 | \commentsPassed=\count83 25 | \codeLinesPassed=\count84 26 | \TotalprocessedLines=\count85 27 | \TotalcommentsRemoved=\count86 28 | \TotalcommentsPassed=\count87 29 | \TotalcodeLinesPassed=\count88 30 | \NumberOfFiles=\count89 31 | \inFile=\read1 32 | \inputcheck=\read2 33 | \off@0=\count90 34 | \off@1=\count91 35 | \off@2=\count92 36 | \off@3=\count93 37 | \off@4=\count94 38 | \off@5=\count95 39 | \off@6=\count96 40 | \off@7=\count97 41 | \off@8=\count98 42 | \off@9=\count99 43 | \off@10=\count100 44 | \off@11=\count101 45 | \off@12=\count102 46 | \off@13=\count103 47 | \off@14=\count104 48 | \off@15=\count105 49 | \@maxfiles=\count106 50 | \@maxoutfiles=\count107 51 | 52 | Utility: `docstrip' 2.5d <2005/07/29> 53 | English documentation <1999/03/31> 54 | 55 | ********************************************************** 56 | * This program converts documented macro-files into fast * 57 | * loadable files by stripping off (nearly) all comments! * 58 | ********************************************************** 59 | 60 | ******************************************************** 61 | * No Configuration file found, using default settings. * 62 | ******************************************************** 63 | 64 | ) 65 | 66 | Generating file(s) ./algorithm.sty 67 | \openout0 = `./algorithm.sty'. 68 | 69 | 70 | Processing file algorithms.dtx (algorithm) -> algorithm.sty 71 | Lines processed: 1272 72 | Comments removed: 984 73 | Comments passed: 0 74 | Codelines passed: 14 75 | 76 | 77 | Generating file(s) ./algorithmic.sty 78 | \openout0 = `./algorithmic.sty'. 79 | 80 | 81 | Processing file algorithms.dtx (algorithmic) -> algorithmic.sty 82 | Lines processed: 1272 83 | Comments removed: 984 84 | Comments passed: 0 85 | Codelines passed: 14 86 | 87 | ********************************************************* 88 | * 89 | * To finish the installation you have to move the 90 | * following files into a directory searched by LaTeX: 91 | * 92 | * algorithm.sty 93 | * algorithmic.sty 94 | * 95 | * To produce the documentation run the file 96 | * `algorithms.dtx' through LaTeX. 97 | * 98 | * Happy TeXing! 99 | ********************************************************* 100 | Overall statistics: 101 | Files processed: 2 102 | Lines processed: 2544 103 | Comments removed: 1968 104 | Comments passed: 0 105 | Codelines passed: 28 106 | ) 107 | Here is how much of TeX's memory you used: 108 | 324 strings out of 493630 109 | 3334 string characters out of 3148801 110 | 54371 words of memory out of 3000000 111 | 3720 multiletter control sequences out of 15000+200000 112 | 3640 words of font info for 14 fonts, out of 3000000 for 9000 113 | 831 hyphenation exceptions out of 8191 114 | 11i,0n,15p,205b,120s stack positions out of 5000i,500n,10000p,200000b,50000s 115 | 116 | No pages of output. 117 | -------------------------------------------------------------------------------- /algorithms/algorithms.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/JeffBezanson/phdthesis/876be73a5aab9b034fac3eb9ea9d8f96713f786f/algorithms/algorithms.pdf -------------------------------------------------------------------------------- /appa.tex: -------------------------------------------------------------------------------- 1 | \chapter{Subtyping algorithm} 2 | \label{appendix:subtyping} 3 | 4 | \begin{singlespace} 5 | \begin{multicols}{2} 6 | \begin{lstlisting}[language=julia] 7 | abstract Ty 8 | 9 | type TypeName 10 | super::Ty 11 | TypeName() = new() 12 | end 13 | 14 | type TagT <: Ty 15 | name::TypeName 16 | params 17 | vararg::Bool 18 | end 19 | 20 | type UnionT <: Ty 21 | a; b 22 | end 23 | 24 | type Var 25 | lb; ub 26 | end 27 | 28 | type UnionAllT <: Ty 29 | var::Var 30 | T 31 | end 32 | \end{lstlisting} 33 | \end{multicols} 34 | 35 | \vspace{-3ex} 36 | \begin{lstlisting}[language=julia] 37 | ## Any, Bottom, and Tuple 38 | const AnyT = TagT(TypeName(),(),false); AnyT.name.super = AnyT 39 | type BottomTy <: Ty; end; const BottomT = BottomTy() 40 | const TupleName = TypeName(); TupleName.super = AnyT 41 | 42 | super(t::TagT) = 43 | t.name===TupleName ? AnyT : inst(t.name.super, t.params...) 44 | 45 | ## type application 46 | inst(t::TagT) = t 47 | inst(t::UnionAllT, param) = subst(t.T, Dict(t.var => param)) 48 | inst(t::UnionAllT, param, rest...) = inst(inst(t,param), rest...) 49 | 50 | subst(t, env) = t 51 | subst(t::TagT, env) = 52 | t===AnyT ? t : TagT(t.name, map(x->subst(x,env), t.params), 53 | t.vararg) 54 | subst(t::UnionT, env) = UnionT(subst(t.a,env), subst(t.b,env)) 55 | subst(t::Var, env) = get(env, t, t) 56 | function subst(t::UnionAllT, env) 57 | newVar = Var(subst(t.var.lb,env), subst(t.var.ub,env)) 58 | UnionAllT(newVar, subst(t.T, merge(env, Dict(t.var=>newVar)))) 59 | end 60 | 61 | rename(t::UnionAllT) = let v = Var(t.var.lb, t.var.ub) 62 | UnionAllT(v, inst(t,v)) 63 | end 64 | 65 | type Bounds 66 | lb; ub # current lower and upper bounds of a Var 67 | right::Bool # this Var is on the right-hand side of A <: B 68 | end 69 | 70 | type UnionState 71 | depth::Int # number of nested union decision points 72 | more::Bool # new union found; need to grow stack 73 | stack::Vector{Bool} # stack of decisions 74 | UnionState() = new(1,0,Bool[]) 75 | end 76 | 77 | type Env 78 | vars::Dict{Var,Bounds} 79 | Lunions::UnionState 80 | Runions::UnionState 81 | Env() = new(Dict{Var,Bounds}(), UnionState(), UnionState()) 82 | end 83 | 84 | issub(x, y) = forall_exists_issub(x, y, Env(), false) 85 | issub(x, y, env) = (x === y) 86 | issub(x::Ty, y::Ty, env) = (x === y) || x === BottomT 87 | 88 | function forall_exists_issub(x, y, env, anyunions::Bool) 89 | for forall in false:anyunions 90 | if !isempty(env.Lunions.stack) 91 | env.Lunions.stack[end] = forall 92 | end 93 | 94 | !exists_issub(x, y, env, false) && return false 95 | 96 | if env.Lunions.more 97 | push!(env.Lunions.stack, false) 98 | sub = forall_exists_issub(x, y, env, true) 99 | pop!(env.Lunions.stack) 100 | !sub && return false 101 | end end 102 | return true 103 | end 104 | 105 | function exists_issub(x, y, env, anyunions::Bool) 106 | for exists in false:anyunions 107 | if !isempty(env.Runions.stack) 108 | env.Runions.stack[end] = exists 109 | end 110 | env.Lunions.depth = env.Runions.depth = 1 111 | env.Lunions.more = env.Runions.more = false 112 | 113 | found = issub(x, y, env) 114 | 115 | if env.Lunions.more 116 | return true # return up to forall_exists_issub 117 | end 118 | if env.Runions.more 119 | push!(env.Runions.stack, false) 120 | found = exists_issub(x, y, env, true) 121 | pop!(env.Runions.stack) 122 | end 123 | found && return true 124 | end 125 | return false 126 | end 127 | 128 | function issub_union(t, u::UnionT, env, R) 129 | state = R ? env.Runions : env.Lunions 130 | if state.depth > length(state.stack) 131 | state.more = true 132 | return true 133 | end 134 | ui = state.stack[state.depth]; state.depth += 1 135 | choice = getfield(u, 1+ui) 136 | return R ? issub(t, choice, env) : issub(choice, t, env) 137 | end 138 | 139 | issub(a::UnionT, b::UnionT, env) = issub_union(a, b, env, true) 140 | issub(a::UnionT, b::Ty, env) = issub_union(b, a, env, false) 141 | issub(a::Ty, b::UnionT, env) = issub_union(a, b, env, true) 142 | # take apart unions before handling vars 143 | issub(a::UnionT, b::Var, env) = issub_union(b, a, env, false) 144 | issub(a::Var, b::UnionT, env) = issub_union(a, b, env, true) 145 | 146 | function issub(a::TagT, b::TagT, env) 147 | a === b && return true 148 | b === AnyT && return true 149 | a === AnyT && return false 150 | if a.name !== b.name 151 | return issub(super(a), b, env) 152 | end 153 | if a.name === TupleName 154 | va, vb = a.vararg, b.vararg 155 | la, lb = length(a.params), length(b.params) 156 | ai = bi = 1 157 | while ai <= la 158 | bi > lb && return false 159 | !issub(a.params[ai], b.params[bi], env) && return false 160 | ai += 1 161 | if bi < lb || !vb 162 | bi += 1 163 | end end 164 | return (la==lb && va==vb) || (vb && (la >= (va ? lb : lb-1))) 165 | end 166 | for i = 1:length(a.params) 167 | ai, bi = a.params[i], b.params[i] 168 | (issub(ai, bi, env) && issub(bi, ai, env)) || return false 169 | end 170 | return true 171 | end 172 | 173 | function join(a,b,env) 174 | (a===BottomT || b===AnyT || a === b) && return b 175 | (b===BottomT || a===AnyT) && return a 176 | UnionT(a,b) 177 | end 178 | 179 | issub(a::Ty, b::Var, env) = var_gt(b, a, env) 180 | issub(a::Var, b::Ty, env) = var_lt(a, b, env) 181 | function issub(a::Var, b::Var, env) 182 | a === b && return true 183 | aa = env.vars[a]; bb = env.vars[b] 184 | if aa.right 185 | bb.right && return issub(bb.ub, bb.lb, env) 186 | return var_lt(a, b, env) 187 | else 188 | if !bb.right # check ~$\forall$~a,b . a<:b 189 | return issub(aa.ub, b, env) || issub(a, bb.lb, env) 190 | end 191 | return var_gt(b, a, env) 192 | end 193 | end 194 | 195 | function var_lt(b::Var, a::Union(Ty,Var), env) 196 | bb = env.vars[b] 197 | !bb.right && return issub(bb.ub, a, env) # check ~$\forall$~b . b<:a 198 | !issub(bb.lb, a, env) && return false 199 | # for contravariance we would need to compute a meet here, but 200 | # because of invariance bb.ub ~$\sqcap$~ a == a here always. 201 | bb.ub = a # meet(bb.ub, a) 202 | return true 203 | end 204 | 205 | function var_gt(b::Var, a::Union(Ty,Var), env) 206 | bb = env.vars[b] 207 | !bb.right && return issub(a, bb.lb, env) # check ~$\forall$~b . b>:a 208 | !issub(a, bb.ub, env) && return false 209 | bb.lb = join(bb.lb, a, env) 210 | return true 211 | end 212 | 213 | function issub_uall(t::Ty, u::UnionAllT, env, R) 214 | haskey(env.vars, u.var) && (u = rename(u)) 215 | env.vars[u.var] = Bounds(u.var.lb, u.var.ub, R) 216 | ans = R ? issub(t, u.T, env) : issub(u.T, t, env) 217 | delete!(env.vars, u.var) 218 | return ans 219 | end 220 | 221 | issub(a::UnionAllT, b::UnionAllT, env) = issub_uall(a,b,env,true) 222 | issub(a::UnionT, b::UnionAllT, env) = issub_uall(a,b,env,true) 223 | issub(a::UnionAllT, b::UnionT, env) = issub_uall(b,a,env,false) 224 | issub(a::Ty, b::UnionAllT, env) = issub_uall(a,b,env,true) 225 | issub(a::UnionAllT, b::Ty, env) = issub_uall(b,a,env,false) 226 | 227 | \end{lstlisting} 228 | \end{singlespace} 229 | -------------------------------------------------------------------------------- /appb.tex: -------------------------------------------------------------------------------- 1 | \chapter{Staged numerical integration} 2 | \label{appendix:integration} 3 | 4 | \begin{singlespace} 5 | \begin{lstlisting}[language=julia] 6 | abstract AbstractKernel 7 | 8 | # any kernel X^p for X ~$\ll$~ s and X^q for X ~$\gg$~ s 9 | abstract APowerLaw{p,q,s} <: AbstractKernel 10 | 11 | type FirstIntegral{K<:AbstractKernel,n}; end 12 | 13 | type PowerLaw{p} <: APowerLaw{p,p}; end # r^p power law 14 | 15 | # N chebyshev points (order N) on the interval (-1,1) 16 | chebx(N) = [cos(~$\pi$~*(n+0.5)/N) for n in 0:N-1] 17 | 18 | # N chebyshev coefficients for vector of f(x) values on chebx 19 | # points x 20 | function chebcoef(f::AbstractVector) 21 | a = FFTW.r2r(f, FFTW.REDFT10) / length(f) 22 | a[1] /= 2 23 | return a 24 | end 25 | 26 | # given a function f and a tolerance, return enough Chebyshev 27 | # coefficients to reconstruct f to that tolerance on (-1,1) 28 | function chebcoef(f, tol=1e-13) 29 | N = 10 30 | local c 31 | while true 32 | x = chebx(N) 33 | c = chebcoef(float([f(y) for y in x])) 34 | # look at last 3 coefs, since individual c's might be 0 35 | if max(abs(c[end]), 36 | abs(c[end-1]), 37 | abs(c[end-2])) < tol * maxabs(c) 38 | break 39 | end 40 | N *= 2 41 | end 42 | return c[1:findlast(v -> abs(v)>tol, c)] # shrink to min length 43 | end 44 | 45 | # given cheb coefficients a, evaluate them for x in (-1,1) by 46 | # Clenshaw recurrence 47 | function evalcheb(x, a) 48 | -1 ~$\leq$~ x ~$\leq$~ 1 || throw(DomainError()) 49 | b~$_{k+1}$~ = b~$_{k+2}$~ = zero(x) 50 | for k = length(a):-1:2 51 | b~$_{k}$~ = a[k] + 2x*b~$_{k+1}$~ - b~$_{k+2}$~ 52 | b~$_{k+2}$~ = b~$_{k+1}$~ 53 | b~$_{k+1}$~ = b~$_{k}$~ 54 | end 55 | return a[1] + x*b~$_{k+1}$~ - b~$_{k+2}$~ 56 | end 57 | 58 | # inlined version of evalcheb given coefficents a, and x in (-1,1) 59 | macro evalcheb(x, a...) 60 | # Clenshaw recurrence, evaluated symbolically: 61 | b~$_{k+1}$~ = b~$_{k+2}$~ = 0 62 | for k = length(a):-1:2 63 | b~$_{k}$~ = esc(a[k]) 64 | if b~$_{k+1}$~ != 0 65 | b~$_{k}$~ = :(muladd(t2, $b~$_{k+1}$~, $b~$_{k}$~)) 66 | end 67 | if b~$_{k+2}$~ != 0 68 | b~$_{k}$~ = :($b~$_{k}$~ - $b~$_{k+2}$~) 69 | end 70 | b~$_{k+2}$~ = b~$_{k+1}$~ 71 | b~$_{k+1}$~ = b~$_{k}$~ 72 | end 73 | ex = esc(a[1]) 74 | if b~$_{k+1}$~ != 0 75 | ex = :(muladd(t, $b~$_{k+1}$~, $ex)) 76 | end 77 | if b~$_{k+2}$~ != 0 78 | ex = :($ex - $b~$_{k+2}$~) 79 | end 80 | Expr(:block, :(t = $(esc(x))), :(t2 = 2t), ex) 81 | end 82 | 83 | # extract parameters from an APowerLaw 84 | APowerLaw_params{p,q,s}(::APowerLaw{p,q,s}) = (p, q, s) 85 | 86 | @generated function call{P<:APowerLaw,n}(::FirstIntegral{P,n}, 87 | X::Real) 88 | # compute the Chebyshev coefficients of the rescaled ~$\mathcal{K}_{n}$~ 89 | K = P() 90 | p, q, s = APowerLaw_params(K) 91 | ~$\mathcal{K}_{n}$~ = X->quadgk(w -> w^n * K(w*X), 0, 1, abstol=1e-14, 92 | reltol=1e-12)[1] 93 | # scale out X ~$\ll$~ s singularity 94 | L~$_{n}$~ = p < 0 ? X -> ~$\mathcal{K}_{n}$~(X) / (s^p + X^p) : ~$\mathcal{K}_{n}$~ 95 | q > 0 && throw(DomainError()) # can't deal with growing kernels 96 | qinv = 1/q 97 | c = chebcoef(~$\xi$~ -> L~$_{n}$~((1-~$\xi$~)^qinv - 2^qinv), 1e-9) 98 | # return an expression to evaluate ~$\mathcal{K}_{n}$~ via C(~$\xi$~) 99 | quote 100 | X <= 0 && throw(DomainError()) 101 | ~$\xi$~ = 1 - (X + $(2^qinv))^$q 102 | C = @evalcheb ~$\xi$~ $(c...) 103 | return $p < 0 ? C * (X^$p + $(s^p)) : C 104 | end 105 | end 106 | 107 | \end{lstlisting} 108 | \end{singlespace} 109 | -------------------------------------------------------------------------------- /appendix.sty: -------------------------------------------------------------------------------- 1 | %% 2 | %% This is file `appendix.sty', 3 | %% generated with the docstrip utility. 4 | %% 5 | %% The original source files were: 6 | %% 7 | %% appendix.dtx (with options: `usc') 8 | %% 9 | %% ----------------------------------------------------------------- 10 | %% Author: Peter Wilson, Herries Press 11 | %% Maintainer: Will Robertson (will dot robertson at latex-project dot org) 12 | %% Copyright 1998--2004 Peter R. Wilson 13 | %% 14 | %% This work may be distributed and/or modified under the 15 | %% conditions of the LaTeX Project Public License, either 16 | %% version 1.3c of this license or (at your option) any 17 | %% later version: 18 | %% 19 | %% This work has the LPPL maintenance status "maintained". 20 | %% The Current Maintainer of this work is Will Robertson. 21 | %% 22 | %% This work consists of the files listed in the README file. 23 | %% ----------------------------------------------------------------- 24 | %% 25 | \NeedsTeXFormat{LaTeX2e} 26 | \ProvidesPackage{appendix}[2009/09/02 v1.2b extra appendix facilities] 27 | 28 | \newif\if@chapter@pp\@chapter@ppfalse 29 | \newif\if@knownclass@pp\@knownclass@ppfalse 30 | \@ifundefined{chapter}{% 31 | \@ifundefined{section}{}{\@knownclass@pptrue}}{% 32 | \@chapter@pptrue\@knownclass@pptrue} 33 | \providecommand{\phantomsection}{} 34 | \newcounter{@pps} 35 | \renewcommand{\the@pps}{\alph{@pps}} 36 | \newif\if@pphyper 37 | \@pphyperfalse 38 | \AtBeginDocument{% 39 | \@ifpackageloaded{hyperref}{\@pphypertrue}{}} 40 | 41 | \newif\if@dotoc@pp\@dotoc@ppfalse 42 | \newif\if@dotitle@pp\@dotitle@ppfalse 43 | \newif\if@dotitletoc@pp\@dotitletoc@ppfalse 44 | \newif\if@dohead@pp\@dohead@ppfalse 45 | \newif\if@dopage@pp\@dopage@ppfalse 46 | \DeclareOption{toc}{\@dotoc@pptrue} 47 | \DeclareOption{title}{\@dotitle@pptrue} 48 | \DeclareOption{titletoc}{\@dotitletoc@pptrue} 49 | \DeclareOption{header}{\@dohead@pptrue} 50 | \DeclareOption{page}{\@dopage@pptrue} 51 | \ProcessOptions\relax 52 | \newcommand{\@ppendinput}{} 53 | \if@knownclass@pp\else 54 | \PackageWarningNoLine{appendix}% 55 | {There is no \protect\chapter\space or \protect\section\space command.\MessageBreak 56 | The appendix package will not be used} 57 | \renewcommand{\@ppendinput}{\endinput} 58 | \fi 59 | \@ppendinput 60 | 61 | \newcommand{\appendixtocon}{\@dotoc@pptrue} 62 | \newcommand{\appendixtocoff}{\@dotoc@ppfalse} 63 | \newcommand{\appendixpageon}{\@dopage@pptrue} 64 | \newcommand{\appendixpageoff}{\@dopage@ppfalse} 65 | \newcommand{\appendixtitleon}{\@dotitle@pptrue} 66 | \newcommand{\appendixtitleoff}{\@dotitle@ppfalse} 67 | \newcommand{\appendixtitletocon}{\@dotitletoc@pptrue} 68 | \newcommand{\appendixtitletocoff}{\@dotitletoc@ppfalse} 69 | \newcommand{\appendixheaderon}{\@dohead@pptrue} 70 | \newcommand{\appendixheaderoff}{\@dohead@ppfalse} 71 | \newcounter{@ppsavesec} 72 | \newcounter{@ppsaveapp} 73 | \setcounter{@ppsaveapp}{0} 74 | \newcommand{\@ppsavesec}{% 75 | \if@chapter@pp \setcounter{@ppsavesec}{\value{chapter}} \else 76 | \setcounter{@ppsavesec}{\value{section}} \fi} 77 | \newcommand{\@pprestoresec}{% 78 | \if@chapter@pp \setcounter{chapter}{\value{@ppsavesec}} \else 79 | \setcounter{section}{\value{@ppsavesec}} \fi} 80 | \newcommand{\@ppsaveapp}{% 81 | \if@chapter@pp \setcounter{@ppsaveapp}{\value{chapter}} \else 82 | \setcounter{@ppsaveapp}{\value{section}} \fi} 83 | \newcommand{\restoreapp}{% 84 | \if@chapter@pp \setcounter{chapter}{\value{@ppsaveapp}} \else 85 | \setcounter{section}{\value{@ppsaveapp}} \fi} 86 | \providecommand{\appendixname}{Appendix} 87 | \newcommand{\appendixtocname}{Appendices} 88 | \newcommand{\appendixpagename}{Appendices} 89 | \newcommand{\appendixpage}{% 90 | \if@chapter@pp \@chap@pppage \else \@sec@pppage \fi 91 | } 92 | \newcommand{\clear@ppage}{% 93 | \if@openright\cleardoublepage\else\clearpage\fi} 94 | 95 | \newcommand{\@chap@pppage}{% 96 | \clear@ppage 97 | \thispagestyle{plain}% 98 | \if@twocolumn\onecolumn\@tempswatrue\else\@tempswafalse\fi 99 | \null\vfil 100 | \markboth{}{}% 101 | {\centering 102 | \interlinepenalty \@M 103 | \normalfont 104 | \Huge \bfseries \appendixpagename\par}% 105 | \if@dotoc@pp 106 | \addappheadtotoc 107 | \fi 108 | \vfil\newpage 109 | \if@twoside 110 | \if@openright 111 | \null 112 | \thispagestyle{empty}% 113 | \newpage 114 | \fi 115 | \fi 116 | \if@tempswa 117 | \twocolumn 118 | \fi 119 | } 120 | 121 | \newcommand{\@sec@pppage}{% 122 | \par 123 | \addvspace{4ex}% 124 | \@afterindentfalse 125 | {\parindent \z@ \raggedright 126 | \interlinepenalty \@M 127 | \normalfont 128 | \huge \bfseries \appendixpagename% 129 | \markboth{}{}\par}% 130 | \if@dotoc@pp 131 | \addappheadtotoc 132 | \fi 133 | \nobreak 134 | \vskip 3ex 135 | \@afterheading 136 | } 137 | 138 | \newif\if@pptocpage 139 | \@pptocpagetrue 140 | \newcommand{\noappendicestocpagenum}{\@pptocpagefalse} 141 | \newcommand{\appendicestocpagenum}{\@pptocpagetrue} 142 | \newcommand{\addappheadtotoc}{% 143 | \phantomsection 144 | \if@chapter@pp 145 | \if@pptocpage 146 | \addcontentsline{toc}{chapter}{\appendixtocname}% 147 | \else 148 | \if@pphyper 149 | \addtocontents{toc}% 150 | {\protect\contentsline{chapter}{\appendixtocname}{}{\@currentHref}}% 151 | \else 152 | \addtocontents{toc}% 153 | {\protect\contentsline{chapter}{\appendixtocname}{}}% 154 | \fi 155 | \fi 156 | \else 157 | \if@pptocpage 158 | \addcontentsline{toc}{section}{\appendixtocname}% 159 | \else 160 | \if@pphyper 161 | \addtocontents{toc}% 162 | {\protect\contentsline{section}{\appendixtocname}{}{\@currentHref}}% 163 | \else 164 | \addtocontents{toc}% 165 | {\protect\contentsline{section}{\appendixtocname}{}}% 166 | \fi 167 | \fi 168 | \fi 169 | } 170 | 171 | \providecommand{\theH@pps}{\alph{@pps}} 172 | 173 | \newcommand{\@resets@pp}{\par 174 | \@ppsavesec 175 | \stepcounter{@pps} 176 | \setcounter{section}{0}% 177 | \if@chapter@pp 178 | \setcounter{chapter}{0}% 179 | \renewcommand\@chapapp{\appendixname}% 180 | \renewcommand\thechapter{\@Alph\c@chapter}% 181 | \else 182 | \setcounter{subsection}{0}% 183 | \renewcommand\thesection{\@Alph\c@section}% 184 | \fi 185 | \if@pphyper 186 | \if@chapter@pp 187 | \renewcommand{\theHchapter}{\theH@pps.\Alph{chapter}}% 188 | \else 189 | \renewcommand{\theHsection}{\theH@pps.\Alph{section}}% 190 | \fi 191 | \def\Hy@chapapp{\appendixname}% 192 | \fi 193 | \restoreapp 194 | } 195 | 196 | \newenvironment{appendices}{% 197 | \@resets@pp 198 | \if@dotoc@pp 199 | \if@dopage@pp % both page and toc 200 | \if@chapter@pp % chapters 201 | \clear@ppage 202 | \fi 203 | \appendixpage 204 | \else % toc only 205 | \if@chapter@pp % chapters 206 | \clear@ppage 207 | \fi 208 | \addappheadtotoc 209 | \fi 210 | \else 211 | \if@dopage@pp % page only 212 | \appendixpage 213 | \fi 214 | \fi 215 | \if@chapter@pp 216 | \if@dotitletoc@pp \@redotocentry@pp{chapter} \fi 217 | \else 218 | \if@dotitletoc@pp \@redotocentry@pp{section} \fi 219 | \if@dohead@pp 220 | \def\sectionmark##1{% 221 | \if@twoside 222 | \markboth{\@formatsecmark@pp{##1}}{} 223 | \else 224 | \markright{\@formatsecmark@pp{##1}}{} 225 | \fi} 226 | \fi 227 | \if@dotitle@pp 228 | \def\sectionname{\appendixname} 229 | \def\@seccntformat##1{\@ifundefined{##1name}{}{\csname ##1name\endcsname\ }% 230 | \csname the##1\endcsname\quad} 231 | \fi 232 | \fi}{% 233 | \@ppsaveapp\@pprestoresec} 234 | 235 | \newcommand{\setthesection}{\thechapter.\Alph{section}} 236 | \newcommand{\setthesubsection}{\thesection.\Alph{subsection}} 237 | 238 | \newcommand{\@resets@ppsub}{\par 239 | \stepcounter{@pps} 240 | \if@chapter@pp 241 | \setcounter{section}{0} 242 | \renewcommand{\thesection}{\setthesection} 243 | \else 244 | \setcounter{subsection}{0} 245 | \renewcommand{\thesubsection}{\setthesubsection} 246 | \fi 247 | \if@pphyper 248 | \if@chapter@pp 249 | \renewcommand{\theHsection}{\theH@pps.\setthesection}% 250 | \else 251 | \renewcommand{\theHsubsection}{\theH@pps.\setthesubsection}% 252 | \fi 253 | \def\Hy@chapapp{\appendixname}% 254 | \fi 255 | } 256 | 257 | \newenvironment{subappendices}{% 258 | \@resets@ppsub 259 | \if@chapter@pp 260 | \if@dotitletoc@pp \@redotocentry@pp{section} \fi 261 | \if@dotitle@pp 262 | \def\sectionname{\appendixname} 263 | \def\@seccntformat##1{\@ifundefined{##1name}{}{\csname ##1name\endcsname\ }% 264 | \csname the##1\endcsname\quad} 265 | \fi 266 | \else 267 | \if@dotitletoc@pp \@redotocentry@pp{subsection} \fi 268 | \if@dotitle@pp 269 | \def\subsectionname{\appendixname} 270 | \def\@seccntformat##1{\@ifundefined{##1name}{}{\csname ##1name\endcsname\ }% 271 | \csname the##1\endcsname\quad} 272 | \fi 273 | \fi}{} 274 | 275 | \newcommand{\@formatsecmark@pp}[1]{% 276 | \MakeUppercase{\appendixname\space 277 | \ifnum \c@secnumdepth >\z@ 278 | \thesection\quad 279 | \fi 280 | #1}} 281 | \newcommand{\@redotocentry@pp}[1]{% 282 | \let\oldacl@pp=\addcontentsline 283 | \def\addcontentsline##1##2##3{% 284 | \def\@pptempa{##1}\def\@pptempb{toc}% 285 | \ifx\@pptempa\@pptempb 286 | \def\@pptempa{##2}\def\@pptempb{#1}% 287 | \ifx\@pptempa\@pptempb 288 | \oldacl@pp{##1}{##2}{\appendixname\space ##3}% 289 | \else 290 | \oldacl@pp{##1}{##2}{##3}% 291 | \fi 292 | \else 293 | \oldacl@pp{##1}{##2}{##3}% 294 | \fi} 295 | } 296 | \endinput 297 | %% 298 | %% End of file `appendix.sty'. 299 | -------------------------------------------------------------------------------- /chap1-notes.tex: -------------------------------------------------------------------------------- 1 | 2 | people had pretty good ideas of certain things they wanted 3 | and they had piles of existing software 4 | the recognized something they could use, e.g. python on C, and just ran 5 | with it. it was never designed 6 | 7 | 8 | 1. technical computing 9 | 10 | - the power of abstraction 11 | - why they never asked 12 | . the current VHLLs must have gotten something right, but it doesn't have 13 | to be done the exact way they do it 14 | . SC vs. CS 15 | . ¶ about T.C. not being about just arrays, but flexibility 16 | 17 | - the remedy (``contributions of this thesis''), the breakthrough 18 | 19 | 20 | 21 | 2. analysis of abstraction 22 | 23 | - current abstractions that work well 24 | . matrices 25 | . blockbuster library calls (fft, lapack, blas) 26 | . composability of calls via key built-in types 27 | . dynamic typing 28 | 29 | - pushing it further -- what doesn't work well 30 | . bad abstractions => productivity problems 31 | . compile-time overloading, weak overloading, single dispatch, 32 | everything-is-a-dictionary, etc. 33 | 34 | - performance through abstraction 35 | 36 | there are 2 ways to design a language: (1) provide simple efficient abstractions 37 | and build out of that, or (2) provide bigger abstractions more directly useful 38 | to a domain expert. (2) often appears to work well, but in fact only approach 39 | (1) is truly viable. 40 | 41 | 3. julia (technical, innovations) 42 | 43 | - language design space 44 | - the many multiple dispatches 45 | - case studies, examples 46 | 47 | 48 | 4. julia (social/vision) 49 | 50 | 51 | - what does or should a language consist of? 52 | - what can be done for this problem at the language level of abstraction? 53 | - a design like NumPy argues the answer is ``nothing'' 54 | 55 | Today, object-oriented languages are used for scientific computing 56 | (particularly C++, Java, and Python). However in our opinion this 57 | application area has not fully explored the possibilities of OOP. In 58 | particular, generic functions have been one of the least popular 59 | OO concepts and yet, we will argue, are the most relevant to scientific 60 | computing. 61 | 62 | 63 | 64 | Unlike in other specialized domains (e.g. CAD software), these users 65 | are primarily interested in writing programs. 66 | 67 | People start out needing a few specialized routines, then eventually 68 | need ``glue'' of some kind, and eventually need a full language. 69 | The glue is an afterthought. 70 | 71 | Computational scientists often observe that they spend an amazingly 72 | small percentage of their time on the core computations that 73 | interest them, and lots of time on glue, verifying results, 74 | parsing and printing data, etc. This speaks to the need for 75 | general purpose languages. 76 | 77 | People are afraid to reinvent --- SVD etc. are considered black 78 | boxes not to be touched. 79 | 80 | We don't just need a faster matlab; for example a matlab with better 81 | loop optimizations or the like. Such a thing is fine to have, 82 | but we would argue it is not what people really need. 83 | Instead we propose powerful general-purpose abstractions that 84 | provide what is needed for technical computing as a special case. 85 | It is a technical computing language because it does *not* 86 | special case technical computing. 87 | 88 | 89 | At a very low level, the kinds of behaviors technical users expect 90 | from their languages do not match computer scientists' preconceptions 91 | of how languages should work. 92 | 93 | You should be able to define the meanings you want, not have them 94 | imposed on you. 95 | 96 | 97 | \section{Why a new language?} 98 | 99 | You cannot implement MATLAB arrays in C++ with the same level of 100 | convenience. 101 | 102 | %% 103 | 104 | Our goal is to declaratively specify the behaviors of abstractions 105 | important to scientific computing, in a way that can be executed 106 | efficiently and is arguably easy to write. 107 | 108 | By ``declaratively'', we mean in a manner that a compiler can 109 | realistically understand. All the behaviors we are interested in 110 | could of course be implemented with, say, imperative code, and indeed 111 | this is what has been done before, either inside a compiler, or inside 112 | an interpreter, or in a library for a sufficiently flexible language. 113 | These approaches have serious drawbacks. Implementing behaviors 114 | inside a compiler is effective for generating efficient code, but 115 | does not provide a way for users to easily implement their *own* 116 | behaviors. Imperative code inside an interpreter or library, on the other hand, 117 | does not provide a clear path to efficient execution. In theory, a 118 | partial evaluator could solve this problem, and this approach has been 119 | tried (REF). After adding minor annotations to a program, partial evaluation 120 | can work well. However, the biggest downside might be opacity: it is 121 | difficult to tell users how to write their code for the partial 122 | evaluator to be effective. We wish to try a different approach, that 123 | (1) permits a simpler performance model, and (2) stands a decent chance 124 | of being exploited *by accident* (i.e. users will tend to follow the performance 125 | model without much effort). 126 | 127 | 128 | Our method for doing this is generic functions with rich signatures 129 | (method specializers). Generic functions are rather well studied in the 130 | OOP literature (REF), but we feel that the kinds of method specializers 131 | that have been designed before are simply not powerful enough. 132 | Furthermore, if they are made powerful enough, surprising consequences 133 | ensue. 134 | 135 | 136 | We don't want to focus on compiler implementation tricks. We want a 137 | design such that fancy compiler and implementation tricks are not necessary. 138 | 139 | 140 | \section{How have times changed?} 141 | 142 | Use more memory, different point now in the resource/cost space 143 | 144 | In line with the new big data world of today? 145 | 146 | Julia is the language where people can and hopefully will collaborate 147 | to make better programs (different from 1980). 148 | 149 | Language has to not just know matrices, but also must be a web server 150 | and everything in between. (MATLAB knew it was also FFT and graphical, 151 | but the line was drawn) 152 | 153 | Want to get past only the experts knowing how to use arpack, lapack, 154 | etc. 155 | 156 | Prediction: the next ARPACK like thing will have one tenth the number 157 | of lines and have many more innovations and contributors (BLAS and 158 | lapack already have 4x redundancy thanks to single, double, complex, 159 | double complex repetition of routines) 160 | 161 | \section{Contributions of this thesis} 162 | -------------------------------------------------------------------------------- /chap1.tex: -------------------------------------------------------------------------------- 1 | \chapter{Introduction} 2 | 3 | Scientific computing has evolved from being essentially the only kind of 4 | computing that existed, to being a small part of how and why computers 5 | are used. 6 | Over this period of time, programming tools have advanced in terms of 7 | the abstractions and generalizations they are capable of. 8 | 9 | Science as a whole evolves through the incorporation of specialized bits 10 | of knowledge into more powerful general theories. 11 | There is a parallel in the world of programming languages: special-purpose 12 | languages have been subsumed by more powerful and general 13 | languages. 14 | How has this trend affected scientific computing? 15 | The surprising answer is: not as much as we would like. 16 | We see scientists and technical users generally either turning away 17 | from the best new programming languages, or else pushing them 18 | to their limits in unusual ways. 19 | 20 | \begin{singlespace} 21 | \begin{figure} 22 | \begin{center} 23 | \begin{tabular}{|llll|l|}\hline 24 | \multicolumn{4}{|c|}{Productivity} & Performance \\ 25 | \hline 26 | Matlab & Maple & Mathematica & SciPy & Fortress\\ 27 | SciLab & IDL & R & Octave & Chapel \\ 28 | S-PLUS & SAS & J & APL & X10 \\ 29 | Maxima & Mathcad & Axiom & Sage & SAC \\ 30 | Lush & Ch & LabView & O-Matrix & ZPL \\ 31 | PV-WAVE & Igor Pro & OriginLab & FreeMat &\\ 32 | Yorick & GAUSS & MuPad & Genius &\\ 33 | SciRuby & Ox & Stata & JLab &\\ 34 | Magma & Euler & Rlab & Speakeasy &\\ 35 | GDL & Nickle & gretl & ana &\\ 36 | Torch7 & A+ & PDL & Nial & \\ 37 | \hline 38 | \end{tabular} 39 | \end{center} 40 | \caption[49 technical computing languages]{ 41 | \small{ 42 | 49 technical computing languages classified as primarily designed for productivity or performance 43 | } 44 | } 45 | \label{gangof40} 46 | \end{figure} 47 | \end{singlespace} 48 | 49 | In fact, we have discovered at least \emph{49} programming languages 50 | designed for technical computing since Fortran (figure~\ref{gangof40}). 51 | This high number begs for an explanation. 52 | We propose that technical users crave the flexibility to pick notation 53 | for their problems, and language design --- the highest level of 54 | abstraction --- is where you go when you need this level of flexibility. 55 | %Language design is associated with the highest level of abstraction. 56 | The desire for scientists to rework their code is not so surprising when one reflects 57 | on the tradition of inventing new notation in mathematics and science. 58 | %This certainly 59 | %helps distinguish scientific programming from other application areas. 60 | 61 | The need for language-level flexibility is corroborated by 62 | the ways that the technical computing domain uses general purpose 63 | languages. 64 | Effective scientific libraries extensively employ 65 | polymorphism, custom operators, and compile time abstraction. 66 | Code generation approaches (writing programs that write programs) 67 | are unusually common. 68 | Most of these techniques are presently fairly difficult to use, and so 69 | programmers working at this level give up the notational conveniences 70 | of the purpose-built languages above. 71 | 72 | The goal of this thesis is to identify and address the fundamental 73 | issues that have made productive and performant technical computing 74 | so difficult to achieve. 75 | %We attempt to make the smallest 76 | %change that can be provided by a simple high-level language 77 | We ask: which general purpose language would \emph{also} be able to handle 78 | technical computing, such that the above workarounds would not have 79 | been necessary? 80 | 81 | % our theory is that t.c. is not just about matrices and numbers 82 | % but a specific pattern of code specialization and dispatch that 83 | % can be automated. 84 | 85 | \iffalse 86 | Compiler techniques, library design, high-performance 87 | computational kernels, new algorithms, and approaches to parallelism are 88 | all important to technical computing. 89 | However these sorts of technologies can usually be applied to multiple 90 | languages, as has happened in the C and Fortran language families. 91 | %They do not by themselves insist that a new language be developed. 92 | However in conjunction with a new language, these technologies can flourish. 93 | Indeed, we believe that language design 94 | has reached a level of importance that even (perhaps temporarily) supersedes 95 | the traditional focus of cache utilization and the use of matrix operations. 96 | \fi 97 | 98 | In brief, our answer is to \emph{integrate code selection and specialization}. 99 | The aforementioned flexibility requirement can be explained as 100 | a sufficiently powerful means for \emph{selecting} which piece of code 101 | to run. 102 | %This notion subsumes method dispatch, function overloading, 103 | %and potentially even branches. 104 | When such mechanisms are used in technical computing, there is nearly 105 | always a corresponding need to \emph{specialize} code for specific cases 106 | to obtain performance. 107 | Polymorphic languages sometimes support forms of specialization, 108 | but often only through a designated mechanism (e.g.\ templates), or 109 | deployed conservatively out of resource concerns. 110 | We intend to show that an equilibrium point in the design space can be found 111 | by combining selection and specialization into a single appropriately designed 112 | dynamic type-based dispatch mechanism. 113 | %The specific design is identified via subtyping theories and closure under 114 | %data flow operations. 115 | 116 | 117 | %\subsubsection{Thesis statement} 118 | 119 | %Integrating code selection and specialization using 120 | %type-based dynamic dispatch captures the performance and 121 | %productivity requirements of technical computing. 122 | 123 | 124 | % why dynamic dispatch? 125 | %% somewhat counter-intuitively, dynamic dispatch can be good for performance 126 | %% since it permits invoking the most specialized possible method. 127 | %% static overloading can lead to calling a sub-optimal case when multiple 128 | %% overloads exist for the sake of performance. 129 | 130 | %Extensive code specialization is a key feature of 131 | %technical computing. ``what to specialize on'' has been an open problem. 132 | %our types are a possible solution to this for two reasons: 133 | 134 | %the amazing thing about programming languages it that a better 135 | %explanation can directly lead to better performance!) 136 | 137 | %% Specialization entails program analysis. By necessity, a language's 138 | %% code selection mechanisms must inform this process, to ensure the 139 | %% correctness of the analysis. A central argument of this thesis is that 140 | %% specialization should feed back into selection, allowing the 141 | %% \emph{approximate values} processed by a compiler to be used in the 142 | %% source language for dispatch. We argue that this is the key feature 143 | %% missing from the present generation of dynamically typed languages. 144 | %This conclusion would not be surprising to advocates of static 145 | %type systems, but the approach we propose is actually a run time 146 | %mechanism that does not restrict the class of valid programs. 147 | 148 | %Why integrate code specialization and code selection? 149 | %\begin{itemize} 150 | %\item specialization requires selection anyway 151 | %\item simpler system 152 | %\item can sometimes collapse 2 layers of dispatch into 1 153 | %\item can replace library code with a code generator without either changing 154 | % client code *or* any extra overhead 155 | %\end{itemize} 156 | 157 | %Instead we intend to argue that, at a 158 | %deeper level, it is about certain kinds of flexibility, particularly 159 | %flexibility in the behavior of key operators and functions. This flexibility 160 | %is needed to maximize composability and reusability in scientific code. 161 | %Without it, certain programs may be easy to write today, but changing 162 | %functional and performance requirements can become difficult to meet. 163 | 164 | \section{The technical computing problem} 165 | \label{sec:tcproblem} 166 | 167 | \begin{singlespace} 168 | \begin{table} 169 | \begin{center} 170 | \def\arraystretch{1.25} 171 | \begin{tabular}{|l|l|}\hline 172 | \textbf{Mainstream PL} & \textbf{Technical computing} \\ 173 | \hline \hline 174 | classes, single dispatch & complex operators \\ 175 | \hline 176 | separate compilation & performance, inlining \\ 177 | \hline 178 | parametric polymorphism & ad hoc polymorphism, extensibility \\ 179 | % - concrete reuse of generated code 180 | \hline 181 | static checking & experimental computing \\ 182 | \hline 183 | modularity, encapsulation & large vocabularies \\ 184 | \hline 185 | eliminating tags & self-describing data, acceptance of tags \\ 186 | \hline 187 | data hiding & direct manipulation of data \\ 188 | \hline 189 | \end{tabular} 190 | \end{center} 191 | \caption[Programming language priorities]{ 192 | \small{ 193 | Priorities of mainstream object-oriented and functional programming language research and 194 | implementation compared to those of the technical computing domain. 195 | } 196 | } 197 | \label{PLpriorities} 198 | \end{table} 199 | \end{singlespace} 200 | 201 | Table~\ref{PLpriorities} compares the general design priorities of mainstream 202 | programming languages to those of technical computing languages. 203 | The priorities in each row are not necessarily opposites or even mutually exclusive, 204 | but rather are a matter of emphasis. 205 | It is certainly possible to have both parametric and ad hoc polymorphism within 206 | the same language, but syntax, recommended idioms, and the design of the standard 207 | library will tend to emphasize one or the other. 208 | Of course, the features on the left side can also be useful for technical computing; 209 | we exaggerate to help make the point. 210 | 211 | It is striking how different these priorities are. 212 | We believe these technical factors have contributed significantly to the persistence 213 | of specialized environments in this area. 214 | Imagine you want just the features on the left. 215 | Then there are many good languages available: Haskell, ML, Java, C\#, perhaps C++. 216 | Getting everything on the right, by comparison, seems to be awkward. 217 | The most popular approach is to use multiple languages, as in NumPy~\cite{numpy}, 218 | with a high-level productivity language layered on top of libraries 219 | written in lower-level languages. 220 | Seeking a similar trade-off, others have gone as far as writing a C++ 221 | interpreter \cite{vasilev2012cling}. 222 | 223 | % something about complicated architecture and not-always-good performance 224 | %technical computing systems have an unusually large amount of 225 | %``failure of abstraction'' --- manual duplication of facts 226 | %all over the system. imagine changing from column-major to 227 | %row-major. 228 | 229 | %problem of finding connections between array programming and OOP. 230 | %array programming is a powerful paradigm for describing computational 231 | %kernels operating over potentially large amounts of data. 232 | 233 | %an ``object system'' in this context is often considered a separate 234 | %part of the language, to be used only when arrays no longer 235 | %suffice. 236 | 237 | It is clear that any future scientific computing language will need to be able to 238 | match the performance of C, C++, and Fortran. 239 | To do that, it is almost certain that speculative optimizations such as tracing 240 | \cite{tracingjit} will not be sufficient --- 241 | the language will need to be able to \emph{prove} facts about types, or at least 242 | let the user request specific types. 243 | It is also clear that such a language must strive for maximum convenience, or else 244 | the split between performance languages and productivity languages will persist. 245 | 246 | It is fair to say that two approaches to this problem are being tried: one is 247 | to design better statically typed languages, and the other is to apply 248 | program analysis techniques to dynamically typed languages. 249 | Static type systems are getting close to achieving the desired level 250 | of flexibility (as in Fortress \cite{fortresspec} or Polyduce \cite{polyduce1}, 251 | for instance), 252 | %, but it is still too early to call a winner between these two 253 | %approaches (if, indeed, there even needs to be a winner). 254 | but here we will use a dynamically typed approach. 255 | We are mostly interested in types in the sense of \emph{data types} and 256 | \emph{partial information} 257 | (for an excellent discussion of the many meanings of the word ``type'' 258 | see \cite{Kell2014}). 259 | Additionally, some idioms in this domain appear to be inherently, or at least 260 | naturally, dynamically typed (as we will explore in chapter~\ref{chap:2}). 261 | The mechanism we will explore provides useful run time behavior and, we hope, 262 | performance improvements. 263 | Many approaches to statically checking its properties are likely possible, 264 | however we leave them to future work. 265 | 266 | %Second, insufficient static checking is most likely not the current limiting 267 | %factor in scientific computing productivity. 268 | %In our view the first priority is to get the combination of 269 | %performance and flexibility we already know users want, and then try to 270 | %improve safety later. 271 | 272 | 273 | \section{The importance of code selection} 274 | 275 | Most languages provide some means for selecting one of many pieces of code 276 | to run from a single point in the program. 277 | This process is often called \emph{dispatch}. 278 | High-level languages, especially ``dynamic'' languages tend to provide a 279 | lot of flexibility in their dispatch systems. 280 | This makes many sophisticated programs easier to express, but at a considerable 281 | performance cost. 282 | 283 | There has been a large amount of work on running dynamic languages faster 284 | (notable examples are Self~\cite{selflang}, and more recently PyPy~\cite{pypyjit}). 285 | These efforts have been very successful, but arguably leave something 286 | out: a better interface to performance. 287 | % put differently: HLLs excel at providing certain features, but not at 288 | % defining other things like those that still perform well 289 | Performance-critical aspects of most dynamically typed languages (e.g.\ arithmetic) 290 | have fixed behavior, and it is not clear what to do when your code does not 291 | perform as well as it could. 292 | Adding type annotations can work, but raises questions about how powerful 293 | the type system should be, and how it relates to the rest of the language. 294 | We speculate that this relative lack of control keeps experts away, 295 | perpetuating the split between performance and productivity languages. 296 | 297 | According to our theory, the issue is not really just a lack of types, 298 | but an exclusive focus on specialization, and not enough on selection. 299 | %Code selection is crucial to performance at all levels: at the lowest 300 | %level, it means picking the best machine instruction, 301 | %and at the highest level it means picking the best algorithm. 302 | In technical computing, it is often so important to select the best 303 | optimized kernel for a problem that it is worth doing a slow dynamic 304 | dispatch in order to do so. 305 | Most of the productivity languages mentioned above are designed 306 | entirely around this principle. 307 | But their view of code selection is incomplete: the dispatch 308 | mechanisms used are ad hoc and not employed consistently. 309 | Even when an optimizing compiler for the source language is developed, 310 | it does not necessarily take all relevant forms of dispatch into 311 | account. 312 | For example, NumPy has its own dispatch system underneath Python's, 313 | and so is not helped as much as it could be by PyPy, which only 314 | understands Python method selection. 315 | 316 | A dispatch specification, for example a method signature in a 317 | multimethod system, describes when a piece of code is applicable. 318 | %A more powerful dispatch system brings many benefits. 319 | A more expressive dispatch system then allows code to be written 320 | in smaller pieces, helping the compiler remove irrelevant code 321 | from consideration. 322 | It is also more extensible, providing more opportunities to 323 | identify special cases that deserve tailored implementations. 324 | Method-at-a-time JIT compilers 325 | (e.g.\ \cite{grcevski2004java, Suganuma:2005:DED:1075382.1075386}) 326 | can specialize method bodies on all arguments, and so are 327 | arguably already equipped to implement and optimize multiple dispatch 328 | (even though most object-oriented languages do not offer it). 329 | At the same time, dispatch specifications are a good way to provide 330 | type information to the compiler. 331 | %For example an optimizing compiler for Self~\cite{Dean:1994:TBI:182590.182489} 332 | %tracked all argument types per call site to help guide inlining. 333 | %Such a system might even use multiple dispatch internally to 334 | %select optimized methods. 335 | %In that case, why not expose that capability to the programmer? 336 | 337 | %%%%%%%%% 338 | %compilation is expensive, so traditional languages have forced the equation 339 | %(what you can generate code for) = (known at compile time) 340 | %wanting specialized code for more dynamic properties is the issue. 341 | %%%%%%%% 342 | 343 | %how to write things so they perform, and how to 344 | %add algorithms for special cases in an extensible way 345 | 346 | %performance is related to dispatch since it lets you describe when some 347 | %efficient kernel is applicable. 348 | 349 | % also for linking purposes the compiler will want to leave some 350 | % record of what it has done, i.e. what assumptions it has made to 351 | % generate the code it left behind. 352 | % here you will want a type system. 353 | 354 | %% Why do we prefer method signatures to imperative logic? 355 | %% - it's extensible 356 | %% - its declarative style is more compact 357 | %% - allows writing functions in small pieces 358 | %% the more descriptive the types, the smaller the pieces 359 | %% might make compiler more efficient; removes large bits of code from 360 | %% consideration just from looking at types. don't need to analyze a 361 | %% large function just to discover that only a small part of it 362 | %% remains. 363 | %% - clearer performance model. it's hard for programmer to guess 364 | %% when the compiler will statically evaluate an arbitrary expression 365 | %% - allows defining semantics about things that are optimized, but 366 | %% *not* compile-time constants. 367 | %% method table can be (ab)used as a mutable lookup table structure. 368 | 369 | %Finally, it is often the case that a seemingly minor 370 | %modification to a type system makes type checking undecidable. Rejecting 371 | %such a system is totally reasonable. However if we are willing to 372 | %accept undecidable checking from the beginning, opportunities arise to 373 | %simplify and increase the power of the language. 374 | 375 | % one of our main innovations is a way to deftly navigate between two 376 | % problems 377 | 378 | %% \subsection{The excess power problem} 379 | 380 | %% We claim that the amount of information that can be statically inferred 381 | %% exceeds most dynamic languages' capacity to exploit it. 382 | %% Much work has been done on program analysis and optimization techniques 383 | %% for dynamically typed languages. 384 | %% When static analyses (often incorporating run time information) are applied 385 | %% to dynamically typed programs, it is typically possible to recover a 386 | %% significant amount of type information (e.g. \cite{druby}). 387 | %% What, then, can one do with this information? 388 | %% If the goal is performance, various partial evaluations can be done: 389 | %% generating code without type checks, removing branches, type-specializing 390 | %% the storage of variables, and compile time method lookup are all valuable 391 | %% and yield large real-world gains. 392 | 393 | %and might use multiple dispatch \emph{internally} to select implementations 394 | %at run time. 395 | %% Arguably, if method calls are dispatched on the first argument, but the types of all 396 | %% arguments can be inferred, some power has been ``left on the table'' --- 397 | %% we could have had multimethods for little extra cost. 398 | %% This argument does not apply equally to statically typed languages, since they 399 | %% cannot simply ``switch'' their functions to generic functions without significant 400 | %% consequences for type checking. 401 | 402 | %% This ``excess power'' problem applies to data structures as well. 403 | %% For example, static or run time analysis might reveal that a certain array 404 | %% can be represented as a native \texttt{Int32} array \cite{Bolz2013}. 405 | %% If this information is not reflected in the source language, then 406 | %% certain uses like passing data to native code become unnecessarily more 407 | %% complicated. 408 | %% And if one is going to implement homogeneous arrays anyway, why not 409 | %% let programmers request them? 410 | 411 | %% Some levels of performance are difficult to reach with implicitly 412 | %% specialized code and data. 413 | %% Given the knowledge that an array contains only \texttt{Int32} data, 414 | %% we might want to go beyond essential optimizations like storing intermediate 415 | %% values in registers, and actually use different algorithms. 416 | %% For example, in Miller-Rabin primality testing~\cite{Rabin1980128}, checking 417 | %% three ``witness'' values suffices for all 32-bit arguments, but up to seven 418 | %% values might be needed for 64-bit arguments. 419 | %% In cryptographic applications, exploiting this difference in an inner loop 420 | %% could bring significant benefits. 421 | 422 | 423 | %\subsection{The divergence problem} 424 | 425 | The remaining question is what exactly we should dispatch on. 426 | Naturally, it might be nice to be able to dispatch on any criteria 427 | at all. 428 | However there is a balancing act to perform: if dispatch signatures 429 | become too specific, it becomes difficult to predict whether they 430 | will be resolved statically. 431 | At one end of the spectrum are mechanisms like static overloading 432 | in C++, where the compiler simply insists that it be possible to 433 | resolve definitions at compile time. 434 | At the other end of the spectrum, we might dispatch on arbitrary 435 | predicates (as in the Scmutils system~\cite{Sussman:2001:SIC:375178}). 436 | % TODO more about scmutils 437 | We do neither of these. 438 | Instead, we only try to make it \emph{more likely} that types can be 439 | statically inferred. 440 | We do this by considering the kinds of types that arise in data flow 441 | type inference, and allowing dispatch on those. 442 | This will be developed in detail in section~\ref{sec:typesystem}. 443 | 444 | %Instead, our dispatch is based on \emph{sets of values that are robust 445 | %under evaluation}: abstract evaluation over such sets is less likely 446 | %to diverge. 447 | 448 | % TODO: needs to be clearer 449 | %% For example, consider the set $\{1,2\}$. 450 | %% This set is not closed under ``natural'' functions. 451 | %% As we evaluate a recursive function over this abstract value, the 452 | %% set will typically grow, and the fixed point will be much larger 453 | %% than the original set. 454 | %% So while specializing a method for $\{1,2\}$ could in some rare 455 | %% cases be useful, it also leads to unpredictable performance. 456 | %% To find reasonably robust sets to dispatch on, we 457 | %% begin with structured type tags and take the closure under data flow 458 | %% operations. 459 | 460 | %However as a dispatch system gets more powerful, its utility as a 461 | %performance model degrades. 462 | % TODO: introduce before this how dispatch can be a performance model 463 | 464 | %% Another problem that occurs when analyzing programs with complex 465 | %% type behavior is divergence: the analysis is likely to infer an 466 | %% overly large result from failing to eliminate enough possible 467 | %% behaviors. 468 | %% Narrowing the inferred types requires some extra source of type 469 | %% information. 470 | %% Multimethod signatures work well for this purpose. 471 | 472 | %% past approaches include: optional user annotations, or a built-in 473 | %% database of function type behavior, determined empirically or 474 | %% analytically. 475 | %% to solve the problem in general, library behavior should not be 476 | %% built-in to the compiler. 477 | %% however, when functions that are both highly complex and performance 478 | %% critical are implemented at the library level it can be difficult 479 | %% to ensure they are sufficiently optimized. 480 | 481 | % specializer must decide when to widen, when to stop going around 482 | % loops, etc. 483 | % this is an opaque process. 484 | % there is an essential divide between what it will statically 485 | % evaluated, and what it won't. 486 | 487 | %% However the divergence problem also places a limit on what 488 | %% kinds of dispatch specifications are useful to program analyses: 489 | %% some sets of values tend to be more robust under execution 490 | %% than others. 491 | 492 | 493 | % TODO: 494 | % claim dispatch works better on approximate type info than branches 495 | % when you have unionall types. 496 | % dispatch is also extensible and declarative. 497 | 498 | % doing analysis only, you can use arbitrarily complex types, but 499 | % you are then limited by what the language can ``consume'', or 500 | % by the sophistication of the t-functions you write. 501 | % adding dispatch, the types become an abstraction under user 502 | % control, so need to be meaningful. 503 | 504 | %% what to dispatch on? dispatch power has been extended in many ways, but 505 | %% there is no real limit to what somebody might want to dispatch on. 506 | %% so what to do? 507 | %% some sets of values are more robust under computation than others 508 | %% (closure properties). 509 | %% identify those sets using data flow concerns. 510 | 511 | %% say we have a method defined for integers, and also for the special cases 512 | %% ``2'' and ``odd integers''. a realistic implementation 513 | %% will group all of these under ``integer'', and ideally generate a couple 514 | %% branches to handle the other cases. we argue the concept of ``integer'' 515 | %% here is a more robust set, and so a more fundamental language concept. 516 | 517 | %- vs predicate dispatch: we extend dispatch power in a different direction, 518 | %guided by semantic subtyping. goal is maximum power that still yields high 519 | %likelihood of resolving many calls to a single implementation. 520 | 521 | 522 | \section{Staged programming} 523 | 524 | In demanding applications, selecting the right algorithm might not 525 | be enough, and we might need to automatically \emph{generate} code 526 | to handle different situations. 527 | While these cases are relatively rare in most kinds of programming, 528 | they are remarkably common in technical computing. 529 | Code generation, also known as \emph{staged programming}, raises 530 | several complexities: 531 | 532 | \vspace{-3ex} 533 | \begin{singlespace} 534 | \begin{itemize} 535 | \item What is the input to the code generator? 536 | \item When and how is code generation invoked? 537 | \item How is the generated code incorporated into an application? 538 | \end{itemize} 539 | \end{singlespace} 540 | 541 | \noindent 542 | These questions lead to practical problems like ad hoc custom syntax, 543 | extra build steps, and excessive development effort (writing parsers and 544 | code generators might take more work than the core problem). 545 | If code needs to be generated based on run time information, then a 546 | % TODO cite julia GPU paper that did this 547 | staged library might need to implement its own dispatch mechanism 548 | for invoking its generated code. 549 | 550 | We find that our style of dynamic type-based dispatch provides 551 | an unusually convenient substrate for staged programming. 552 | The reason is that the types we dispatch on contain enough 553 | information to drive code generation for a useful class of problems, 554 | while also allowing 555 | the dispatch mechanism to be reused for caching and invoking staged code. 556 | Code generators are invoked automatically by 557 | the compiler, and the results can be called directly or even inlined 558 | into user code. 559 | Libraries can switch to staged implementations with method-level granularity 560 | without affecting client code. 561 | 562 | %past (static) type systems for dispatch were designed to ensure the absence of 563 | %no-method errors and ambiguities (completeness and uniqueness). our goal 564 | %is instead to statically resolve methods. this is inherently heuristic and 565 | %best-effort. since static types shouldn't affect program behavior, we 566 | %conclude that the dispatch must be dynamic, which is happily the same 567 | %conclusion you would reach if you simply wanted dynamic typing. 568 | 569 | %it is quite possible that some static type system will work well for this 570 | %however we defer this question. 571 | %interesting variants: 572 | %- require static single method matches 573 | %- reject programs with no-method errors 574 | %- reject programs that yield Unions 575 | 576 | %%%%%% 577 | 578 | \section{Summary of contributions} 579 | 580 | \iffalse 581 | We began with a belief that we could design a technical computing language 582 | sufficiently novel and powerful that it could gain popularity 583 | in real applications. 584 | The key idea was that language level abstractions could bring ease of use, 585 | performance, and wider applicability to technical computation. 586 | It is far from trivial to analyze and design this right set of abstractions 587 | This thesis contributes a deep analysis of our findings. 588 | 589 | At the very core, the novel idea in this 590 | thesis is the very notion that technical computing is amenable to deep language 591 | analysis. 592 | As simple as this may sound, many in the technical computing world did not 593 | understand how a computer science approach to technical computing could be 594 | useful to them. 595 | Our personal experience describing the research plan to 596 | the computer science world might be 597 | characterized by the view that this space consists of library 598 | functions such as FFTs and matmuls and would not be as interesting 599 | to analyze. 600 | Despite the early discouraging viewpoints, five years later, 601 | the power of language analysis is manifesting itself 602 | theoretically, opening new research directions, and practically in that Julia 603 | has worldwide name recognition and worldwide adaption. 604 | \fi 605 | 606 | \iffalse 607 | Our first contribution is a discussion of the nature of technical computing 608 | that suggests which language-level abstractions might best support its use 609 | cases. 610 | Simply put technical computing has by and large happened 611 | without sufficient probing and analysis as to what it is. 612 | 613 | Based on the theory that technical computing is characterized by complex 614 | operators and particular combinations of binding time behavior. 615 | \fi 616 | 617 | At a high level, our contribution is to identify the priorities 618 | that have been implicit in the designs of technical computing systems, 619 | and suggest fundamental changes that would better serve those 620 | priorities. 621 | In the process, we make the following specific contributions: 622 | 623 | \begin{itemize} 624 | \item To our knowledge, the first complete technical computing system 625 | developed by applying automatic type specialization over libraries 626 | written in a single high-level language. 627 | Our system is the first to combine by-default specialization on all 628 | arguments with type widening to automatically limit specialization. 629 | %Past systems have applied specialization to a set of user-level routines. 630 | %We show that it can be used for an entire system. 631 | 632 | \item A novel dispatch system that supports a form of set-theoretic types 633 | including variadic methods. 634 | We contribute an answer to the question of how powerful a dynamic dispatch 635 | system should be: even if type checking is not done, dispatch should still 636 | use types that support decidable subtyping. 637 | %The resulting system is both more and less powerful than most previous 638 | %dispatch systems. 639 | %should be, by suggesting that they reflect types discoverable by flow 640 | %analysis. 641 | %Interestingly, the resulting system seems to fall just short of the trap 642 | %of undecidable subtyping. 643 | 644 | %We introduce the idea of integrated code selection and specialization. 645 | %This leads to a dispatch system that provides a novel combination of 646 | %performance and expressiveness. 647 | 648 | %It provides ``diagonal dispatch'' 649 | %Using data flow types to drive the design leads to novel dispatch features: 650 | %- diagonal dispatch 651 | %- unifying variadic methods with regular types 652 | %- predictable performance without giving up flexibility 653 | 654 | %This leads to easy-to-use polymorphism, prioritizing 655 | %flexibility and performance over nearly all else. 656 | 657 | % Something about dispatch for performance. Given a performance kernel, it takes 658 | % a lot of info to describe when it is applicable. 659 | 660 | % dispatch on everything, not just classes 661 | 662 | % ?? % \item Easy polymorphism 663 | 664 | %- library writers can decide what to put at the type level without affecting users, 665 | % dropping type parameters 666 | %- a single mechanism to cover overloading, dispatch, and specialization 667 | %%%- using types, but mostly for dispatch, where they can be used gradually 668 | %- specialize by default (makes static polymorphism less of a black art) 669 | %- types as ordinary values 670 | 671 | \item A subtyping algorithm for our system, including a straightforward 672 | implementation. 673 | This subtyping system is adoptable by dynamically typed languages that might 674 | benefit from a richer abstract value domain, for example for 675 | describing method applicability or performance-critical aspects of data structures. 676 | 677 | % we design a type system for this. and introduce the ``evaluate softly 678 | % and carry a big subtype relation'' school of thought. 679 | 680 | % we provide a straightforward implementation that should be easy to 681 | % translate to other languages. 682 | 683 | % at this point, certain language implementation techniques have been fairly widely 684 | % disseminated: how to write a parser, how to write a bytecode VM, how to 685 | % design an object system, etc. 686 | % subtyping systems are still relatively esoteric, often not even mentioned 687 | % in introductory texts. 688 | 689 | %\item a novel form of staged programming? 690 | 691 | \item We demonstrate a novel combination of staged programming with generic 692 | functions that allows staging to be invoked implicitly, leading to improved 693 | usability. 694 | 695 | 696 | \item We show how to implement key features of technical computing languages 697 | using our dispatch system, eliminating the need for them to be built in. 698 | We preserve flexibility while gaining efficiency and extensibility. 699 | (James Morris eloquently observed that 700 | ``One of the most fruitful techniques of language analysis is explication through 701 | elimination. 702 | The basic idea is that one explains a linguistic feature by showing 703 | how one could do without it.''~\cite{morris}) 704 | 705 | %the application of our approach to 706 | %features of technical computing environments that have not been subject to such 707 | %analysis before. 708 | %We provide an example application that shows how to use our language to 709 | %more easily solve a difficult computational problem. 710 | 711 | % hopefully will provide useful examples for evaluating future dispatch 712 | % systems, object systems, and type systems 713 | 714 | \item Finally, we contribute the Julia software system, currently a 715 | growing free software project, demonstrating that our approach is both practical 716 | and appealing to a significant number of users. 717 | 718 | \end{itemize} 719 | -------------------------------------------------------------------------------- /chap6.tex: -------------------------------------------------------------------------------- 1 | \chapter{Conclusion} 2 | 3 | %% A generation of dynamic languages have been designed by trying variants of 4 | %% the class-based object oriented paradigm. This process has been aided by 5 | %% the development of standard techniques (e.g. bytecode VMs) and reusable 6 | %% infrastructure such as code generators, garbage collectors, and whole VMs 7 | %% like the JVM and CLR. 8 | 9 | %% It is possible to envision a future generation of languages that generalize 10 | %% this design to set-theoretic subtyping instead of just classes. This next 11 | %% generation will require its own new tools, such as partial evaluators (already 12 | %% under development in PyPy and Truffle). One can also imagine these future 13 | %% language designers wanting reusable program analyses, and tools for 14 | %% developing lattices and their operators. 15 | 16 | It is probably not possible to define technical computing precisely. 17 | That is just as well, since being ``domain specific'' is not our goal. 18 | Programming languages want to be general purpose, and evidence suggests 19 | people want them to be as well. 20 | Recent analysis of programming language adoption~\cite{Meyerovich:2013:EAP:2509136.2509515} 21 | found that when a language is popular only within a certain niche, it is not 22 | usually the most popular language in that niche --- broadly popular, 23 | general languages are still preferred. 24 | We speculate that wherever this property fails to hold, there is an opportunity 25 | to improve our general purpose languages. 26 | As noted in the introduction, at least some forms of technical computing, 27 | however imprecisely defined, have surely been just such a case. 28 | This dissertation takes a small step towards understanding this niche in a 29 | more general framework. 30 | 31 | %we see it as a motivation, not a target 32 | %want to be more general, not domain specific 33 | 34 | %``I've yet to hear anyone explain how you decide what are the boundaries of a `domain-specific' language. Isn't the `domain' mathematics and science itself?''~\cite{bobharperdsl} 35 | 36 | %tc is not a domain, and doesnt need to be: 37 | % \cite{meyerovich2012socio} about appealing to some domain first 38 | % technical computing was ripe for such a treatment 39 | 40 | We began by observing that technical computing users have priorities 41 | that have rarely been addressed directly by programming languages. 42 | Arguably, even many of the current technical computing languages only 43 | address these priorities for a subset of cases. 44 | % in particular, they want flexible notation, and code specialized 45 | % for information regardless of when that information is known. 46 | In some sense all that was missing was an appropriate notion of 47 | partial information. 48 | Partial information has many uses. 49 | It describes sets of values, and therefore code applicability. 50 | It describes what sorts of information a compiler can determine, 51 | contributing to a performance model. 52 | It leads to staged programming: generating code requires 53 | knowing something about what needs to be computed, but not everything, so that 54 | generated code can be reused enough to be worthwhile. 55 | Of course, this sounds a lot like a type system. 56 | However programmers in our area of interest, and working in dynamic languages 57 | generally, have resisted this. 58 | In our view this can change as more uses of types are discovered and 59 | advocated. 60 | Surely there are many more ways to obtain useful run time behavior based on 61 | partial information. 62 | 63 | The rest of this concluding chapter will reflect on what more could be done. 64 | 65 | % what's wrong with dynamic languages is not just a lack of static 66 | % guarantees, but that they don't seem to be pareto optimal. 67 | % actually not enough is done with dynamic typing: you give up type 68 | % checking, and all you get is untyped dictionaries in return? 69 | 70 | % we know these programs need more organization and type info. 71 | % this is the first truly viable approach 72 | % - bad that they need to think about type stability, but 73 | % also good that is relatively easy to grasp, and it gets 74 | % people thinking about it who wouldn't normally 75 | % - the types give people the tools to deal with it 76 | % - can't pretend that people wont have to worry about this stuff; 77 | % it's fundamental 78 | 79 | %exploiting partial information is key. 80 | %dispatch was an especially natural way to do this, 81 | %are there others? 82 | %What else can we do with partial information as part of a programming 83 | %model? 84 | % somehow being dual to ML-family languages; what's hard for them is 85 | % easy for us and vice versa. 86 | 87 | \section{Performance} 88 | 89 | If we are interested in abstraction, then type specialization is the 90 | first priority for getting performance. 91 | However in a broader view there is much more to performance. 92 | For example ``code selection'' appears in a different guise in the 93 | idea of \emph{algorithmic choice}~\cite{Ansel:2009:PLC:1542476.1542481,Ansel:2014:OEF:2628071.2628092}. 94 | At any point in a program, we might have a choice of several algorithms and 95 | want to automatically pick the fastest one. 96 | Julia's emphasis on writing functions in small pieces and describing 97 | applicability seems naturally suited to this functionality. 98 | A possible approach could be to dispatch on components of an execution plan 99 | object. 100 | 101 | High-performance code generators such as Spiral~\cite{Puschel:2004:SGP:1080647.1080687} 102 | often specialize on data size. 103 | Julia makes it easy to represent array sizes in the type system, and the 104 | usual pattern of dynamic dispatch to specialized code could be applicable 105 | in these cases as well. 106 | % immutable arrays, specializing on size 107 | 108 | %There are several key aspects of performance programming that our design 109 | %does not directly address, e.g. storage and in-place optimizations. 110 | 111 | While Julia includes a distributed computing library, we have not 112 | sufficiently explored shared memory parallelism. 113 | The Cilk model~\cite{Joerg96,Randall98} would be a good match for the 114 | level of performance and abstraction we aim for. 115 | 116 | 117 | \section{Other future work} 118 | 119 | As with any practical system, we must begin the process of trying to get back 120 | what our design initially trades away. 121 | For example, the specialization-based polymorphism we use does not support 122 | separate compilation. 123 | Fortunately that's never stopped anyone before: C++ templates have the same 124 | problem, but separately compiled modules can still be generated. 125 | We plan to do the same, with the same cost of re-analyzing all relevant code 126 | for each module. 127 | Another approach is to use layering instead of separate modules. 128 | Starting with the core language, one next identifies and compiles a useful base 129 | library. 130 | That layer is then considered ``sealed'' and can no longer be extended --- 131 | it effectively becomes part of the language. 132 | Applications using this library can be compiled more efficiently. 133 | More layers can be added (slowest-changing first) to support more specific 134 | use cases. 135 | This is essentially the ``telescoping languages'' approach~\cite{telescoping}. 136 | 137 | An ideal approach to higher-order programming in Julia remains somewhat 138 | elusive. 139 | For example the \texttt{map} function in section~\ref{sec:implementingmap} 140 | always returns an array of element type \texttt{Bottom} when the input 141 | array is empty, which is fully defensible but still confusing and surprising 142 | to many programmers. 143 | It is possible the situation could be improved by some syntactic sugar for 144 | nominal arrow types. 145 | 146 | Approaches to static type checking are also worth thinking about. 147 | Most importantly, we feel we have the priorities right: first introduce 148 | at least some kind of type information, then gradually add checks and 149 | tooling to improve safety. 150 | For example, a useful alternative form of the language could require 151 | types to match when control flow edges meet. 152 | Tools like \texttt{TypeCheck.jl}~\cite{typecheckjl} can be used to take 153 | better advantage of whatever type information we are able to infer. 154 | 155 | %There are many opportunities to incorporate more detailed static analysis. 156 | 157 | % higher resolution type info degrades SNR 158 | 159 | %% \begin{itemize} 160 | %% \item formalize more details of dispatch, meet, join, widen 161 | %% \item product domains, how to incorporate finer types more smoothly 162 | %% *\item how to incorporate static checks? \cite{typecheckjl} 163 | %% *\item separate compilation 164 | %% *\item function types 165 | %% \item shared memory, cilk 166 | %% \item can we implement BLAS? 167 | %% *\item incorporate autotuning? 168 | %% \end{itemize} 169 | 170 | % oscar: 171 | % - what we have now is the ``minimal julia'' 172 | % - ``easy to write code that's easy to analyze statically'' 173 | % - got non-programmer people to write easy to analyze code 174 | 175 | % mention lines of code 176 | %% How much of the past 30 years of handwritten Matlab internals can 177 | %% be autogenerated with a compiler? (A lot) 178 | %% 70kLOC julia, 34kLOC c/c++, 6kLOC scheme 179 | % but this includes a REPL, package manager 180 | 181 | % easy polymorphism. 182 | % - starts with a very simple HLL 183 | % - performs well because of underlying mechanisms, 184 | % which then unfold gradually when you want more control over performance 185 | 186 | % making everything a method, and everything glued together by types 187 | % gives certain reflective properties. 188 | 189 | 190 | \section{Project status} 191 | 192 | Not only is Julia free software, but we want to make 193 | the most of it by facilitating reading and modifying its code. 194 | Most of Julia is defined in libraries, lowering the barrier to contributing 195 | to more aspects of the system. 196 | There are currently 590 packages listed in our package management system, 197 | and the majority of them are written entirely in Julia. 198 | 199 | 200 | %over 350 contributors 201 | 202 | 203 | % something about how ``information hiding'' is anathema to science, 204 | % and coincidentally is not the focus of t.c. languages or rigorous 205 | % functional languages. 206 | 207 | -------------------------------------------------------------------------------- /contents.tex: -------------------------------------------------------------------------------- 1 | % -*- Mode:TeX -*- 2 | %% This file simply contains the commands that actually generate the table of 3 | %% contents and lists of figures and tables. You can omit any or all of 4 | %% these files by simply taking out the appropriate command. For more 5 | %% information on these files, see appendix C.3.3 of the LaTeX manual. 6 | \renewcommand{\baselinestretch}{1.4}\normalsize 7 | \tableofcontents 8 | \renewcommand{\baselinestretch}{1.5}\normalsize 9 | \newpage 10 | \listoffigures 11 | %\listofalgorithms 12 | %\newpage 13 | \listoftables 14 | \newpage 15 | -------------------------------------------------------------------------------- /cover.tex: -------------------------------------------------------------------------------- 1 | % -*-latex-*- 2 | % $Log: cover.tex,v $ 3 | % Revision 1.7 2010/04/29 11:35:46 bryt 4 | % changed department chair from Art Smith to Terry Orlando 5 | % changed default copyright flag from author to MIT, left directions for changing it back 6 | % 7 | % Revision 1.6 1999/10/21 14:49:31 boojum 8 | % changed comment referring to documentstyle 9 | % 10 | % Revision 1.5 1999/10/21 14:39:04 boojum 11 | % *** empty log message *** 12 | % 13 | % Revision 1.4 1997/04/18 17:54:10 othomas 14 | % added page numbers on abstract and cover, and made 1 abstract 15 | % page the default rather than 2. (anne hunter tells me this 16 | % is the new institute standard.) 17 | % 18 | % Revision 1.4 1997/04/18 17:54:10 othomas 19 | % added page numbers on abstract and cover, and made 1 abstract 20 | % page the default rather than 2. (anne hunter tells me this 21 | % is the new institute standard.) 22 | % 23 | % Revision 1.3 93/05/17 17:06:29 starflt 24 | % Added acknowledgements section (suggested by tompalka) 25 | % 26 | % Revision 1.2 92/04/22 13:13:13 epeisach 27 | % Fixes for 1991 course 6 requirements 28 | % Phrase "and to grant others the right to do so" has been added to 29 | % permission clause 30 | % Second copy of abstract is not counted as separate pages so numbering works 31 | % out 32 | % 33 | % Revision 1.1 92/04/22 13:08:20 epeisach 34 | \title{Abstraction in Technical Computing} 35 | 36 | \author{Jeffrey Werner Bezanson} 37 | \prevdegrees{A.B., Harvard University (2004) \\ 38 | S.M., Massachusetts Institute of Technology (2012)} 39 | \department{Department of Electrical Engineering and Computer Science} 40 | % If the thesis is for two degrees simultaneously, list them both 41 | % separated by \and like this: 42 | % \degree{Doctor of Philosophy \and Master of Science} 43 | \degree{Doctor of Philosophy} 44 | \degreemonth{June} 45 | \degreeyear{2015} 46 | \thesisdate{May 20, 2015} 47 | 48 | %% By default, the thesis will be copyrighted to MIT. If you need to copyright 49 | %% the thesis to yourself, just specify the `vi' documentclass option. If for 50 | %% some reason you want to exactly specify the copyright notice text, you can 51 | %% use the \copyrightnoticetext command. 52 | %\copyrightnoticetext{\copyright IBM, 1990. Do not open till Xmas.} 53 | 54 | % If there is more than one supervisor, use the \supervisor command 55 | % once for each. 56 | \supervisor{Alan Edelman}{Professor} 57 | 58 | % This is the department committee chairman, not the thesis committee 59 | % chairman. You should replace this with your Department's Committee 60 | % Chairman. 61 | \chairman{Leslie Kolodziejski}{Chairman, Department Committee on Graduate Students} 62 | 63 | % Make the titlepage based on the above information. If you need 64 | % something special and can't use the standard form, you can specify 65 | % the exact text of the titlepage yourself. Put it in a titlepage 66 | % environment and leave blank lines where you want vertical space. 67 | % The spaces will be adjusted to fill the entire page. The dotted 68 | % lines for the signatures are made with the \signature command. 69 | \maketitle 70 | 71 | \newpage 72 | \null 73 | 74 | % The abstractpage environment sets up everything on the page except 75 | % the text itself. The title and other header material are put at the 76 | % top of the page, and the supervisors are listed at the bottom. A 77 | % new page is begun both before and after. Of course, an abstract may 78 | % be more than one page itself. If you need more control over the 79 | % format of the page, you can use the abstract environment, which puts 80 | % the word "Abstract" at the beginning and single spaces its text. 81 | 82 | %% You can either \input (*not* \include) your abstract file, or you can put 83 | %% the text of the abstract directly between the \begin{abstractpage} and 84 | %% \end{abstractpage} commands. 85 | 86 | % First copy: start a new page, and save the page number. 87 | \newpage 88 | % Uncomment the next line if you do NOT want a page number on your 89 | % abstract and acknowledgments pages. 90 | % \pagestyle{empty} 91 | \setcounter{savepage}{\thepage} 92 | \begin{abstractpage} 93 | \input{abstract} 94 | \end{abstractpage} 95 | 96 | \newpage 97 | \null 98 | 99 | % Additional copy: start a new page, and reset the page number. This way, 100 | % the second copy of the abstract is not counted as separate pages. 101 | % Uncomment the next 6 lines if you need two copies of the abstract 102 | % page. 103 | % \setcounter{page}{\thesavepage} 104 | % \begin{abstractpage} 105 | % \input{abstract} 106 | % \end{abstractpage} 107 | 108 | \newpage 109 | 110 | \begin{singlespace} 111 | 112 | \section*{Acknowledgments} 113 | 114 | \input{acks} 115 | 116 | \end{singlespace} 117 | 118 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 119 | % -*-latex-*- 120 | -------------------------------------------------------------------------------- /doublespace.sty: -------------------------------------------------------------------------------- 1 | %------------------------------------------------------------------------------- 2 | % 3 | % LaTeX Document style option "doublespace" 4 | % -- usage: \documentstyle[...,doublespace,...]{...} 5 | % 6 | % This style option produces a double-spaced document by redefining 7 | % the LaTeX parameter \baselinestretch to 2. 8 | % 9 | % It also fixes a number of problems with standard LaTeX, as follows: 10 | % 11 | % 1. A new environment "singlespace" is provided, within which single 12 | % spacing will apply. 13 | % JFL - changed so that it works in regular text and so that vertical 14 | % space is before and after is correctly computed 15 | % 2. Double spacing is turned off within footnotes and floats (figures 16 | % and tables). 17 | % 3. Proper double spacing happens below tabular environments and in other 18 | % places where LaTeX uses a strut. 19 | % 4. Slightly more space is inserted before footnotes. 20 | % 5. JFL - fixes spacing before and after displayed math 21 | % 22 | % Note: This version sets a baselinestretch of 2. If this is too much, 23 | % put \setstretch{1.7} (or some appropriate value) before the 24 | % \begin{document} command. To print the document with single spacing 25 | % again, without removing "singlespace" environments, just put a 26 | % \setstretch{1} at the top of the document. 27 | % 28 | % PLEASE REPORT ANY BUGS 29 | % 30 | % Modified by: Jean-Francois Lamy 31 | % lamy@ai.toronto.edu 32 | % lamy@utai.uucp 33 | % 34 | % Author: Stephen Page -- sdpage@prg.oxford.ac.uk 35 | % sdpage%prg.oxford.ac.uk@cs.ucl.ac.uk 36 | % 37 | % Release date: 6 July 1986 - September 3, 1986 38 | % 39 | % Known bugs: 40 | % . It might be nice if spacing before the footnote rule (\footins) 41 | % were provided in a tidier way. 42 | % . Increasing struts may possibly cause some other obscure part of 43 | % formatting to fall over. 44 | % . \begin{singlespace}\begin{quote} produces the wrong spacing before 45 | % the quote (extra glue is inserted). 46 | % . shouldn't @setsize stretch parskip as well? 47 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 48 | 49 | %---Set up double spacing 50 | 51 | \def\baselinestretch{2} 52 | 53 | 54 | %---New command "\setstretch" (slightly more mnemonic... and easier to type) 55 | 56 | \def\setstretch#1{\renewcommand{\baselinestretch}{#1}} 57 | 58 | %---Stretch the baseline BEFORE calculating the strut size. This improves 59 | % spacing below tabular environments etc., probably... 60 | % Comments are welcomed. 61 | 62 | \def\@setsize#1#2#3#4{\@nomath#1% 63 | \let\@currsize#1\baselineskip 64 | #2\baselineskip\baselinestretch\baselineskip 65 | \parskip\baselinestretch\parskip 66 | \setbox\strutbox\hbox{\vrule height.7\baselineskip 67 | depth.3\baselineskip width\z@}% 68 | \normalbaselineskip\baselineskip#3#4} 69 | 70 | 71 | %---Increase the space between last line of text and footnote rule. 72 | % This is a very untidy way to do it! 73 | 74 | \skip\footins 20pt plus4pt minus4pt 75 | 76 | 77 | %---Reset baselinestretch within footnotes and floats. Originally stolen 78 | % from Stanford thesis style. 79 | 80 | %\def\@xfloat#1[#2]{\ifhmode \@bsphack\@floatpenalty -\@Mii\else 81 | %\@floatpenalty-\@Miii\fi\def\@captype{#1}\ifinner 82 | %\@parmoderr\@floatpenalty\z@ 83 | %\else\@next\@currbox\@freelist{\@tempcnta\csname ftype@#1\endcsname 84 | %\multiply\@tempcnta\@xxxii\advance\@tempcnta\sixt@@n 85 | %\@tfor \@tempa :=#2\do 86 | %{\if\@tempa h\advance\@tempcnta \@ne\fi 87 | %\if\@tempa t\advance\@tempcnta \tw@\fi 88 | %\if\@tempa b\advance\@tempcnta 4\relax\fi 89 | %\if\@tempa p\advance\@tempcnta 8\relax\fi 90 | %}\global\count\@currbox\@tempcnta}\@fltovf\fi 91 | %\global\setbox\@currbox\vbox\bgroup 92 | %\def\baselinestretch{1}\small\normalsize 93 | %\boxmaxdepth\z@ 94 | %\hsize\columnwidth \@parboxrestore} 95 | %\long\def\@footnotetext#1{\insert\footins{\def\baselinestretch{1}\footnotesize 96 | %\interlinepenalty\interfootnotelinepenalty 97 | %\splittopskip\footnotesep 98 | %\splitmaxdepth \dp\strutbox \floatingpenalty \@MM 99 | %\hsize\columnwidth \@parboxrestore 100 | %\edef\@currentlabel{\csname p@footnote\endcsname\@thefnmark}\@makefntext 101 | %{\rule{\z@}{\footnotesep}\ignorespaces 102 | %#1\strut}}} 103 | 104 | % Stolen from MIT. 105 | % 106 | % A single spaced quote (say) is done by surrounding singlespace with quote. 107 | % 108 | \def\singlespace{% 109 | \vskip\parskip% 110 | \vskip\baselineskip% 111 | \def\baselinestretch{1}% 112 | \ifx\@currsize\normalsize\@normalsize\else\@currsize\fi% 113 | \vskip-\parskip% 114 | \vskip-\baselineskip% 115 | } 116 | 117 | \def\endsinglespace{\par} 118 | 119 | % spacing, doublespace and onehalfspace all are meant to INCREASE the 120 | % spacing (i.e. calling onehalfspace from within doublespace will not 121 | % produce a graceful transition between spacings) 122 | % 123 | \def\spacing#1{\par% 124 | \def\baselinestretch{#1}% 125 | \ifx\@currsize\normalsize\@normalsize\else\@currsize\fi} 126 | 127 | \def\endspacing{\par% 128 | \vskip \parskip% 129 | \vskip \baselineskip% 130 | \endgroup% 131 | \vskip -\parskip% 132 | \vskip -\baselineskip% 133 | \begingroup} 134 | 135 | \def\onehalfspace{\spacing{1.5}} 136 | \let\endonehalfspace=\endspacing 137 | 138 | \def\doublespace{\spacing{2}} 139 | \let\doublespace=\endspacing 140 | 141 | % Fix up spacing before and after displayed math 142 | % (arraystretch seems to do a fine job for inside LaTeX displayed math, 143 | % since array and eqnarray seem to be affected as expected) 144 | % Changing \baselinestretch and doing a font change also works if done here, 145 | % but then you have to change @setsize to remove the call to @nomath) 146 | % 147 | \everydisplay{ 148 | \abovedisplayskip \baselinestretch\abovedisplayskip% 149 | \belowdisplayskip \abovedisplayskip% 150 | \abovedisplayshortskip \baselinestretch\abovedisplayshortskip% 151 | \belowdisplayshortskip \baselinestretch\belowdisplayshortskip} 152 | -------------------------------------------------------------------------------- /fullpage.sty: -------------------------------------------------------------------------------- 1 | % This is FULLPAGE.STY by H.Partl, Version 2 as of 15 Dec 1988. 2 | % Document Style Option to fill the paper just like Plain TeX. 3 | 4 | \typeout{Style Option FULLPAGE Version 2 as of 15 Dec 1988} 5 | 6 | \topmargin 0pt 7 | \advance \topmargin by -\headheight 8 | \advance \topmargin by -\headsep 9 | 10 | \textheight 8.9in 11 | 12 | \oddsidemargin 0pt 13 | \evensidemargin \oddsidemargin 14 | \marginparwidth 0.5in 15 | 16 | \textwidth 6.5in 17 | 18 | 19 | % For users of A4 paper: The above values are suited for american 8.5x11in 20 | % paper. If your output driver performs a conversion for A4 paper, keep 21 | % those values. If your output driver conforms to the TeX standard (1in/1in), 22 | % then you should add the following commands to center the text on A4 paper: 23 | 24 | % \advance\hoffset by -3mm % A4 is narrower. 25 | % \advance\voffset by 8mm % A4 is taller. 26 | 27 | \endinput 28 | 29 | 30 | -------------------------------------------------------------------------------- /lgrind.sty: -------------------------------------------------------------------------------- 1 | %% 2 | %% This is file `lgrind.sty', 3 | %% generated with the docstrip utility. 4 | %% 5 | %% The original source files were: 6 | %% 7 | %% lgrind.dtx (with options: `package') 8 | %% 9 | %% LGrind is used to format source code of different programming 10 | %% languages for LaTeX. 11 | %% 12 | %% LGrind is a minor adaptation of Jerry Leichter's tgrind for LaTeX, 13 | %% which was a notable improvement upon Van Jacobsen's tgrind for 14 | %% plain TeX, which was adapted from vgrind, a troff prettyprinter. 15 | %% 16 | %% Based on Van Jacobson's ``tgrindmac'', a macro package for TeX. 17 | %% Modified, 1987 by Jerry Leichter. Put '@' in all internal names. 18 | %% Modified, 1991 by George Reilly. Changed name from tgrind to lgrind. 19 | %% Modified, 1995 by Michael Piefel. Made it work with \LaTeXe. 20 | \NeedsTeXFormat{LaTeX2e}[1995/06/01] 21 | \ProvidesPackage{lgrind} 22 | [1997/01/30 v3.4 LGrind environment and supporting stuff] 23 | \newcount\lc@unt 24 | \newcount\ln@xt 25 | \newcount\LGnuminterval 26 | \LGnuminterval=10 27 | \DeclareOption{nolineno}{\LGnuminterval=50000} 28 | \DeclareOption{lineno5}{\LGnuminterval=5} 29 | \newif\ifLGleftnum 30 | \DeclareOption{leftnum}{\LGleftnumtrue} 31 | \newskip\LGindent 32 | \LGindent=1.6667\parindent 33 | \DeclareOption{noindent}{\LGindent=0pt} 34 | \newif\ifLGnorules 35 | \DeclareOption{norules}{\LGnorulestrue} 36 | \newlength{\LGsloppy} 37 | \setlength{\LGsloppy}{7.2pt} 38 | \DeclareOption{fussy}{\LGsloppy=0pt} 39 | \newcommand{\DefaultProc}{\@gobble} 40 | \newcommand{\DefaultProcCont}{\@gobble} 41 | \DeclareOption{procnames}{ 42 | \renewcommand{\DefaultProc}[1]{\renewcommand{\Procname}{#1}% 43 | \global\setbox\procbox=\hbox{\PNsize #1}} 44 | \renewcommand{\DefaultProcCont}[1]{\renewcommand\Procname{#1} 45 | \global\setbox\procbox=\hbox{\PNsize\dots #1}}} 46 | \newbox\procbox 47 | \newcommand{\Procname}{} 48 | \ProcessOptions 49 | \def\BGfont{\sffamily} 50 | \def\CMfont{\rmfamily\itshape} 51 | \def\NOfont{\sffamily} 52 | \def\KWfont{\rmfamily\bfseries} 53 | \def\STfont{\ttfamily} 54 | \def\VRfont{\rmfamily} 55 | \def\PNsize{\BGfont\small} 56 | \def\LGsize{\small} 57 | \def\LGfsize{\footnotesize} 58 | \newif\ifLGinline 59 | \newif\ifLGd@fault 60 | \def\LGbegin{\ifLGinline$\hbox\else$$\vbox\fi\bgroup\LGd@faulttrue} 61 | \def\LGend{\ifLGd@fault\egroup\ifLGinline$\else$$\fi\LGd@faultfalse\fi} 62 | \newif\ifc@mment 63 | \newif\ifstr@ng 64 | \newif\ifright@ 65 | \newbox\ls@far 66 | \newbox\tb@x 67 | \newdimen\TBw@d 68 | \newdimen\@ts 69 | {\catcode`\_=\active \gdef\@setunder{\let_=\sp@ce}} 70 | \newcommand{\lgrindheader}{} 71 | \newcommand{\lgrindfilename}{}\newcommand{\lgrindfilesize}{} 72 | \newcommand{\lgrindmodyear}{}\newcommand{\lgrindmodmonth}{} 73 | \newcommand{\lgrindmodday}{}\newcommand{\lgrindmodtime}{} 74 | \newenvironment{lgrind}[1][1]{% 75 | \def\Line##1{\L{\LB{##1}}}% 76 | \newcommand{\Head}[1]{\gdef\lgrindhead{##1}}% 77 | \newcommand{\File}[6]{\gdef\lgrindfilename{##1}\message{(LGround: ##1)}% 78 | \gdef\lgrindmodyear{##2}\gdef\lgrindmodmonth{##3}% 79 | \gdef\lgrindmodday{##4}\gdef\lgrindmodtime{##5}% 80 | \gdef\lgrindfilesize{##6}}% 81 | \let\Proc=\DefaultProc% 82 | \let\ProcCont=\DefaultProcCont% 83 | \hfuzz=\LGsloppy 84 | \def\NewPage{\filbreak\bigskip}% 85 | \ifLGinline 86 | \def\L##1{\setbox\ls@far\null{\CF\strut##1}\ignorespaces}% 87 | \else 88 | \let\r@ghtlno\relax\let\l@ftlno\relax 89 | \ifnum\LGnuminterval>\z@ 90 | \ifLGleftnum 91 | \def\l@ftlno{\ifvoid\procbox\ifnum\lc@unt>\ln@xt 92 | \global\advance\ln@xt by\LGnuminterval 93 | \llap{{\normalfont\scriptsize\the\lc@unt\quad}}\fi 94 | \else\llap{\box\procbox\quad}\fi}% 95 | \else 96 | \def\r@ghtlno{\ifvoid\procbox\ifnum\lc@unt>\ln@xt 97 | \global\advance\ln@xt by\LGnuminterval 98 | \rlap{{\normalfont\scriptsize\enspace\the\lc@unt}}\fi 99 | \else\rlap{\enspace\box\procbox}\fi}% 100 | \fi 101 | \fi 102 | \def\L##1{\@@par\setbox\ls@far=\null\strut 103 | \global\advance\lc@unt by1% 104 | \hbox to \hsize{\hskip\LGindent\l@ftlno ##1\egroup% 105 | \hfil\r@ghtlno}% 106 | \ignorespaces}% 107 | \fi 108 | \lc@unt=#1\advance\lc@unt by-1% 109 | \ln@xt=\LGnuminterval\advance\ln@xt by-1% 110 | \loop\ifnum\lc@unt>\ln@xt\advance\ln@xt by\LGnuminterval\repeat% 111 | \def\LB{\hbox\bgroup\bgroup\box\ls@far\CF\let\next=}% 112 | \def\Tab##1{\egroup\setbox\tb@x=\lastbox\TBw@d=\wd\tb@x% 113 | \advance\TBw@d by 1\@ts\ifdim\TBw@d>##1\@ts 114 | \setbox\ls@far=\hbox{\box\ls@far \box\tb@x \sp@ce}\else 115 | \setbox\ls@far=\hbox to ##1\@ts{\box\ls@far \box\tb@x \hfil}\fi\LB}% 116 | \ifLGinline\def\sp@ce{\hskip .3333em}% 117 | \else \setbox\tb@x=\hbox{\texttt{0}}% 118 | \@ts=0.8\wd\tb@x \def\sp@ce{\hskip 1\@ts}\fi 119 | \catcode`\_=\active \@setunder 120 | \def\CF{\ifc@mment\CMfont\else\ifstr@ng\STfont\fi\fi} 121 | \def\N##1{{\NOfont ##1}\global\futurelet\next\ic@r}% 122 | \def\K##1{{\KWfont ##1}\global\futurelet\next\ic@r}% 123 | \def\V##1{{\VRfont ##1}\global\futurelet\next\ic@r}% 124 | \def\ic@r{\let\@tempa\/\ifx.\next\let\@tempa\relax% 125 | \else\ifx,\next\let\@tempa\relax\fi\fi\@tempa}% 126 | \def\C{\egroup\bgroup\CMfont \global\c@mmenttrue \global\right@false}% 127 | \def\CE{\egroup\bgroup \global\c@mmentfalse}% 128 | \def\S{\egroup\bgroup\STfont \global\str@ngtrue}% 129 | \def\SE{\egroup\bgroup \global\str@ngfalse}% 130 | \def\,{\relax \ifmmode\mskip\thinmuskip \else\thinspace \fi}% 131 | \def\!{\relax \ifmmode\mskip-\thinmuskip \else\negthinspace \fi}% 132 | \def\CH##1##2##3{\relax\ifmmode ##1\relax 133 | \else\ifstr@ng ##2\relax\else$##3$\fi\fi }% 134 | \def\{{\CH\lbrace {\char'173}\lbrace }% 135 | \def\}{\CH\rbrace {\char'175}\rbrace }% 136 | \def\1{\CH///}% % / 137 | \def\2{\CH\backslash {\char'134}\backslash }% % \ 138 | \def\|{\CH|{\char'174}|}% 139 | \def\<{\CH<<<}% 140 | \def\>{\CH>>>}% 141 | \def\*{\CH***}\relax %\relax for DOCSTY 142 | \def\-{\CH---}% 143 | \def\_{\ifstr@ng {\char'137}\else 144 | \leavevmode \kern.06em \vbox{\hrule width.35em}% 145 | \ifdim\fontdimen\@ne\font=\z@ \kern.06em \fi\fi }% 146 | \def\&{\textsf{\char'046}}% 147 | \def\#{{\STfont\char'043}}% 148 | \def\%{{\char'045}}% 149 | \def\~{{\char'176}}% 150 | \def\3{\ifc@mment\ifright@ ''\global\right@false% 151 | \else``\global\right@true \fi 152 | \else{\texttt{\char'042}}\fi}% 153 | \def\4{\ifc@mment'\else {\texttt{\char'015}}\fi}% 154 | \def\5{{\texttt{\char'136}}}% 155 | \def\${{\ifmmode\slshape\else\ifdim\fontdimen\@ne\font>\z@\slshape\fi\fi 156 | \char'044}}% %No $ in \it, use \sl 157 | \parindent\z@\parskip\z@ plus 1pt\hsize\linewidth% 158 | \bgroup\BGfont 159 | } 160 | {\egroup\@@par} % end of environment lgrind 161 | \def\lgrinde{\ifLGinline\else\LGsize\fi\begin{lgrind}} 162 | \def\endlgrinde{\end{lgrind}} 163 | \def\lagrind{\@ifstar{\@slagrind}{\@lagrind}} 164 | 165 | \def\@lagrind{\@ifnextchar[{\@@lagrind}{\@@lagrind[t]}} 166 | \def\@slagrind{\@ifnextchar[{\@@slagrind}{\@@slagrind[t]}} 167 | \def\@@lagrind[#1]#2#3#4{% 168 | \begin{figure}[#1] 169 | \ifLGnorules\else\hrule\fi 170 | \vskip .5\baselineskip 171 | \begin{minipage}\columnwidth\LGsize\LGindent\z@ 172 | \begin{lgrind} 173 | \input #2\relax 174 | \end{lgrind} 175 | \end{minipage} 176 | \vskip .5\baselineskip plus .5\baselineskip 177 | \ifLGnorules\else\hrule\fi\vskip .5\baselineskip 178 | \begingroup 179 | \setbox\z@=\hbox{#4}% 180 | \ifdim\wd\z@>\z@ 181 | \caption{#3}% 182 | \label{#4}% 183 | \else 184 | \captcont{#3}% 185 | \fi 186 | \endgroup 187 | \vskip 2pt 188 | \end{figure} 189 | } 190 | \def\@@slagrind[#1]#2#3#4{% 191 | \begin{figure*}[#1] 192 | \ifLGnorules\else\hrule\fi 193 | \vskip .5\baselineskip 194 | \begin{minipage}\linewidth\LGsize\LGindent\z@ 195 | \begin{lgrind} 196 | \input #2\relax 197 | \end{lgrind} 198 | \end{minipage} 199 | \vskip .5\baselineskip plus .5\baselineskip 200 | \ifLGnorules\else\hrule\fi\vskip .5\baselineskip 201 | \begingroup 202 | \setbox\z@=\hbox{#4}% 203 | \ifdim\wd\z@>\z@ 204 | \caption{#3}% 205 | \label{#4}% 206 | \else 207 | \captcont{#3}% 208 | \fi 209 | \endgroup 210 | \vskip 2pt 211 | \end{figure*} 212 | } 213 | \def\lgrindfile#1{% 214 | \par\addvspace{0.1in} 215 | \ifLGnorules\else\hrule\fi 216 | \vskip .5\baselineskip 217 | \begingroup\LGfsize\LGindent\z@ 218 | \begin{lgrind} 219 | \input #1\relax 220 | \end{lgrind} 221 | \endgroup 222 | \vskip .5\baselineskip 223 | \ifLGnorules\else\hrule\fi 224 | \addvspace{0.1in} 225 | } 226 | \endinput 227 | %% 228 | %% End of file `lgrind.sty'. 229 | -------------------------------------------------------------------------------- /main.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/JeffBezanson/phdthesis/876be73a5aab9b034fac3eb9ea9d8f96713f786f/main.pdf -------------------------------------------------------------------------------- /main.tex: -------------------------------------------------------------------------------- 1 | % -*- Mode:TeX -*- 2 | 3 | %% The documentclass options along with the pagestyle can be used to generate 4 | %% a technical report, a draft copy, or a regular thesis. You may need to 5 | %% re-specify the pagestyle after you \include cover.tex. For more 6 | %% information, see the first few lines of mitthesis.cls. 7 | 8 | \documentclass[12pt,twoside]{mitthesis} 9 | \usepackage[top=1in, bottom=1.5in, left=1in, right=1in]{geometry} 10 | \usepackage{stmaryrd} 11 | \usepackage{amsmath} 12 | \usepackage{amsfonts} 13 | \usepackage{amsopn} 14 | \usepackage{amssymb} 15 | \usepackage{listings} 16 | \usepackage{hyperref} 17 | \usepackage{url} 18 | \usepackage[nottoc]{tocbibind} 19 | \usepackage{appendix} 20 | \usepackage{multicol} 21 | \usepackage{bussproofs} 22 | \usepackage[lighttt]{lmodern} 23 | \usepackage{pgfplots} 24 | \pgfplotsset{width=5.5in,height=3.5in} 25 | \usetikzlibrary{positioning} 26 | 27 | \pagestyle{plain} 28 | 29 | \newcommand{\code}[1]{\texttt{#1}} 30 | 31 | \lstdefinelanguage{julia}{ 32 | basicstyle=\small\ttfamily, 33 | showspaces=false, 34 | showstringspaces=false, 35 | keywordstyle={\textbf}, 36 | morekeywords={if,else,elseif,while,for,begin,end,quote,try,catch,return,local,abstract,function,stagedfunction,macro,ccall,finally,typealias,break,continue,type,global,module,using,import,export,const,let,bitstype,do,in,baremodule,importall,immutable}, 37 | escapeinside={~}{~}, 38 | morecomment=[l]{\#}, 39 | % commentstyle=\textsf, 40 | commentstyle={}, 41 | morestring=[b]", 42 | } 43 | 44 | \lstdefinestyle{ttcode}{ 45 | basicstyle=\small\ttfamily, 46 | showspaces=false, 47 | showstringspaces=false, 48 | } 49 | 50 | \begin{document} 51 | 52 | \include{cover} 53 | \include{contents} 54 | 55 | \include{chap1} 56 | \include{chap2} 57 | \include{chap3} 58 | \include{chap4} 59 | \include{chap5} 60 | \include{chap6} 61 | 62 | \begin{appendices} 63 | \include{appa} 64 | \include{appb} 65 | \end{appendices} 66 | 67 | \newpage 68 | 69 | \begin{singlespace} 70 | \bibliographystyle{acm} 71 | \bibliography{main} 72 | \end{singlespace} 73 | 74 | \end{document} 75 | -------------------------------------------------------------------------------- /mainj.tex: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/JeffBezanson/phdthesis/876be73a5aab9b034fac3eb9ea9d8f96713f786f/mainj.tex -------------------------------------------------------------------------------- /mainjp.tex: -------------------------------------------------------------------------------- 1 | 2 | %% \usepackage{amsmath} 3 | %% \usepackage{graphicx} 4 | %% \usepackage{hyperref} 5 | %% \usepackage{url} 6 | %\usepackage[colorinlistoftodos, textwidth=1.5\marginparwidth, shadow]{todonotes} 7 | 8 | \newcommand{\julia}{\text{Julia}} 9 | \newcommand{\ALGOL}{A\textsc{LGOL}} 10 | \newcommand{\python}{\text{Python}} 11 | \newcommand{\octave}{\text{Octave}} 12 | \newcommand{\scilab}{\text{Scilab}} 13 | \newcommand{\rlang}{\textsc{R}} 14 | \newcommand{\clang}{\textsc{C}} 15 | \newcommand{\fortran}{\text{Fortran}} 16 | \newcommand{\java}{\text{Java}} 17 | \newcommand{\cpp}{\text{C++}} 18 | \newcommand{\mathematica}{\text{Mathematica}} 19 | \newcommand{\code}[1]{\texttt{#1}} 20 | 21 | %\setlength{\oddsidemargin}{-.0in} 22 | %\setlength{\evensidemargin}{-.0in} 23 | %\setlength{\textwidth}{6.25 in} 24 | %\setlength{\topmargin}{-0.25in} 25 | %\setlength{\textheight}{8.25in} 26 | 27 | 28 | %% \newlength{\boxwidth} 29 | %% \setlength{\boxwidth}{\textwidth} 30 | %% \addtolength{\boxwidth}{-20 pt} 31 | %% \newcommand{\boxer}[1]{\begin{center} \fbox{\fbox{ 32 | %% \begin{minipage}{\boxwidth} #1 \end{minipage}}} \end{center}} 33 | 34 | % \renewcommand{\,}{\hspace*{1em} } 35 | 36 | % \renewcommand{\>}{\hspace*{0.1em} } 37 | %Julia stuff 38 | %--------- 39 | % \usepackage{graphicx} 40 | %\usepackage{color} 41 | %\usepackage{framed} 42 | 43 | %% \definecolor{shadecolor}{gray}{.92} 44 | %% \definecolor{incolor}{rgb}{0,0,.7} 45 | %% \definecolor{outcolor}{rgb}{.65,0,0} 46 | %% \definecolor{syntaxcolor}{rgb}{.65,0,0} 47 | %% \usepackage{verbatim} 48 | %% \newcommand{\sh}[1]{\textcolor{syntaxcolor}{#1}} 49 | 50 | %% \newcounter{jcounter} 51 | %% \newenvironment{jinput}[1][]{\ifx#1\relax\else\setcounter{jcounter}{#1}\addtocounter{jcounter}{-1}\fi\refstepcounter{jcounter}\ttfamily\hspace*{-.7in}\noindent\begin{minipage}[t]{.19\textwidth}\vskip2ex\hspace*{\fill}\textcolor{incolor}{In[\arabic{jcounter}]: }\end{minipage}\begin{minipage}[t]{.8\textwidth}\vskip-0ex\begin{shaded}}{\end{shaded}\end{minipage}\par} 52 | 53 | %% \newenvironment{joutput}[1][]{\vskip1ex plus .2ex minus .1ex\ifx#1\relax\else\setcounter{jcounter}{#1}\fi\addtocounter{jcounter}{-1}\refstepcounter{jcounter}\ttfamily\noindent\hspace*{-.5in}\begin{minipage}[t]{.19\textwidth}\vskip0ex\hspace*{\fill}\textcolor{outcolor}{Out[\arabic{jcounter}]: }\end{minipage}\begin{minipage}[t]{.8\textwidth}\vskip-0ex}{\end{minipage}\par\vskip1.5ex} 54 | 55 | %% \newcommand{\ja}{\begin{jinput}} 56 | %% \newcommand{\jb}{\end{jinput}\begin{joutput}} 57 | %% \newcommand{\jc}{\end{joutput}} 58 | 59 | %% \newcommand{\jav}{\begin{jinput}\begin{verbatim}} 60 | %% \newcommand{\jbv}{\end{verbatim}\end{jinput}\begin{joutput}\begin{verbatim}} 61 | %% \newcommand{\jcv}{\end{verbatim} \end{joutput}} 62 | 63 | %% \usepackage{fancyvrb} 64 | -------------------------------------------------------------------------------- /mitthesis.cls: -------------------------------------------------------------------------------- 1 | % $Log: mitthesis.cls,v $ 2 | % Revision 1.2 1999/10/21 14:51:33 boojum 3 | % changed references to documentstyle to documentclass in comments 4 | % 5 | % Revision 1.1 1999/10/21 14:39:31 boojum 6 | % Initial revision 7 | % 8 | %Revision 1.7 1998/04/01 20:45:34 othomas 9 | %removed offending phrase ", and to grant others the right to do so" from copyright notice. 10 | % 11 | %Revision 1.6 96/06/26 15:07:29 othomas 12 | %safety checkin. 13 | % 14 | %Revision 1.5 93/06/07 15:38:50 starflt 15 | %Altered 'vi' option copyright wording to comply with new Institute 16 | %Archives requirements and MIT lawyers. 17 | % 18 | %Revision 1.4 92/08/19 16:51:06 lwvanels 19 | %Updated Course 6 title page for new permissions. 20 | % 21 | %Revision 1.3 92/04/23 10:16:15 epeisach 22 | %Fixed comment character in rcs file 23 | % 24 | %Revision 1.2 92/04/22 13:12:02 epeisach 25 | %Fixes for 1991 course 6 requirements 26 | %Phrase "and to grant others the right to do so" has been added to 27 | %permission clause 28 | %Second copy of abstract is not counted as separate pages so numbering works 29 | %out 30 | % 31 | %Revision 1.1 90/05/04 11:45:53 lwvanels 32 | %Initial revision 33 | 34 | % 35 | % LaTeX format for theses at MIT 36 | % Based on "Specifications for Thesis Preparation" 37 | 38 | % `vi' and `upcase' options by Krishna Sethuraman - krishna@athena.mit.edu 39 | % Margins and heading types by Peter Nuth - nuth@ai.mit.edu 40 | % Title and abstract page by Stephen Gildea - gildea@erl.mit.edu 41 | % Look in this directory for example file mitthesis.doc 42 | % Also for propcover.tex - Boilerplate for PHD proposal. 43 | 44 | % To use this style - say something like: 45 | % for dull, boring thesis format: 46 | % \documentclass[12pt]{mitthesis} 47 | % \pagestyle{plain} 48 | % OR for fast drafts: 49 | % \documentclass[11pt,singlespace,draft]{mitthesis} 50 | % \pagestyle{drafthead} 51 | % OR for Tech Reports: 52 | % \documentclass[12pt,twoside]{mitthesis} 53 | % \pagestyle{headings} 54 | % OR 55 | % some other combination... 56 | % 57 | %%%% New options: 58 | % 59 | % Option `twoside': 60 | % Good for producing Tech Reports. 61 | % The default is single-sided printing, which is what M.I.T. wants on the 62 | % thesis document itself. 63 | % 64 | % Option `singlespace': 65 | % Good for drafts. 66 | % Double-spaced theses are the default. 67 | % That is what M.I.T. asks for in the formal specifications. 68 | % 69 | % Note that MIT does not REQUIRE all theses to be double-spaced anymore. 70 | % Someone in the library system said that it's OK to be single-spaced. 71 | % (Regardless of what the specs. say...) 72 | % To get singlespacing in an area - Use the 'singlespace' environment. 73 | % 74 | % Option `draft': 75 | % Puts `overfull' boxes at the end of lines that are too long. 76 | % 77 | % Pagestyle `drafthead': 78 | % Puts the date and the label ``*DRAFT*'' in the footer. 79 | % 80 | %%%%%%%%%% 81 | % 82 | %%%% Parameters to initialize for boilerplate page: 83 | % 84 | % \title{Mixed Circular Cylindrical Shells} 85 | % \author{J. Casey Salas} 86 | % \prevdegrees{B.S., University of California (1978) \\ 87 | % S.M., Massachusetts Institute of Technology (1981)} 88 | % \department{Department of Electrical Engineering and Computer Science} 89 | % \degree{Doctor of Philosophy} 90 | %% If the thesis is for two degrees simultaneously, list them both 91 | %% separated by \and like this: 92 | % \degree{Doctor of Philosophy \and Master of Science} 93 | % \degreemonth{February} 94 | % \degreeyear{1987} 95 | % \thesisdate{December 10, 1986} 96 | %% If the thesis is copyright by the Institute, leave this line out and 97 | %% the standard copyright line will be used instead. 98 | % \copyrightnotice{J. Casey Salas, 1986} 99 | %% If there is more than one supervisor, use the \supervisor command 100 | %% once for each. 101 | % \supervisor{John D. Galli}{Director, Sound Instrument Laboratory} 102 | %% This is the department committee chairman, not the thesis committee chairman 103 | % \chairman{Arthur C. Smith} 104 | % {Chairman, Departmental Committee on Graduate Students} 105 | %% Make the titlepage based on the above information. If you need 106 | %% something special and can't use the standard form, you can specify 107 | %% the exact text of the titlepage yourself. Put it in a titlepage 108 | %% environment and leave blank lines where you want vertical space. 109 | %% The spaces will be adjusted to fill the entire page. The dotted 110 | %% lines for the signatures are made with the \signature command. 111 | % 112 | %% The abstractpage environment sets up everything on the page except 113 | %% the text itself. The title and other header material are put at the 114 | %% top of the page, and the supervisors are listed at the bottom. A 115 | %% new page is begun both before and after. Of course, an abstract may 116 | %% be more than one page itself. If you need more control over the 117 | %% format of the page, you can use the abstract environment, which puts 118 | %% the word "Abstract" at the beginning and single spaces its text. 119 | % 120 | % \begin{abstractpage} 121 | % Abstract goes here. 122 | % \end{abstractpage} 123 | % 124 | %%%%%%%% Newer additions 125 | % 126 | % documentclass options - 127 | % vi For MIT course VI or VIII thesis - will copyright the thesis to 128 | % you while giving MIT permission to copy and distribute it. 129 | % upcase Will put much of the cover page in uppercase, as per the 130 | % example on page 17 of the *Specifications for Thesis 131 | % Preparation*, (revised 1989) 132 | % Also added ``All Rights Reserved'' to default copyright notice. 133 | % 134 | %%%%%%%%%%% 135 | % 136 | % Documentclass options (vi and upcase) and changes to copyright notice 137 | % Copyright (c) 1990, by Krishna Sethuraman. 138 | % 139 | % Pagestyle and header generation 140 | % Copyright (c) 1987, 1988 by Peter Nuth 141 | % 142 | % Original version 143 | % Copyright (c) 1987 by Stephen Gildea 144 | % Permission to copy all or part of this work is granted, provided 145 | % that the copies are not made or distributed for resale, and that 146 | % the copyright notice and this notice are retained. 147 | % 148 | % THIS WORK IS PROVIDED ON AN "AS IS" BASIS. THE AUTHOR PROVIDES NO 149 | % WARRANTY WHATSOEVER, EITHER EXPRESS OR IMPLIED, REGARDING THE WORK, 150 | % INCLUDING WARRANTIES WITH RESPECT TO ITS MERCHANTABILITY OR FITNESS 151 | % FOR ANY PARTICULAR PURPOSE. 152 | %%%%%%%% 153 | 154 | \NeedsTeXFormat{LaTeX2e} 155 | \ProvidesClass{mitthesis}[1999/10/20] 156 | 157 | \def\mystretch{1.5} % Double spacing hack 158 | \DeclareOption{doublespace}{} % This is default 159 | % So we do not read this style twice 160 | \DeclareOption{singlespace}{ % If he explicitly wants single spacing 161 | \typeout{Single spaced} 162 | \def\mystretch{1}} 163 | 164 | %% `vi' and `upcase' document style options. Krishna Sethuraman (1990) 165 | \newcount\vithesis 166 | \DeclareOption{vi}{\typeout{Course VI/VIII thesis style.}\advance\vithesis by1} 167 | \vithesis=0 168 | 169 | \DeclareOption{upcase}{\typeout{Uppercase cover page.} 170 | \gdef\choosecase#1{\uppercase\expandafter{#1}}} 171 | \def\choosecase#1{#1} 172 | 173 | % Thesis looks much like report 174 | \DeclareOption*{\PassOptionsToClass{\CurrentOption}{report}} 175 | \ProcessOptions 176 | \LoadClass{report} 177 | 178 | % If the user wants single spacing, set baselinestretch=1. 179 | % Read the doublespace style that we got from Rochester. 180 | 181 | \input doublespace.sty % We always read doublespacing 182 | \def\baselinestretch{\mystretch} % Double spacing hack 183 | 184 | %%%%%%% Set up margins and formatting params %%% 185 | 186 | % Margins. 187 | % Note we want 1in top margin assuming no header line, so push header 188 | % into 1in margin. 189 | % Draft mode brings the header back down. 190 | 191 | \setlength{\oddsidemargin}{0.25in} % 1.25in left margin 192 | \setlength{\evensidemargin}{0.25in} % 1.25in left margin (even pages) 193 | \setlength{\topmargin}{0.0in} % 1in top margin 194 | \setlength{\textwidth}{6.0in} % 6.0in text - 1.25in rt margin 195 | \setlength{\textheight}{9in} % Body ht for 1in margins 196 | \addtolength{\topmargin}{-\headheight} % No header, so compensate 197 | \addtolength{\topmargin}{-\headsep} % for header height and separation 198 | 199 | % The next two macros compensate page style for headers and footers 200 | % We only need them in page styles that USE headers and footers. 201 | % If we have a header, it must be 1in from top of page. 202 | \def\pulldownheader{ % Shift header down 1in from top 203 | \addtolength{\topmargin}{\headheight} 204 | \addtolength{\topmargin}{\headsep} 205 | \addtolength{\textheight}{-\headheight} 206 | \addtolength{\textheight}{-\headsep} 207 | } 208 | % If we have a footer, put it 1in up from bottom 209 | \def\pullupfooter{ % Shift footer up 210 | \addtolength{\textheight}{-\footskip} 211 | \addtolength{\textheight}{-\footheight} 212 | } 213 | 214 | %%%%%%% End of margins and formatting params %%% 215 | 216 | %%%%%%% Fix various header and footer problems %%% 217 | 218 | % Format for draft of thesis. Define our own PageStyle - 219 | % Just like headings, but has foot lines with the date and warning 220 | 221 | \if@twoside % If two-sided printing. 222 | \def\ps@drafthead{ 223 | \let\@mkboth\markboth 224 | \def\@oddfoot{\rm \today \hfil \sc **DRAFT**} 225 | \def\@evenfoot{\sc **DRAFT** \hfil \rm \today } 226 | \def\@evenhead{\rm \thepage\hfil \sl \leftmark} 227 | \def\@oddhead{\hbox{}\sl \rightmark \hfil \rm\thepage} 228 | \def\chaptermark##1{\markboth {\uppercase{\ifnum \c@secnumdepth >\m@ne 229 | \@chapapp\ \thechapter. \ \fi ##1}}{}} 230 | \def\sectionmark##1{\markright {\uppercase{\ifnum \c@secnumdepth >\z@ 231 | \thesection. \ \fi ##1}}} 232 | \pulldownheader % Bring header down from edge 233 | \pullupfooter % Bring footer up 234 | } 235 | \else % If one-sided printing. 236 | \def\ps@drafthead{ 237 | \let\@mkboth\markboth 238 | \def\@oddfoot{\rm \today \hfil \sc **DRAFT**} 239 | \def\@oddhead{\hbox{}\sl \rightmark \hfil \rm\thepage} 240 | \def\chaptermark##1{\markright {\uppercase{\ifnum \c@secnumdepth >\m@ne 241 | \@chapapp\ \thechapter. \ \fi ##1}}} 242 | \pulldownheader % Bring header down from edge 243 | \pullupfooter % Bring footer up 244 | } 245 | \fi 246 | 247 | % I redefine these formats that were defined in report.sty 248 | % Definition of 'headings' page style 249 | % Note the use of ##1 for parameter of \def\chaptermark inside the 250 | % \def\ps@headings. 251 | % 252 | 253 | \if@twoside % If two-sided printing. 254 | \def\ps@headings{\let\@mkboth\markboth 255 | \def\@oddfoot{} 256 | \def\@evenfoot{} % No feet. 257 | \def\@evenhead{\rm \thepage\hfil \sl \leftmark} % Left heading. 258 | \def\@oddhead{\hbox{}\sl \rightmark \hfil \rm\thepage} % Right heading. 259 | \def\chaptermark##1{\markboth {\uppercase{\ifnum \c@secnumdepth >\m@ne 260 | \@chapapp\ \thechapter. \ \fi ##1}}{}} 261 | \def\sectionmark##1{\markright {\uppercase{\ifnum \c@secnumdepth >\z@ 262 | \thesection. \ \fi ##1}}} 263 | \pulldownheader % Bring header down from edge 264 | } 265 | \else % If one-sided printing. 266 | \def\ps@headings{\let\@mkboth\markboth 267 | \def\@oddfoot{} 268 | \def\@evenfoot{} % No feet. 269 | \def\@oddhead{\hbox {}\sl \rightmark \hfil \rm\thepage} % Heading. 270 | \def\chaptermark##1{\markright {\uppercase{\ifnum \c@secnumdepth >\m@ne 271 | \@chapapp\ \thechapter. \ \fi ##1}}} 272 | \pulldownheader % Bring header down from edge 273 | } 274 | \fi 275 | 276 | % Redefinition of 'myheadings' page style. 277 | % 278 | \def\ps@myheadings{\let\@mkboth\@gobbletwo 279 | \def\@oddfoot{} 280 | \def\@evenfoot{} 281 | \def\sectionmark##1{} 282 | \def\subsectionmark##1{} 283 | \def\@evenhead{\rm \thepage\hfil\sl\leftmark\hbox {}} % 284 | \def\@oddhead{\hbox{}\sl\rightmark \hfil \rm\thepage} % 285 | \pulldownheader % Bring header down from edge 286 | } 287 | 288 | % Redefine '/chapter' to always start on an odd page. 289 | % Should make no difference in singleside mode. 290 | % 291 | \def\chapter{\cleardoublepage % Starts new page. 292 | \thispagestyle{plain} % Page style of chapter page is 'plain' 293 | \global\@topnum\z@ % Prevents figures from going at top of page. 294 | \@afterindentfalse % Suppresses indent in first paragraph. Change 295 | \secdef\@chapter\@schapter} % to \@afterindenttrue to have indent. 296 | 297 | % If using the report style, use - instead of . in the figure number. 298 | \@ifundefined{thechapter}{}{\def\thefigure{\thechapter-\arabic{figure}}} 299 | 300 | 301 | %%%%%%%%% End of Style parameters %%%% 302 | 303 | % Here's Gildea's Boilerplate Stuff. 304 | % Copyright (c) 1987 by Stephen Gildea 305 | % Permission to copy all or part of this work is granted, provided 306 | % that the copies are not made or distributed for resale, and that 307 | % the copyright notice and this notice are retained. 308 | 309 | %% Define all the pieces that go on the title page and the abstract. 310 | 311 | % \title and \author already exist 312 | 313 | \def\prevdegrees#1{\gdef\@prevdegrees{#1}} 314 | \def\@prevdegrees{} 315 | 316 | \def\department#1{\gdef\@department{#1}} 317 | 318 | % If you are getting two degrees, use \and between the names. 319 | \def\degree#1{\setbox0\hbox{#1} %for side effect of setting \@degreeword 320 | \gdef\@degree{#1}} 321 | 322 | % \and is used inside the \degree argument to separate two degrees 323 | \def\and{\gdef\@degreeword{degrees} \par and \par} 324 | \def\@degreeword{degree} 325 | 326 | % The copyright notice stuff is a tremendous mess. 327 | % 328 | % \@copyrightnotice is used by \maketitle to actually put text on the 329 | % page; it defaults to ``Copyright MIT 19xx. All rights reserved.'' 330 | % \copyrightnoticetext takes an argument and defined \@copyrightnotice 331 | % to that argument. \copyrightnotice takes an argument, and calls 332 | % \copyrightnoticetext with that argument, preceeded by a copyright 333 | % symbol and followed by ``All rights reserved.'' and the standard 334 | % permission notice. 335 | % 336 | % If you use the 'vi' option, \copyrightnoticetext is used to set the 337 | % copyright to ``(C) Your Name, Current Year in Roman Numerals.'' 338 | % followed by the permission notice. 339 | 340 | % If there is no \copyrightnotice command, it is asssumed that MIT 341 | % holds the copyright. This commands adds the copyright symbol to the 342 | % beginning, and puts the standard permission notice below. 343 | %% ``All rights reserved'' added. Krishna Sethuraman (1990) 344 | \def\copyrightnotice#1{\copyrightnoticetext{\copyright\ #1. All rights 345 | reserved.\par\permission}} 346 | 347 | % Occacionally you will need to exactly specify the text of the 348 | % copyright notice. The \copyrightnoticetext command is then useful. 349 | \long\def\copyrightnoticetext#1{\gdef\@copyrightnotice{#1}} 350 | \def\@copyrightnotice{\copyright\ \Mit\ \@degreeyear. All rights reserved.} 351 | 352 | %% `vi' documentclass option: Specifying this option automatically 353 | %% copyrights the thesis to the author and gives MIT permission to copy and 354 | %% distribute the document. If you want, you can still specify 355 | %% \copyrightnotice{stuff} to copyright to someone else, or 356 | %% \copyrightnoticetext{stuff} to specify the exact text of the copyright 357 | %% notice. 358 | \ifodd\vithesis \copyrightnoticetext{\copyright\ \@author, 359 | \uppercase\expandafter{\romannumeral\@degreeyear}. All rights reserved.\par\permission} 360 | %% or just 361 | %%\@degreeyear}} 362 | \typeout{Copyright given to author, 363 | permission to copy/distribute given to MIT.} 364 | \else \typeout{Thesis document copyright MIT unless otherwise (manually) specified} 365 | \fi 366 | 367 | \def\thesisdate#1{\gdef\@thesisdate{#1}} 368 | 369 | % typically just a month and year 370 | \def\degreemonth#1{\gdef\@degreemonth{#1}} 371 | \def\degreeyear#1{\gdef\@degreeyear{#1}} 372 | 373 | % Usage: \supervisor{name}{title} 374 | % \chairman{name}{title} 375 | 376 | % since there can be more than one supervisor, 377 | % we build the appropriate boxes for the titlepage and 378 | % the abstractpage as the user makes multiple calls 379 | % to \supervisor 380 | \newbox\@titlesupervisor \newbox\@abstractsupervisor 381 | 382 | \def\supervisor#1#2{\setbox\@titlesupervisor\vbox 383 | {\unvbox\@titlesupervisor \vskip 10pt% plus 1fil minus 1fil 384 | \def\baselinestretch{1}\large 385 | \signature{Certified by}{#1 \\ #2 \\ Thesis Supervisor}} 386 | \setbox\@abstractsupervisor\vbox{\unvbox\@abstractsupervisor 387 | \vskip\baselineskip \def\baselinestretch{1}\@normalsize 388 | \par\noindent Thesis Supervisor: #1 \\ Title: #2}} 389 | 390 | % department chairman, not thesis committee chairman 391 | \def\chairman#1#2{\gdef\@chairmanname{#1}\gdef\@chairmantitle{#2}} 392 | 393 | %% `upcase' documentclass option: \choosecase is defined either as a dummy or 394 | %% a macro to change the (expanded) argument to uppercase. 395 | \def\maketitle{\begin{titlepage} 396 | \large 397 | {\def\baselinestretch{1.2}\Large\bf \choosecase{\@title} \par} 398 | by\par 399 | {\Large \choosecase{\@author}} 400 | \par 401 | \@prevdegrees 402 | \par 403 | \choosecase{Submitted to the} \choosecase{\@department} \\ 404 | \choosecase{in partial fulfillment of the requirements for the} 405 | \choosecase{\@degreeword} 406 | \choosecase{of} 407 | \par 408 | \choosecase{\@degree} 409 | \par 410 | at the 411 | \par\MIT\par 412 | \@degreemonth\ \@degreeyear 413 | \par 414 | \@copyrightnotice 415 | \par 416 | \vskip 3\baselineskip 417 | \signature{Author}{\@department \\ \@thesisdate} 418 | \par 419 | \vfill 420 | \unvbox\@titlesupervisor 421 | \par 422 | \vfill 423 | \signature{Accepted by}{\@chairmanname \\ \@chairmantitle} 424 | \vfill 425 | \end{titlepage}} 426 | 427 | % this environment should probably be called abstract, 428 | % but we want people to also be able to get at the more 429 | % basic abstract environment 430 | \def\abstractpage{\newpage 431 | \begin{center}{\large{\bf \@title} \\ 432 | by \\ 433 | \@author \\[\baselineskip]} 434 | \par 435 | \def\baselinestretch{1}\@normalsize 436 | Submitted to the \@department \\ 437 | on \@thesisdate, in partial fulfillment of the \\ 438 | requirements for the \@degreeword\ of \\ 439 | \@degree 440 | \end{center} 441 | \par 442 | \begin{abstract}} 443 | 444 | %% Changed from \unvbox to \unvcopy for use with multiple copies of abstract 445 | %% page. 446 | %% Krishna Sethuraman (1990) 447 | \def\endabstractpage{\end{abstract}\noindent 448 | \unvcopy\@abstractsupervisor \newpage} 449 | 450 | %% This counter is used to save the page number for the second copy of 451 | %% the abstract. 452 | \newcounter{savepage} 453 | 454 | % You can use the titlepage environment to do it all yourself if you 455 | % don't want to use \maketitle. If the titlepage environment, the 456 | % paragraph skip is infinitely stretchable, so if you leave a blank line 457 | % between lines that you want space between, the space will stretch so 458 | % that the title page fills up the entire page. 459 | \def\titlepage{\newpage\centering 460 | \thispagestyle{empty} 461 | \parindent 0pt \parskip 10pt plus 1fil minus 1fil 462 | \def\baselinestretch{1}\@normalsize\vbox to \vsize\bgroup\vbox to 9in\bgroup} 463 | % The \kern0pt pushes any depth into the height. Thanks to Richard Stone. 464 | \def\endtitlepage{\par\kern 0pt\egroup\vss\egroup\newpage} 465 | 466 | \def\MIT{MASSACHUSETTS INSTITUTE OF TECHNOLOGY} 467 | \def\Mit{Massachusetts Institute of Technology} 468 | 469 | \def\permission{\par\noindent{\centering 470 | The author hereby grants to MIT permission to reproduce and 471 | distribute publicly paper and electronic copies of this thesis 472 | document in whole or in part.}\par} 473 | 474 | \def\signature#1#2{\par\noindent#1\dotfill\null\\* 475 | {\raggedleft #2\par}} 476 | 477 | \def\abstract{\subsection*{Abstract}\small\def\baselinestretch{1}\@normalsize} 478 | \def\endabstract{\par} 479 | 480 | -------------------------------------------------------------------------------- /notes: -------------------------------------------------------------------------------- 1 | common themes: 2 | 3 | goal: 4 | 5 | common framework powerful enough to encompass both TC and general-purpose 6 | programming 7 | "finding the right abstraction level": prescribing just enough, but not 8 | so much that programmers feel limited 9 | 10 | there is such a thing as "more" abstraction, but what matters is the 11 | "right" abstraction. 12 | 13 | the right abstraction is one where you can specify everything that's 14 | important to you, but don't have to specify anything else. 15 | 16 | the right abstraction does not constrain you from doing 17 | mathematically valid things. 18 | 19 | the right abstraction empowers the user 20 | 21 | it's easy to have misconceptions about what the right level is. 22 | it would be easy for a computer scientist to conclude, for example, 23 | that scientific users just needed BLAS, or the most popular 200 24 | matlab functions. 25 | 26 | computer scientists are good at adding more abstraction, but the 27 | difference here is we try to make sure the more powerful abstractions 28 | can actually do what people want, given the existing popular systems. 29 | 30 | 31 | 32 | 33 | theme: code generation 34 | 35 | show 36 | - you need some ability to prove things about types, not just JIT with speculative opts 37 | - our design makes it easier to get performance, for both the user and language 38 | implementer 39 | 40 | 41 | mechanism: 42 | 43 | TC is very light on theory and could benefit from more theory 44 | certain aspects of this theory can be used to redesign TC languages in 45 | a better way, as opposed to the ad-hoc things that have come before 46 | 47 | 48 | review chapter: 49 | 50 | all the things that have been tried, what we have learned, and out of 51 | that we identify a convex set of the good stuff 52 | 53 | the point is not to prove "our way is fastest" of all possible ways 54 | our thesis statement is not an empirical finding 55 | 56 | often too much empiricism in computer systems is not useful; 57 | there is measurement bias. this goes back to presumptions about what 58 | the user wants. 59 | 60 | counterexample: lots of compiler papers published about how to 61 | optimize matlab programs. a fine thing to do, but i want to try 62 | a different approach. our approach to the problem is highly 63 | under-explored. 64 | 65 | 66 | 67 | 3 problems with speeding up existing languages: 68 | 69 | - what to specialize on, what to dispatch on? 70 | e.g. should something be specialized on a constant integer value or just Int? 71 | 72 | - during analysis types just get bigger; no types in contravariant position to 73 | narrow them 74 | 75 | - ultimately (and somewhat ironically) you end up with different mechanisms 76 | for specialization and selection, just like in C++. the compiler might 77 | end up using multiple dispatch, but you can't have it. not optimal. 78 | 79 | on the other end of the spectrum, you might be using very powerful dispatch 80 | (e.g. predicate dispatch, pattern matching) that's not very useful to the 81 | compiler. 82 | 83 | what's missing is descriptive information. it might be added later, e.g. 84 | a system of annotations to augment a partial evaluator. but annotations 85 | are inert; they don't do anything but improve performance. 86 | the information is also just nice to have. you can talk about it, refer to it. 87 | 88 | maybe measure: % of methods applicable per call site on average, based on 89 | static information. 90 | functions: 1/1 91 | class-based OO: n/n, where n=# subclasses and is fairly small 92 | overloading: 1/n 93 | julia: (small number)/(large number) 94 | 95 | solve the equation 96 | 97 | dispatch power = program analysis power 98 | 99 | the answer is semantic subtyping. 100 | 101 | this finds local optima in the design space. 102 | more powerful dispatch => ok, but compiler can help less 103 | less " => the compiler could help, you're leaving power on the table 104 | -------------------------------------------------------------------------------- /outline.tex: -------------------------------------------------------------------------------- 1 | \documentclass[12pt]{article} 2 | 3 | \title{Abstraction in Technical Computing} 4 | \author{Jeff Bezanson} 5 | 6 | \usepackage{outlines} 7 | \begin{document} 8 | 9 | \maketitle 10 | 11 | \section{Outline} 12 | 13 | \begin{outline}[enumerate] 14 | \1 Introduction 15 | \2 What is technical computing? 16 | \3 In terms of design priorities 17 | \2 Description of our solution 18 | \2 Contributions 19 | \1 Problems in technical computing 20 | % motivations from the problem domain side 21 | \2 The current software stack 22 | \2 Current dynamic language designs 23 | \2 Uses of dynamic typing 24 | \2 Bad tradeoffs in current designs 25 | \2 Social phenomena 26 | \1 Available technology 27 | % motivations from the technology side; what's available and under-used 28 | \2 Language design space 29 | \3 Something about the priorities from chapter 1 30 | \2 Dynamic dispatch 31 | \2 Multiple dispatch 32 | \3 Symbolic programming 33 | \2 Domain theory 34 | \2 Dynamic type inference 35 | \1 The Julia approach 36 | \2 Language description 37 | \3 Type system 38 | \3 Data model 39 | \3 Dispatch mechanism 40 | \2 Performance model 41 | \3 Type inference 42 | \3 Specialization 43 | \2 Explication through elimination 44 | \3 Conversion and other basic operations 45 | \3 Numeric types and embeddings 46 | \3 Multidimensional array indexing 47 | \3 Array views 48 | \3 Units 49 | \1 Case Studies 50 | \2 Numerical linear algebra 51 | \2 JUMP 52 | \2 (possibly Grid.jl and other packages) 53 | \1 Conclusion 54 | \end{outline} 55 | 56 | \end{document} 57 | -------------------------------------------------------------------------------- /outlines.sty: -------------------------------------------------------------------------------- 1 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 2 | % outlines.sty - Provides an "outline" environment for mixed-level 3 | % outline lists 4 | % 5 | % Charles Pecheur, UCL, 2005 -- 2012 6 | % charles.pecheur@uclouvain.be 7 | % 8 | % Note: this package has no connection with outline.sty or outliner.sty, 9 | % that are available on CTAN 10 | % 11 | % This work may be distributed and/or modified under the 12 | % conditions of the LaTeX Project Public License, either version 1.3 13 | % of this license or (at your option) any later version. 14 | % The latest version of this license is in 15 | % http://www.latex-project.org/lppl.txt 16 | % and version 1.3 or later is part of all distributions of LaTeX 17 | % version 2005/12/01 or later. 18 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 19 | % Usage: 20 | % 21 | % \usepackage{outlines} 22 | % 23 | % \begin{outline}[] 24 | % \1 25 | % \1[