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!
At the end of this course, you should be able to use a functional programming language to build simple financial models.
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.
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.
name: John Clements
telephone number: 756-6528
e-mail address: aoeuclements @ brinckerhoff.org
Lecture: 0800–0900, MWF, room 186-C101
Lab: 0900-1000, MWF, room 14-302
This is the course web page, its link is http://www.csc.calpoly.edu/~clements/csc458-sp10/.
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.
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.
There is a google group, csc458-sp10. You will need to join this group. You can request this by visiting the url
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).
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.
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:
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.
Checking out your own portions of the repository, assuming your name is glognar (N.B.: watch out for wrapped lines in the below):
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".
svn add foo
svn commit -m "I added foo" .
svn up .
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:
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:
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.
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).
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.
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.
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.
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:
Midterm exam: 10%
Final exam: 20%
Instructor’s Whim: 5%
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.
I do not formally state attendance requirements.