COMP396 Automated Trading Project
INDEX | NEXT | PREVIOUS
Assessment 2: Evaluation of trading strategies (30%)
Summary
For this assessment you submit a single file containing your strategy (implementation of getOrders. Your strategy will be run on part 3 of the data, and its resulting performance will be
used to determine your mark in accordance with the marking guidelines below. Deadline and submission details
The deadline for submitting your trading strategy is 12:00 Wednesday 25 March 2020 (Week 9).
You need to submit an implementation of the function getOrders.
You can implement a selection of strategies, but they must all interact with the backtester via
a SINGLE implementation of getOrders.
Please submit your getOrders implementation in a file called teamX.R where X is replaced by
your team number, for example, team5.R.
Note
At the top of teamX.R please give the list of parameters in a variable called params that you would like passed to the backtest function backtest. For example:
params <- list(lookback=50,sdParam=1.5,series=1:10) # params for bb
This could be NULL if you hardwire parameters into other parts of your code:
params <- NULL
If you use any packages make sure to require them in your code. Only use pacakges that you are sure are readily available (if we can¡¯t install them then we can¡¯t run your code). Naturally, all the packages that are installed on the lab machines are fine.
Please submit your file via the department submission site (like last time). Only one person from your team should submit!
The evaluation of trading strategies will be automatic. If your implementation of getOrders does not work then you will get zero marks for Assessment 2.
To be clear: You have no choice in the way that you interact with the backtester. You must write an implementation of getOrders() which takes the same arguments and returns the same
things as the backtester code that is on the module webpage. The examples in the distributed code demonstrate how your strategy will be run using the backtest function (the only difference will be that trading data instead of training data is used).
Hint
A simple way to check that your implementation works is to run it with the backtester on part 1 or part 2 the data. To do this just edit main.R to source your implementation of
getOrders and in addition pass backtest your params if needed. The only difference for the evaluation will be that part 3 of the data is used.
Part 3 of the data is the continuation of part 2 of the data, which in turn is a continuation of part 1 of the data. That is, the first day of the part 3 of the data time series will be the next trading day after the end of the part 2 of data time series.
Naturally, the order of the series (1,...,10) is consistent across the three parts of the data.
Data and trading assumptions
The data is derived from real OHLC daily financial data but names of instruments are not identified. All data is denominated in a single currency.
For detailed information on the types of orders, see here.
TABLE OF CONTENTS
Home
Teams and Supervisors
Timetable
Assessment 1: Design presentation and report (20%)
Assessment 2: Evaluation of trading strategies (30%)
Summary
Deadline and submission details Data and trading assumptions Marking Guidelines
Running time
Slippage
Penalty marks
Assessment 3a: Final report and source code (50%)
Assessment 3b: Peer review exercise
SEARCH
Enter search terms.
Go
The performance of your strategies will evaluated using the PD Ratio, as computed within
Backtester and data
Lectures and slides
Exercises
Programming help sessions
Minutes
Assessments
Suggested reading
R resources
Plagiarism and Collusion
Marks
Description
Guarantees
Performance
Guaranteed Mark
7.5
Taking positions.
Let be the percentage of trading days on which you took a position in at least one of the series.
marks
Below are three examples
marks
marks
marks
7.5
Best PD Ratio over individual series
15
Return
30%
15%
0%
15
Aggregate PD Ratio
backtester.R.
Marking Guidelines
Your strategies will be judged on the following three criteria
1. Return: You start with ¡ê1,000,000. Your return is how much you increase this in percentage terms. So, if you end with ¡ê1,200,000, then your return is 20%.
2. PD Ratio: This measures how much risk you took to get your return. It is computed by the backtester for you.
3. Activity: This is measured by how many days you took a position. You do not have to trade every day, but your strategy should be active throughout the data series. This is a secondary category: if you manage to get good returns with a good PD ratio by only taking a position on a small number of days, then you will not be penalized.
In order to ensure that teams are not too heavily penalized for a poor overall performance (i.e., low Aggregate PD Ratio over all ten time series), some marks will be available for
1. taking positions regardless how profitable they are (details below) 2. the best performance on an individual series
In addition, to guide you in your development, mark guarantees are provided. For the return and PD ratios, these have the following meaning: if you achieve above a certain return or PD Ratio then you are guaranteed to acheive a certain mark (however you may actually get this mark for a worse return or PD Ratio). For your convenience the PD Ratios that will be used are output by the backtester.
Running time
Naturally there must be a bound on how long your strategy code can run for. Please make sure that you code runs on part 2 of the data on a PC in one of the labs in less than 40 minutes.
If your strategy takes longer than this to run on the test data, we reserve the right to deduct marks in accordance to how much longer it takes (see below).
Slippage
Slippage will be calculated as 20% of the overnight gap.
Penalty marks
In case there is a problem with your code, certain penalties will be applied as follows.
Offence
2. The submitted code does not run on part 3 data without errors (minor). This may be in addition (and even caused by) or separate to the previous offence. It is minor if it can be fixed without returning the code to the team.
Penalty
1. An attempt to alter or use data/variables outside of the submitted strategy file that contains getOrders. For example, any attempt to
directly access the full data (e.g. by loading it with getData), or to set global variables (e.g.: with <<-, which may affect the running of the framework itself). You can only work with the data passed to getOrders and set things within it and via its return arguments
10% (3 marks)
10% (3 marks)
3. The submitted code does not run on part 3 data without errors (major). This may be in addition (and even caused by) or separate to the first offence. It is major as opposed to minor if the code has to be returned to the team to be fixed
20% (6 marks)
4. The submitted code takes too long to run on part 3 data. As mentioned above, as a general quideline it should take not more than 40 minutes to run on a lab machine.
10% (3 marks)
SHOW SOURCE
Last updated on Jan 27, 2020. Created using Sphinx 1.6.3
.