Advanced

Mathematics

(define (LR stack states-stack read-input unread-input output)
  (if (empty? unread-input) ((λ (z) (if (boolean? z) (err (length read-input)) (reverse (cons (car z) output)))) (from-start stack))
      (match (hash-ref trans-table (cons (car states-stack) (car unread-input)) 0)
        [0 (err (length read-input))]
        [(cons 'shift n) (LR (cons (car unread-input) stack) (cons n states-stack) (getread (car unread-input) read-input) (cdr unread-input) output)]
        [(cons 'reduce n) (define rul (vector-ref rules n))
                          (define len (length (rule-RHS rul)))
                          (LR (drop stack len) (drop states-stack len) read-input (cons (rule-LHS rul) unread-input) (cons rul output))])))
(define (finalize-token state l)
  (cond
    [(symbol=? state 'ID) (make-token (get-state (string->symbol (list->string l))) (list->string l))]
    [(or (symbol=? state 'ZERO) (symbol=? state 'NUM))
     (if (< (string->number (list->string l)) (arithmetic-shift 1 31)) (make-token 'NUM (list->string l)) (err))]
    [else (make-token state (list->string l))]))

If you do know that 'here is one hand', we'll grant you all the rest.

When one says that such and such a proposition can't be proved, of course that does not mean that it can't be derived from other propositions; any proposition can be derived from other ones. But they may be no more certain than it is itself.

-Ludwig Wittgenstein, On Certainty

Welcome to the course website (under construction) for my Summer II 2020 course!

The two central themes of this course are:
i) We, and all with which we are concerned, will be vanquished by the eroding tides of time.
ii) Logic won't help one be a happier person.

Along the way, we will study the notion of proof, the foundations of mathematics, the theory of programming languages, and formal logic. We'll learn about these topics by doing: writing proofs, writing programs, writing program readable proofs, writing programs to read proofs, living, loving, and suffering.

This course is an introduction to mathematics and computer science, and will ideally serve as a foundation for further studies in both subjects. Towards this goal, our approach will be one of descent. We will start with an intuitively presented example, conveyed in words that ring with an echo of systematic reasoning. Then, taking this as our point of departure, we will dig further and deeper, with the morbid fascination of a dissection, cutting away in an effort to discover what is meant by mathematics.

Matthias Felleisen writes that most first programming courses are run as follows:
You show the kids how to print "hello world" and you show them how to read a line or a number from a file; you declare some variables and arrays; you write some loops, while or for preferably; you package things up into procedures and methods; and if you want to be fancy, you can always modularize your program with classes. And that’s all there is to it.

Is this what is necessarily meant by learning by doing, or problem driven courses?
In some sense, in a typical accelerated introductions to mathematics course, one does not study what it means to write a proof; a standard for proofs is established (a good proof is one accepted in grading, just as a good program is one that passes test cases and style inspections), and students are provided a wide array of examples, typically in number theory, for the honing of this art.
Herein, a point is to be made: mathematics, as with most other arts, is not a spectator sport, and is always best done by yourself reasoning through arguments and through solving problems. However, this lies entirely orthogonal to whether or not its principles ought to be given tacitly - slowly diffusing into one's mind by pattern matching given arguments - or whether the very discovery of its principles ought to be taken as the guiding goal.

With hope, we can steer this away from becoming the Neon Genesis Evangelion of mathematics courses. (Explanation)

Do take a look at the syllabus.

-Taras Kolomatski