CSC 458, Spring 2010 : Functional Programming and Computational Finance
1 About the Course
I’m an expert in functional programming (that’s what I get paid for). I’m also interested in Computational Finance (that’s why this class is happening). Am I an expert in Computational Finance? No, I’m not. For this reason, this class will have a somewhat exploratory flavor. This will require maturity on your part. That’s why it’s a 400-level course!
2 Outcomes
At the end of this course, you should be able to use a functional programming language to build simple financial models.
3 Prerequisites
Students taking this course must be able to design and implement medium-size programs (~ 5 KLOC) efficiently. Students must have a basic understanding of mathematics.
4 Names, Times, Locations
Google Calendar:
See my Cal Poly Home Page for my calendar, including times & locations of labs, lectures, and office hours. You can add it to your calendar, if that makes your life easier.
4.1 Instructor
name: John Clements
telephone number: 756-6528
e-mail address: aoeuclements @ brinckerhoff.org
4.2 Lecture & Lab
Lecture: 0800–0900, MWF, room 186-C101
Lab: 0900-1000, MWF, room 14-302
4.3 Web Page
This is the course web page, its link is http://www.csc.calpoly.edu/~clements/csc458-sp10/.
5 Computing Environment
We will be using F# for this class. Those of you comfortable using Windows should go ahead and use Visual Studio for this, as it doubtless has really nice language integration. The rest of us will use Mono + F# on the lab machines – note that this is an entirely free (as in beer) setup, so I’m not requiring you to buy anything here.
Know of good F# tutorials? Send mail to the google group.
We’ll be handling handin using a subversion repository. Details to follow.
6 Readings
Ooh, this is a tough one. In a perfect world, you would all have a bunch of textbooks (Hull, Wilmott, etc.) and I would assign lots of readings. I hate to make you buy these great big books, though, because they’re heavy and they’re incredibly expensive. We’re going to try to get by without them.
7 Communication
There is a google group, csc458-sp10. You will need to join this group. You can request this by visiting the url
http://groups.google.com/group/csc458-sp10
I will use this group to tell you about important changes and updates to the assignments. However, it will also be a forum for you to help each other. As long as you’re not posting code, I strongly encourage you to ask questions and to respond to questions on the group. For this reason, I also require you to sign up in individual e-mail mode, and not in digest mode. Finally, you need to make sure that your postings are professional and civil. Imagine that your boss is reading them (I am).
8 Assignments/Milestones
This class will tentatively consist of four small assignments, and one final project. The small assignments may be solved in pairs. The final project should be done in teams of two or three.
Unless otherwise specified, all assignments are due at 11:00 PM.
Along with any code you submit you must also include a Makefile whose default target builds the code, and a README that describes how to run the project against your tests.
9 Handin
This class will use a central subversion repository, hosted on li128-9.members.linode.com. We will use this repository to synchronize all work in the class. That is: in order to hand in your code, just make sure that it’s in the repository.
If you’ve never used revision control: yikes! Okay, here’s a brief summary: systems like subversion (and git and...) "keep track of" a directory or set of directories on your machine by tracking all changes to these directories and allowing you to synchronize these directories with other users on other machines. Revision control systems allow you to "roll back" any accidental or unwanted changes ("oh dear, that refactoring isn’t going to work out after all") and to make sure that you and the others you’re working with are both working on the same set of sources. That’s an absurdly brief overview, and should give you enough to google on.
Your login ids will be the same as your calpoly.edu login ids. I will mail your repository ids to you separately. The repository is organized like this:
/ |
- public |
- clements |
- bogusman |
- nonexistiamus |
... |
- private |
- clements |
- bogusman |
- nonexistiamus |
... |
That is, each member of the class has a path in both public and private. The public paths may be used to share test cases, and the private paths are for your own code. Everyone has read access to the entire public tree, and each person has write access to his or her subdirectory of the public tree. Each person has read and write access to his or her subdirectory of the private tree.
In order to get you started, I’m going to provide a number of command-line examples of how you might check out your own portion of the tree, add a directory, commit it, and update to see whether anyone else has made any other changes.
9.1 Checking Out for the first time
Checking out your own portions of the repository, assuming your name is glognar (N.B.: watch out for wrapped lines in the below):
cd ~ |
|
mkdir csc458 |
|
cd 458 |
|
svn co http://li129-8.members.linode.com/csc458-repository/public public |
<enter user name and password; if svn guesses user id wrong, hit return for a chance to enter the right one.> |
|
svn co http://li129-8.members.linode.com/csc458-repository/private/glognar/ private/glognar |
Obviously, you can choose your own parent path, but I suggest keeping the other bits in the same places relative to each other, so that you directory structure mirrors that on the build machine. If you want to refer to code that lives in the public repository, you can then use a path like "../../public/clements/whatever".
9.2 Adding a Directory
cd private/glognar |
|
mkdir foo |
|
svn add foo |
|
svn commit -m "I added foo" . |
9.3 Updating
svn up . |
9.4 Creating a Branch to Hand in
Handin will consist of creating a branch (a.k.a. subdirectory) with a specified name. For standalone assignments, you can simply create this directory and do the work there. Here’s how you might do this for Assignment 1:
cd private/glognar |
|
mkdir Assignment1 |
|
svn add Assignment1 |
|
svn commit -m "created new dir" . |
Alternatively, if a particular assignment is just a step in a larger project (say, building a compiler), you’ll want to create a branch by copying the current state of the project into the named subdirectory. So, if you’re working in a subdirectory called "compiler", you could branch off an Assignment 1 handin like this:
cd private/glognar |
svn cp compiler Assignment1 |
svn commit -m "created branch for Assignment1" |
Keep in mind that making changes to that Assignment1 directory’s files would probably be a bad idea, because those changes would not appear along the main trunk.
That’s the briefest of introductions. Please let me know if I’ve made any mistakes, or if you have references to particularly helpful introductions to subversion.
9.5 Working with a partner
You and your partner should use the same repository subtree. After all, one of the most important advantanges of version control is that you can safely cooperate on the same source tree.
To make this work, you should designate one pair member’s repository tree as the one in which you’ll work, and both partners should share the password assigned to that subtree. Do all of the work in that set of trees (e.g., /public/glognar and /private/glognar).
10 Teams
This class allows teams of size two. You are not required to work with a partner, but I strongly encourage it. You may change partners between assignments. Changing partners mid-assignment or mid-final-project is generally not allowed.
11 Cheating
In the programming assignments, you may not copy another team’s code (including test cases and pseudo-code). You may not share code with other teams in the class. That is, you may not allow another team to see the code you write for the class, deliberately or through obvious negligence.
Any code you submit that is attributable to another source must be clearly identified as such. In general, you will not receive credit for code that your team did not write.
I will use an automated tool to compare student submissions and identify cheating.
Students believed to be cheating–that is, both parties involved in the transfer of code–will receive a failing grade in the class.
12 Exams
There will be a midterm exam in the class, in the sixth week. There will also be a final. These will both be closed-note.
13 Grades
Grades will be determined by performance on programming projects, and class interaction. A small fraction of the grade is determined by the instructor’s whim.
The breakdown of the grade is as follows:
Assignments: 65%
Midterm exam: 10%
Final exam: 20%
Instructor’s Whim: 5%
13.1 Grading Methods and Expectations
I will grade submitted code by running test suites of my own devising and by running your test suites and by reading your code. Just to make this clear: if you write gross horrible code that happens to be correct, you will generally receive a poor grade. Also, code that does not compile generally gets a score of zero.
I will grade your presentations and demonstrations and code and design reviews based on the success of the demonstrated code and upon the content and delivery of the presentation.
Naturally, all grades contain an element of subjectivity.
14 Attendance Requirements
I do not formally state attendance requirements.