A LaTeX wrapper for homework

April 1st, 2009

Apropos of nothing… here are two examples of empty LaTeX files suitable for everyday use (e.g. homework). These templates don’t necessarily conform to any particular standard, but I think they are reasonable.

\documentclass{article}
\usepackage{amsmath, amsthm, amssymb}
\usepackage{listings}
\usepackage{graphicx}
\usepackage{float}
\usepackage{enumerate}
\usepackage{fancyhdr}
\usepackage[left=0.75in, top=1in, right=0.75in, bottom=1in]{geometry}
\pagestyle{plain}
\begin{document}
    \rhead{Student Name\\School 101: Homework 1}
    \thispagestyle{fancy}
 
    % The list environment is just to get some vertical spacing
    \list{} \item \endlist
 
    % Let the homework begin!
    \section*{Question 1}
    \subsection*{Part (a)}
    Yes
    \subsection*{Part (b)}
    No
 
    \section*{Question 2}
    Maybe
\end{document}

Looks like this,

A variation with a simpler header,

\documentclass{article}
\usepackage{amsmath, amsthm, amssymb}
\usepackage{listings}
\usepackage{graphicx}
\usepackage{float}
\usepackage[left=1in, top=1in, right=1in, bottom=1in]{geometry}
\pagestyle{plain}
\newtheorem{theorem}{Theorem}%[section]
 
\begin{document}
    \begin{flushright}
    Student Name\\School 101
    \end{flushright}
 
    \section*{Exercise 42}
    Eureka!
 
    \begin{theorem}
        \textit{(A useful equivalence)}\\
        $P = NP$
    \end{theorem}
    \begin{proof}
        By inspection.
    \end{proof}
\end{document}

looks like this,

Enjoy!

Anthony Software

Scheming in Units

March 31st, 2009

After working with modules in a language like Standard ML, modular abstraction in other programming languages can feel somewhat primitive. One sometimes wishes to abstract an inter-module dependency, or, put another way, parameterize a module by the implementation of an interface. In object-oriented terms, this is a functional analogy of programming to an interface. To this end, PLT Scheme provides a mechanism called Units. Unfortunately, I found working through the Guide and Reference (standard documentation) rather hard going as usage is somewhat complicated by the availability of syntax-directed static analysis in some situations but not others. What I really missed in the documentation was a simple, generic example of working with different implementations of one signature. What follows is an example program that demonstrates several variations of just that technique with PLT Scheme 4.1.5. This is by no means a replacement for the Guide or Reference, but instead a supplementary example. One additional note: I am deliberately using several variations of the syntax for working with Units in order to provide examples of a few different styles.

The program we are writing is one that asks the user for his or her name, and then displays a greeting. However, the interface logic doesn’t specify the implementation for either of those actions. In this toy example, the idea is to provide implementations in different human languages. Note that the entire implementation is abstract, not just the string data. So, for example, the action of asking for a name could involve very different dialogues in different implementations (e.g. one question, or a series of questions warming up to asking for a name), or even a network transport layer for interacting with a remote user. The key feature is that the interface logic is entirely parameterized by the two actions I am calling ask-for-name and greet.

Let’s make that parameterization concrete with the file service-sig.ss

;;; The service we are abstracting over is one that provides functions for 
;;; basic user interaction.
#lang scheme
 
(provide service^)
 
(define-signature service^
  (ask-for-name
   greet))

With that signature defined, we can define our user interaction logic. Here is the file interaction.ss.

;;; The interaction logic is dependent on a service for directly interfacing
;;; with the user. In this example, the functions ask-for-name and greet will
;;; be supplied by some unit implementing the service^ signature.
#lang scheme
 
(require "service-sig.ss")
 
(provide user-interface^ interaction@)
 
(define-signature user-interface^
  (prompt-user))
 
(define-unit interaction@
  (import service^)
  (export user-interface^)
  (define (prompt-user)
    (let ((name (ask-for-name)))
      (greet name))))

We’re going to need an implementation of our “service,” so let’s start with an English language version, service-impl1.ss

;;; An English language implementation of the service^ signature.
#lang scheme/unit
 
(require "service-sig.ss")
 
(import)
(export service^)
 
(define (ask-for-name) (printf "What is your name? ") (read-line))
(define (greet name) (printf "Well, hello there, ~a!~n" name))

That’s a lot of foundational work; let’s see how it comes together before going any further. The first version of our program, service-program1.ss

;;; Basic usage of the interaction unit. We supply interaction@ with an 
;;; implemenation of the service^ signature so that we can use it.
#lang scheme
 
(require "service-impl1.ss")
(require "service-impl2.ss")
(require "interaction.ss")
 
;; If we don't want programatic linking, then we can really lean on inference.
;; Change service-impl1@ to service-impl2@ for a different language.
(define-compound-unit/infer my-program
  (import)
  (export user-interface^)
  (link service-impl1@ interaction@)) 
 
;; Brings an implementation of the user-interface^ signature into scope.
(define-values/invoke-unit/infer my-program)
 
;; Kick off the interactive program
(prompt-user)

I’ve snuck in another implementation of our service^ signature. Here is the Spanish language version, service-impl2.ss,

;;; An Spanish language implementation of the service^ signature.
#lang scheme/unit
 
(require "service-sig.ss")
 
(import)
(export service^)
 
(define (ask-for-name) (printf "¿Cómo te llamas? ") (read-line))
(define (greet name) (printf "¡Bueno! ¿Cómo estás, ~a?~n" name))

One can play around with service-program1.ss as indicated in the comments. We have now achieved our goal of writing our program in such a way that we do not need to touch the interaction logic in order to supply different implementations of our service^ signature.

But Units can be taken further! Units are first class in PLT Scheme, so we can work with them at runtime. The requirement that we modify the source of service-program1.ss to change language front-ends feels a bit clumsy, so let’s write a program that will select which implementation to use for itself, service-program2.ss

;;; Units are first class in PLT Scheme, so we can programatically control 
;;; how they are linked together. In this variation, we bind an identifier 
;;; to a particular Unit depending on the user's choice of language. We 
;;; then link the interaction Unit with that new binding in order to 
;;; execute our program.
#lang scheme
 
(require "service-impl1.ss")
(require "service-impl2.ss")
(require "interaction.ss")
(require "service-sig.ss")
 
(printf "Choose your language: (1) English or (2) for Spanish")
(define language (if (regexp-match #px"2" (read-line))
                     'spanish
                     'english))
 
;; If we are willing to bind a temporary at the top-level, then we can 
;; use a define-unit form which will let us take advantage of /infer 
;; forms when using the unit. 
(define-unit-binding impl@ 
  (cond 
    ((eq? language 'english) service-impl1@)
    ((eq? language 'spanish) service-impl2@))
  (import)
  (export service^))
 
(define-compound-unit/infer my-program
  (import)
  (export user-interface^)
  (link impl@ interaction@))
 
;; Brings an implementation of the user-interface^ signature into scope.
(define-values/invoke-unit/infer my-program)
 
;; Kick off the interactive program
(prompt-user)

For one final variation, the top-level binding of impl@ bothers me a bit since it is purely a detail of my-program’s implementation. In service-program3.ss, we move impl@ into my-program’s definition.

;;; We can achieve programatic linking without binding a new identifier at the 
;;; top-level, but this strategy reduces the degree to which the Unit 
;;; system is able to infer imports and exports.
#lang scheme
 
(require "service-impl1.ss")
(require "service-impl2.ss")
(require "interaction.ss")
(require "service-sig.ss")
 
(printf "Choose your language: (1) English or (2) for Spanish")
(define language (if (regexp-match #px"2" (read-line))
                     'spanish
                     'english))
 
;; An example of using first class units. We have to make imports
;; and exports much more explicit since we are not using a top-level 
;; form for binding impl@, our temporary unit.
(define my-program
  (let ((impl@ (cond
                 ((eq? language 'english) service-impl1@)
                 ((eq? language 'spanish) service-impl2@))))
    (compound-unit
     (import)
     (export UI)
     (link (((UI : user-interface^)) interaction@ Lang)
           (((Lang : service^)) impl@)))))
 
;; Brings an implementation of the user-interface^ signature into scope.
(define-values/invoke-unit my-program (import) (export user-interface^))
 
;; Kick off the interactive program
(prompt-user)

All the source files may be found in this archive.

Anthony Programming, Scheme , ,

Octave + Image package + Mac OS X

November 14th, 2008
Comments Off

A quick public service note for anyone else trying to install the Image package (1.0.8 was the version I downloaded) with Octave (3.0.3 was the version I had) installed as Octave.app from the Octave Forge page.

I had ImageMagick 6.4.1 installed via fink on OS 10.4.11, but installing the Octave Image package was failing on

mkoctfile __magick_read__.cc

Looking in image-1.0.8/src/Makefile, there is the line

$(MKOCTFILE) $< `Magick++-config --cppflags` `Magick++-config --ldflags`

which, it turns out, needed to be

$(MKOCTFILE) $< `Magick++-config --cppflags` `Magick++-config --ldflags` `Magick++-config --libs`

for me.

Since it took me several hours to sort this all out, I’m putting it here for anyone else having trouble getting the Image package installation to link with ImageMagick.

Anthony Octave, Programming, Software

Behind Closed Doors

December 31st, 2007
Comments Off

Nick Carr suggests some reading, including a provocative post from Jaron Lanier. To extend the link chain just once more, Jaron’s post was made as somewhat of a response to an article by Freeman Dyson. Phew.

Lanier’s point is that work in private can produce good things, or, more pointedly, better things than more public, open-source methodologies. My initial reaction to this was not exactly one of surprise.

Jaron’s portrayal of open-source as being eminently capable of producing polished clones of existing artefacts, while struggling to produce large-scale paradigm shifts makes a lot of sense. Of course, one has to couch all these claims and descriptions in some meliorating language. Namely, even if you, unfairly, view Linux as a purely derivative product, its continued development, making it a better and better product, does change the operating system game in terms of redefining what a potential customer expects from a product, and what that customer is willing to pay for. However, it is quite a bit harder to make the argument that Linux, in and of itself, represents a bold new direction for operating system design.

Importantly, one does not need to categorically decry either open- or closed-source development to consider Lanier’s submission. What seems clear is that the act of copying an existing artefact has the significant advantage of inherently providing a shared goal for all contributors. There is a platonic truth at the core of the effort captured in the object being copied itself. Unfortunately, the development of something substantially different from what has come before must instead rely on much more mundane forms of communication, and this is where closed-source development can have an advantage.

Once an artefact has been created, it may speak for itself. But until that time, the responsibility for communicating that artefact’s nature lies in the, effectively, side-band communication capabilities of its designers. The development process itself may in fact be viewed as the attempt to communicate this new idea. Unfortunately, without tangible evidence at hand, most people are unable to sufficiently convince others of the worthiness of one particular goal over another such that potential supporters are willing to set aside their own misgivings over particular design choices. A silly analogy is the fabrication of a chair. If you and I are to copy an existing chair, then who am I to disagree with the plan that we give our chair four legs? But if we are instead tasked with inventing a new mechanism for supporting the human form, then who are you to tell me that we must give our device four legs?

We are able to resolve, for better or for worse, the problems engendered by our own communication shortcomings by barter: I offer you some amount of money to follow my design. That way, a design that I couldn’t possibly implement on my own is brought into the world. Of course, closed-source approaches fail at least as often as they succeed, for hidden within the simple-to-express notion of, “I’ll pay you to follow my plan,” is the necessity that the contributor bring his or her own ingenuity to bear in figuring out how best to implement the given plan, or even improve it with the designer’s consent. We don’t want smart workers stupidly following orders, but we also don’t want too many chefs in the kitchen. No, there is still a place in the world for the cathedral and the bazaar. Neither can accomplish all that the other is capable of.

So, what motivated Lanier’s potential-flame-bait-yet-simultaneously-easily-defensible article? I can’t say for sure, but I think a lot of it stems from a single phrase in Dyson’s article describing the detrimental effect of speciation on Darwinian evolution: “It probably slowed down the pace of evolution considerably.” Delivered in such an off-hand manner, this statement doesn’t invite much scrutiny, but I think that this is where the disagreement begins. The comparisons to technology development are no stretch at all. The question is, does providing momentary succor for a single voice in the chorus facilitate the creation of something new, something better? Researchers do not scatter their best thoughts across peer reviews, they must instead cultivate some ideas in a controlled environment — asking for input from select others, working through the details themselves, maybe getting a post doc. to run some experiments — and present the seeds of the idea as a cohesive whole that has grown to something substantial enough for others to evaluate. This closed development is how complex communication is achieved, and while it may slow down diversification of ideas, or genetics depending on which branch of the discussion you find more compelling, it strongly supports the effort to strike out from today’s local minimum.

Anthony Technology

Linux’s Mainstream Appeal

November 14th, 2007
Comments Off

Some comments on an Ars review of the Eee PC note some surprise that Linux’s spread into mainstream consumer electronics is happening care of the low end of the hardware spectrum, as opposed to the high end where most desktop PC Linux fans feel it really shines.

What’s really happening is that the cost of software is being made more and more visible the cheaper the hardware gets. When you bought a $2,000 PC ten years ago, the fact that you paid another $100-200 for Windows wasn’t such a huge factor in most people’s minds. But if the cost of the OS doubles the cost of the purchase, well, that’s something people tend to notice. Note that this says nothing about the value of software in general approaching zero, or anything like that. Instead, it’s making a decision that was viewed as abstract to the point of absurdity by many, into something with real weight: how much is Windows worth to me? Consumers must ask themselves this question when considering any other piece of software, but the OS is both essential to the use of the computer, and it has been seen as a free throw-in from whoever sold the computer. Now that the OS can no longer be viewed as a freeby, historically unquantified benefits of Windows such as superior device support and user friendliness are being quantified, and a price tag is finally, truly being put on them.

So Linux’s advantages may now be nearing full operational status: you can go back and forth about device support and ease of use, but the Linux side will always have price as a kicker. A kicker that, until hardware prices dropped below a certain threshold (apparently $500 or so), wasn’t worth much, but is now worth a fortune.

Anthony Linux, Microsoft