Asymptotic Investors

A Flexible Simulation Environment for Trading of Derivatives of Multiple Asset Classes

ContentsTrading Simulation Template.........................................................................................2

Trading Decision Policy Enforcement..........................................................................4Pricing Algorithms Supported.....................................................................................5Inputs to Pricing Algorithms.......................................................................................5Commodity Futures Price Estimation Issues...............................................................5VaR and Transaction Cost Heuristics..........................................................................6Previous Day’s Price...................................................................................................7Trading Table Running Snapshot.................................................................................7Returns, Volatility, Margin, and Sharpe Ratio Calculation...........................................7Single Pass to Compute Summary Statistics..............................................................8Clearing of Old Results...............................................................................................8Profit Estimation.......................................................................................................10Day Trading..............................................................................................................10Test of Simulation.....................................................................................................11Model CSV Input Architecture...................................................................................13Update: Correction to Covered Interest Parity Calculation and Spot Rate Source....15Merge of Currency and Commodity Price Files.........................................................17Integrated Portfolio Performance Simulation............................................................18Test of Two Month Simulation...................................................................................29Monte Carlo Simulation of Profit...............................................................................30Sanity Check of Model Prices....................................................................................30Date and Time Utilities.............................................................................................30

Incorporating Quandl Data.............................................................................................32Migrating to Third-Party Platform: Quantiacs.................................................................32

Quantiacs and Octave Difficulties................................................................................33Demonstration Algorithm: Commodity Pairs Trading..................................................36

Bibliography...................................................................................................................36

Trading Simulation Template In order to simulate many trading strategies over multiple portfolios with multiple holding periods, a set of Excel tables will be developed. A scenario analysis will involve predicting the position profit/loss, total transaction cost, and maximal 10-day VaR over the holding periods. Netting effects and the portfolio-level outcome should also be computed. Each underlying will have a separate lognormal distribution for price moves in an hour. In some simulations (such as those involving arbitrage), new positions can be opened after the starting date, and thus a record of the current price for a limited universe of securities (including some not initially traded) must be maintained. While this is basically just a simplified version of what would result from running many high-frequency trading simulations repeatedly with different baskets, the Excel sheet may enable an easier way to consider the business flow without preoccupation with bugs in the code. The point if for allow fund managers to adjust the control and securities tables and then, with a single keystroke, run a simulation of several months in length to assess a strategy’s profitability. However, simply providing the code and the price type is not enough, as, for the commodity futures contracts, the spot price must be known.The goals of this template are: monitor the pricing accuracy of the models for futures (model price vs market price accuracy should be an output metric per contract, present the risk levels assumed by an automated strategy, and assess the returns possible by such a strategy. The Excel functionality for configuring open and close criteria for a contract should be migrated back into the commodity and currency futures UIs.Three tables will be involved in the simulation: the securities master, the control table, and the simulation results output. The control table will map each code in the universe to open criteria, close criteria, market price style (Brownian motion or historical), Brownian mean and variance, historical data cells, model price (e.g. CIP for currency, Logistic Regression for commodities). The simulation results involve two aspects, the contract’s price movements and the profit/loss outcome from the actual holdings. Note that any simulations involving dates later than the present will use only Brownian motion for market pricing. Each simulation will likely require a separate securities master and control table. Open criteria and close criteria logic is non-trivial to implement in Excel, involving checking of model price data in another table or considering the date offset from the start. It is debatable that the day number is a valid metric for obtaining a profitable strategy. However, it is included for two reasons: 1. as a basis for comparison with the quantitative model pricing approach, and 2. to enable manual trades to be set up to accommodate seasonal, holiday, and news-event-based positions (e.g. stockpiling soybeans during a drought or buying gold during a major dollar devaluation). If the model strategy proves successful, all day-count-based strategies can be discounted. A screen shot of a test run of the function to retrieve the daily drift from the securities master sheet is shown below. The “getMeanSec” function was invoked in a test cell within the “trade_sim” sheet. The “getMeanSec” code was placed within “module1” in order to be visible to the worksheet. The actual “securities_master” sheet follows.

The “model price” will involve repeatedly calling the Algorithm module’s “maxLikelihoodPrBayes” and “maxLikelihoodPrLog” methods and outputting the code, date, and price to a CSV file (the Algorithm module will need to be extended for such functionality). For currency pricing, the Arbitrage class’s “computeCIPPrice”, “computeTriangularRates”, and “computePPPRates” methods, along with the Pricing class’s “getVarPrice” method, must be invoked. Optimally, the Excel VBA macro could run exes to invoke the C# and C++ modules and copy the results from their output streams back into the sheet. Otherwise, some sort of bridge using the file system might be necessary. Note that the security master sheet must be saved as a CSV file and read into the scripts. For each trading day, the scripts will determine which codes match the product category handled by the respective module (currency or commodity), call the price inference class, and write the output to another CSV file. Note that the securities master must be modified to include the pricing model to use (e.g. covered interest parity or linear logistic regression). For initial testing purposes, model prices for two days can be filled in manually on the “model_prices” sheet.

The Brownian Motion simulation can be carried out using the Central Limit Theorem. Draws from a uniform distribution will be carried out repeatedly with a max value of 1 (100% return) and a min of 2*mu-1, where mu is the desired mean of the normal distribution. The number of draws to be averaged will be n = sigmau^2/sigman^2, where sigmau = (max-min)/sqrt(12)=(2-2mu)/sqrt(12) is the standard deviation of the uniform distribution, and sigman is the desired standard deviation of the normal distribution (one for now). The reasoning behind the sqrt(12) divisor is based on the moment generating function of the uniform distribution. The derivation of the number of draws is also not straightforward, and is based on equating the standard deviation of the normal distribution with the standard error of the sample mean. For a small uniform range, this number can be less than one, which is impractical. Thus, using the uniform variable (u-muu), summing over n draws, and dividing by (n*sigma^2), results in a variable with mean zero and standard deviation of one (this is the Lyapunov Central Limit Theorem). The final normal distribution is thus independent of the number of draws. To obtain N(mu,sigma^2), where mu and sigma^2 are the mean and standard deviation of the uniform distribution, generate the variable ∑ui/n. Solving a system of two equations yields the [min,max] range of [mu-sigma*sqrt(3),mu+sigma*sqrt(3)].“Brownian Mean” and “Brownian Variance” are settings for each futures contract in the simulation securities master, so, on each day, a draw will be run from a separate distribution for each contract. The daily returns will be generated by a script (likely Excel Macro) executing a dual for loop, the first iterating over dates and the second iterating over contract codes. This script will look up the mean and variance for the Brownian motion from the security master table, execute a random draw to obtain the return r, multiply (1+r) times the previous day’s price, and thus finalize the current day’s price.A standard problem in trading and market data processing not addressed immediately by this application is trading recesses on holidays and weekends. For now, every consecutive day between the start date and end date of the simulation is assumed to be valid. Later on, some sort of “business day” logic may be added.A sample histogram generated by the “lookupBrownianReturn” function is depicted below, with mean of .06 and variance .1. The canonical “bell curve” topology obtained indicates that the function is likely implemented correctly.

0.0010.01

0.0190.028

0.0370.046

0.0550.064

0.0730.082

0.091More

0

40

80

Histogram

Frequency

Bin

Freq

uenc

y

Trading Decision Policy EnforcementThe control table will contain options for the open and close policies for each contract in the portfolio. These policies, along with the market price and (in the case of the open) the model price, will determine what the number of contracts held at the end of the trading day will be. For example, if the policy is “10% market-model diff” and the open side is “market-dependent” (as the settings are for February gold in the demonstration portfolio), then, if the model price is 1100 and the market price is 980, a “buy” order would be justified. Note that the ten percent band is sensitive to the side of the order. If the order is a buy order, the market price must be more than ten percent below the

market. For a sell order, it must be ten percent above. An excerpt below from the first trading day shows the policy enforcement—positions are opened for the first two codes (day 1 open and 10% sell) but not the third (10% buy).

Day CodeMarket Price

Model Price

Num Contracts Position

Per-Period Profit

12/6/2016 9:01 6SU7 1.0055 1.07476 3377062.

5 012/6/2016 9:01 6SZ6 1.014 0.9 -2 -253500 0

12/6/2016 9:01 6SH7 1.01980.77838

8 0 0 0

Note that all contracts must be closed by the final day in the trading period. In addition, at any given time, only one position in a given contract can be established. The former provision can be enforced by adding a new clause to the “canClose” test. This function will return true if the current date is equal to the final day (if the delta t granularity is one day) or the final hour (if the delta t granularity is one hour).

Pricing Algorithms SupportedCurrency Futures

1. Covered Interest Parity2. 99% VaR3. Purchasing Power Parity

Covered Interest Parity is a mechanism which prices exchange rates to prevent arbitrage based on interest rate disparities between countries. Purchasing Power Parity is a formula which prevents arbitrage based on lower price levels for equivalent goods in different countries. The value at risk pricing mechanism computes a worst-case price scenario where a loss is incurred which could not occur at such a severity or greater with a confidence of 99%.Commodity Futures

1. Logistic Regression2. Naïve Bayes

Inputs to Pricing AlgorithmsThe point of a simulation is to compute pricing model outputs over multiple dates and to use these model estimates to interpret market signals, translating such market information into trading decisions. The covered interest parity algorithm is sensitive to the present spot rate of the currency pair, so this rate must either be known (from historical data) or estimated (via stochastic simulation) for each date and time covered by the simulation. The interest rates also used as inputs will vary with the time, so the function which retrieves these from the database should be parameterized by date instead of simply returning the most recent interest rate for the currency. There is no automated mechanism to populate the spot rates or interest rates tables currently, so the administrator must load appropriate rate data for the currencies, dates, and terms desired. For the value-at-risk estimate, the futures price on the simulation date must be known, and not simply the price of the date on which the simulation is run. This will be addressed by modifying the pricing method to query the database’s ticks table (which must be updated regularly by the TickPopulator) instead of making an HTTP call for the current day’s prices. In the commodity futures case, the spot price is the price published on that date and the maturity is the expiry date of the contract (not the holding period). The “holding period” input in the sheets and CSV files is an

enhancement for the future to allow different contracts to have different price calculation logic based on how long they will be held for but is not used currently.

Commodity Futures Price Estimation IssuesSome problems were noted using the Naïve Bayes pricing algorithm to price soybean, gold, and Brent oil futures over the simulation period 12/6/2016-1/6/2017. Strangely, the determinant of the covariance matrix was zero, inducing an infinite coefficient for the Gaussian density computation. The covariance itself was valid (despite empty third rows and third columns due to a lack of news settings in the database). In fact, the problem is the newly-added news factor, which induces the third rows and columns to be all zeros. Such a state guarantees that each term in the determinant sum will contain a zero factor, making the total zero. A new module to populate the nbweights table with default news mean and covariance values (pending adjustment to the training algorithm to write such data back to this table).

VaR and Transaction Cost HeuristicsValue-at-Risk (VaR) of a position will be based on the notional value and volatility of the holdings of a given contract. The summary’s one-day VaR will be max(1-day VaR) over all trading days. The one-day VaR on a trading day is units-per-contract*price*numContracts*(2.33*(1-day-volatility)+mean). The summary’s ten-day VaR will be the maximal 10-day VaR which is one-day VaR times sqrt(10).Transaction costs can include brokerage commissions, network fees, and slippage. These will be assumed to amount to five basis points (.0005) of the maximal total notional maintained during the holding period (units-per-contract*price*numContracts). Given the introduction of day trading into the model, inducing a higher transaction volume, a per-trade transaction cost model may need to be implemented. The net profit will be the profit from trading minus the transaction costs.Note that, in the case of both VaR and transaction costs, the sign will be dropped from the number of contracts.The value at risk for 10 days was sight-checked to be correct. The daily trading row below indicates the approximate maximal position, and the summary row following it indicates the one and ten-day value-at risk values for Swiss Francs with a March maturity (6SH6).

Day CodeMarket

PriceModel

Price

Num Contract

s PositionDaily

Profit

3/2/2016 6SH61.04224

3 100 2260560.

845.2439

4

code

profit transaction costs

maximal one-day VaR

maximal 10-day VaR net profit

6SH69448.074 130.280

46666.93722

21082.71 9317.794

Note that the above reflects a maximal position of about USD 260560.82, a volatility of about .010709, and a drift of .000635. The formula for 10-day VaR is thus:sqrt(10)*260560.82*(2.33*.010709+.000635) = 21082.708

Portfolio VaRThe next desired metric for the simulation would be the portfolio value at risk. This would involve aggregating the variances of all contracts held. However, the formula also considers the pairwise correlation of all contracts, as is indicated by the two contract formulasigma^2p = w1^2*sigma1^2+w2^2*sigma2^2+2*w1*w2*sigma1*sigma2One possible way to address this problem is to consider all pairs of securities (n choose 2) and encode their correlations in a matrix, but this would be somewhat time consuming (about O(5000) for 100 contracts).

Previous Day’s Price In order to mark the portfolio to market each day, the previous day’s prices must be remembered. This will be accomplished using the Scripting.Dictionary associative array. In the case of the code which iterates over the Brownian sheet’s returns and writes the trading results sheet, a copy of the table must be passed to the “processSecuritiesDate” function and returned back to the “brownianReturns” caller.

Trading Table Running SnapshotSimilar to the memorization of pricing information, the most recent information about the current price, profit, open price, and position will need to be cached in memory when creating the trading results table. This will be accomplished by another Scripting.Dictionary object which will be updated in the “fillInStratResults” subroutine and will be visible globally. A “secOffset” field, which indicates the offset of the code in the securities table, will be maintained here, as it will be used to lookup attributes such as the units-per-contract multiple (could also be used for mean and variance, which currently uses an O(n) search).

Returns, Volatility, Margin, and Sharpe Ratio CalculationIn order to make the returns comparable to those produced by other traders, a risk-adjusted performance metric must be computed. Such metrics include the Sharpe ratio, the Sortino ratio, and the information ration. Of these, the Sharpe ratio is the most common. However, in order to obtain the value, s = (mu-r)/sigma, where mu is the expected value of periodic (daily) returns, r is the risk-free return rate, and sigma is the periodic return volatility, several new fields must be computed. The first is the daily percent return for the entire portfolio of securities. Computing this is non-trivial, as the amount invested will vary each day. An alternative is just to include cash in the portfolio and thus use a return on a fixed portfolio investment which is invariant, but then capital limitations would need to be enforced. For the time being, the initial capital, taken from the control sheet, will be utilized as the invested amount divisor, since this approach would be comparable to the computation of returns on a hedge fund. However, as was noted above, this initial amount will have to be debited and credited for margin whenever positions are opened and closed.The logic will assume that all codes for a given day will have the same timestamp (at the deltaT granularity). The fillInStratResults code, which loops over every security on every day/time, will invoke the method to set the daily portfolio return, passing the timestamp and the row offset for the result to be written in the “daily trading results” sheet. The mean, volatility, and Sharpe ratio of the daily returns (annualized) will be written to both the “daily trading results” sheet and the “trading sim” control/summary sheet. A key point will be when to display the returns as “daily” (simple profit/investment) and “annualized daily” ((profit/investment)*252). For now, two separate columns will be used for each day, with the annualized values used for the mean, volatility, and Sharpe ratio. This calculation logic is important to fund performance attribution as, if a large portion of available capital is not invested, the returns, even if strongly positive relative to the value of assets traded, will be negligible relative to the fund size.

Test of Return and Sharpe Ratio LogicThe new functionality to calculate and record daily returns, annual returns, and the Sharpe ratio was tested. Initially, the read of the risk-free rate (three-month USD LIBOR) from the control sheet was validated. Next, the daily returns were checked over six days. Interestingly, they seemed to be zero every other day for the first week, but this trend ceased later (positions were closed and no new ones opened on that day, it is suspected) One problem encountered was that, in order to avoid adding an item to a hash table twice, the value in the table needed to be modeified in place. Thus, a reference to an object needed to be obtained. Fortunately, the Set keyword in VBA accomplishes this task, with, for example, Set pi = datePortMap.Item(currT). The fact that returns are properly annualized was checked, as weres the mean computation and volatility logic. Note that, although the average returns are negative, the volatility will always be positive. The final output from a sample run is below.

Mean of Annualized Returns -0.0163Volatility of Annualized Returns

0.029961

Sharpe Ratio -1.00463

Interestingly, the mean annualized daily returns are always slightly negative and close to zero, as the ten test outcomes below indicate

1 -0.015412 -0.013233 -0.008894 -0.001475 -0.011536 -0.007857 -0.014898 -0.006419 -0.00461

10 -0.00881

Single Pass to Compute Summary StatisticsWhile a typical dual for-loop could be written to iterate over all securities and days to complete the summary table in O(m*n), where m is the number of securities and n is the number of days, an O(n) approach in time with memoization can be adopted. The drift and volatility can be preloaded from the securities_master sheet into a hash table which maps each security code to a tuple of summary information. The order of summary items is based on the code list read from the security master. The dictionary of TradeRow objects maintained while setting the trading table can be translated to a list of SummaryInfo objects in O(m) time.

Clearing of Old ResultsAlthough the summary, Brownian motion, and daily trade sheets are replaced column-by-column in each run, old data could persist, if a previous simulation covers more rows than the current one. In addition, the control sheet is completely manually populated, and its length will change based on the number of contracts in the securities master file. Ideally, the Brownian motion, daily trade, and summary data should be deleted prior to a new simulation run. This might be done by clearing the first 10000 rows of the sheet (which would cover 20 contracts over 500 days). This functionality will be enabled in a subsequent release. For now, users should expect to see a sudden discontinuity in the date (for simulation rows) or a security that does not belong (for security rows) when old data persists.

A new macro is being written to reset the Brownian motion, daily trade, control table, and summary table. This code will be run after the security master is in place but before the “runBrownian” or “mcSim” macros are run. The code to erase all cells in the Brownian and daily trade sheets is straightforward, calling the “clear” method on the rectangular range (e.g. A3:D9999). However, several cells in the control table, such as the open and close criteria and the algorithm, are based on list selection which are set by the “validation” menu in the “data” tab. This information can be set in the cells programmatically via the “With <range>. Validation” syntax, which allows multiple properties of the Validation property to be set concisely. The codes will be read from the security_master sheet and used to compute the row counts of the control and summary tables. Note that the “SecInfo” type defined to contain a row needed to be set as a class module in order for it to be contained in a generic Collection object. In addition, the syntax for adding objects to a collection is rather strict, as “retColl.Add(si)” failed, but “retColl.Add(item:=si)” succeeded. In addition, the “formula1” field is set with the Excel-formula-style syntax "='" & Worksheets(controlSheetName).Name & "'!" & ptValidRng.Address, where “ptValidRng” is a range variable.It is hoped that, eventually, every step needed to set up and run the simulation can be handled programmatically, including the kick-off of all C#, C++, and Java executables and the loading of the model_prices.csv file into the workbook.

Simulation Including ResetAfter the sheet was reset, the Brownian simulation was rerun. No problems due to the reset in the Brownian results, daily trading results, or control table sheets were detected. However, the “plus one hour” close criterion failed in the case of a Swiss Franc position, as a short position was doubled instead of being closed. This was determined to be an error in the “canOpen” function. This needed to include a check that the number of contracts open was currently zero, as otherwise canOpen should be false and canClose true. Upon editing this function, the open and close times for the three securities were as follows.

Code Open Date Close Date

6SM6 {2016/05/16 09:00:01, 2016/05/16 11:00:01, 2016/05/16 13:00:01, 2016/05/16 15:00:01} {2016/05/16 10:00:01, 2016/05/16 12:00:01, 2016/05/16 14:00:01, 2016/05/16 16:00:01}

ZCN6 {2016/05/16 09:00:01} {2016/05/16 16:00:01}

ZWN6 {2016/05/16 09:00:01} {2016/05/16 16:00:01}The next step is to update the securities master sheet and reset the three sheets, in order to verify that the control table size can vary. In fact, with a new securities_master containing 13 contracts, added, the script to reset the sheets works correctly. Model prices for currency and commodity futures were generated from the security master subsets for each product group, and these model price files were merged into a new combined model prices sheet. This stage was also validated, although the “plus 1 hour” close functionality was found to contain an error, in that it would not close contracts one day later, in the event that the time step is one day. This error is acceptable, as this setting could have behavior defined only if the time step is one hour. Thus, the simulation was rerun with a close time of “day 25” for the “plus one” closes, and the open and close patterns were verified to be correct.

Profit EstimationIn order to compute inter-day profits in the simulation, the product of (number of contracts), (units per contract), and price must be computed only for those contracts held over the two day span (i.e. not those opened or closed on the current day). This model assumes that, for any given contract, only one open and once close action can occur within the portfolio during the simulation period (needs to change for day trading). The position size must be traced within the “daily_trading_results” sheet, and the open-to-close profit will be recorded in the summary table of the “trading_sim” sheet. In the case of the daily results the positions are compared only if the number of contracts held is uniform on the previous and current days (otherwise, profit is set to “0”).

Day TradingInitial tests involved a single open or close operation on any given day, due to the recording of market prices and positions at the day granularity. However, this granularity could be updated to the hour or minute level simply by increasing the volume of data in the “Brownian_Results” and “Trading_Results” sheets. Then, the simulation would iterate over all securities in the portfolio multiple times per day. However, the daily volatility would have to be reduced to compensate for the reduction of the time step size.Modification to Allow for Intraday TradingThe control table and macros are being further generalized to allow pricing and trading decisions on an hourly basis. Firstly, the start and stop times must be added to the start/end date fields in the control sheet (B2, B3 of “trading_sim”). In addition, two new fields, “delta t number” and “delta t units” will allow a specified number of hours or days to constitute a time step. New open criteria will include “hour 1”. New close options include “hour 6” and “plus 1 hour”. Functions affected include “runTradingSimBrownian”, and “brownianReturns”, “canOpen”, “canClose”, and “checkDay”. The ability to open and close a single contract multiple times during the trading session will be a necessity for effective day trading, and the current infrastructure (which determines whether the contract can be opened without checking whether it already was) should be adequate. However, multiple open and close times for each contract

will be possible, so these fields in the TradingRow and SummaryInfo structures will need to be stored as arrays. Similar arrays will be required for the open and close prices.An issue not specific to intraday closing of opened positions but more clearly illustrated by a short holding period is that the model price of the C# and c++ code is based on a holding period lasting until the maturity of the contract. This may appear to be a problem, if the contract is not held to maturity. However, as an indicator of what a futures price should be, the contract maturity is adequate. The point of a futures contract is to set a price for delivery on the delivery date, so the contract date should be an input to a pricing algorithm. The mean and variance units need not change (i.e. should be daily for VaR pricing). This will enable the summary sheet to specify the pricing accuracy for one holding period of each contract. Note that the simulation end date MUST fall at a date after the end of a holding period for each contract. The holding period will be passed into and out of the model price logic, but for the time being will not be a factor in price computation. In the future, both maturity and holding period could be pricing parameters. This is somewhat complex, though, as the current parameter for the pricing model is the expiry of the contract, not the date on which the contract is going to be sold. For the time being, the date at the end of the holding period will be substituted for the expiry of the contract in the input to the inference. This should not induce any bias in the testing as opposed to the training, as training determines the “maturity” parameter as the time the contract would be held from the current date to expiry. This is an arbitrary interval. For now, the number of trading days in a year will be assumed to be 252. Note that, while the specification intended for deltaT and the holding period to be a floating point value, programming techniques used are constraining the hours or days to an integer value.Both the commodity and currency pricing modules must be parameterized with the delta t number (double precision floating point) and units (string “hours” or “days”), which requires changes to the “main” methods and the constructors for the primary classes (CurrPricesCSV or CommPricesCSV). The delta-t will be added to the previous pricing time to determine the new time (and spot) in the for loop which generates a new price for each contract at each time. The number of time steps will be computed based on the start date, end date, delta-t, and delta t units (functions “computeNDays” and “computeNHours” in the c++ code). Note that the spot price will not vary with each hour but should change every 24 hours. The “mean” and “variance” of returns specified in the security master table need not be in the units of delta-t (hours, if delta-t is a number of hours), as the prices are futures prices premised on delivery of the underlying at maturity. Both the read and write code for the model price generation programs will be modified to consider the holding period (including the Java merge program), butthe code which invokes the pricing logic will not pass the holding period, and the covered interest parity arbitrage logic will not consider the holding period in determining the interest rate term. Basically, the holding period is an attribute of a portfolio component that may be used in computing the price later but will not be processed currently.While it makes sense to align the schedule exactly with CME Globex or ICE electronic trading, this would require additional logic at little perceived gain in forecasting ability. Thus, a 24-hour operating schedule will be assumed for the time being.

Test of SimulationThe sheet generation was tested with default model prices of 100 set for all contracts (as the CSV file generation components have yet to be implemented). While the Brownian Motion returns (although quite small, due to the fact that they were daily moves) were generated correctly, the opening of positions did not occur as dictated by the control table. This was remedied by adding logic to the “open side” selection to correctly check the market price against the model price when the control table

indicated that the side should be “model-dependent”. While the number of contracts was correctly set, the position value was inflated (-2*10^8 when -200000 expected). This was due to an inaccuracy or idiosyncracy in the VBA interpreter to some extent. A variable for a value in a hash table which was out of scope was passed to the function to find the units-per-contract but, instead of throwing an exception, the interpreter passed the last value assigned to the variable in its scope. Upon correctly using a reference to a global hash table, the position was set correctly. Profit was correctly set upon initializing the current date variable (use without initialization was not caught by the interpreter). The close based on date functionality works correctly, but the profit or loss is never significant enough to hit a 10% threshold. A .01% (1 basis point) threshold is used for demonstration purposes. The “canClose” check can be invoked only if some contracts have been opened (else, the openPrice is 0, and a divide-by-zero error ensues). Note that the closing of contracts on the same day they are opened will not be allowed in the simulation (this disallowance of day trading is a substantial constraint, but it makes sense given the one-day time step size). Profits will not be realized from the quantity adjustments due to opening or closing the position, but profits should be realized from price movements on the closing day. The application has been adjusted to function in this manner. The profit in the “daily_trading_results” sheet is a daily profit, but the profit in the summary table is cumulative from open to close. In order to maintain a total of the daily profits for each contract, a “cumulative profit” field was added to the “TradingRow” class. This remedied the summary table’s profit display issues, but the gold holdings did not indicate the correct transaction costs or VaR. This was because the maximal position used for transaction costs and VaR needs to be unsigned (either long or short positions incur such costs or risks), and the gold contracts were the only ones shorted (negative position).Day Trading TestIn order to set up the workbook for an intraday trading simulation, the following steps were taken.

1. The macros were modified to store the open dates, close dates, open prices, and close prices in collections

2. Logic was written to parse for new open and closing conditions3. The control table was modified to have open and close criteria with an hourly

granularity, as specified above.A final merged model prices CSV excerpt is shown below. Note the time sensitive spot, interest rate, and model prices. date,code,spotComm,maturity,ir1,ir2,spotFX,mean,variance,threshold,modelPr,holdingPeriod,hpUnits2016-01-04 09:00:00,GCG6,1172.0,2026-02-28 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,950.0,1,hours2016-01-04 09:00:00,GCJ6,1172.0,2026-04-30 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,1200.390625,2,hours2016-01-04 09:00:00,GCM6,1172.0,2016-06-30 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,825.390625,20,days2016-01-04 09:00:00,B032016,37.08,2016-03-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,95.205078125,2,hours2016-01-04 09:00:00,B062016,37.08,2016-06-30 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,95.205078125,1,hours2016-01-04 09:00:00,B082016,37.08,2016-08-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,95.205078125,1,hours2016-01-04 09:00:00,ZSH6,8.63,2026-03-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,1818.75,1,days

2016-01-04 09:00:00,ZSK6,8.63,2016-05-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,1818.75,1,hours2016-01-04 09:00:00,ZSN6,8.63,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,1818.75,1,days2016-01-04 09:00:00,6SH6,-1.0,2016-03-30 00:00:00,-0.00509315,0.00315653,1.001,6.34921E-4,1.14683E-4,0.0,0.999065,1,hours2016-01-04 09:00:00,6SM6,-1.0,2016-06-30 09:16:00,-0.005,0.0032,1.001,6.15079E-4,1.08036E-4,0.0,0.997004,24,hours2016-01-04 09:00:00,6SU6,-1.0,2016-09-30 00:00:00,-0.005,0.0032,1.001,6.54762E-4,1.17397E-4,0.01,0.61649,1,days…2016-01-05 16:00:00,GCG6,1210.25,2026-02-28 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,950.0,1,hours2016-01-05 16:00:00,GCJ6,1210.25,2026-04-30 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,1200.390625,2,hours2016-01-05 16:00:00,GCM6,1210.25,2016-06-30 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,1225.390625,20,days2016-01-05 16:00:00,B032016,36.85,2016-03-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,95.205078125,2,hours2016-01-05 16:00:00,B062016,36.85,2016-06-30 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,95.205078125,1,hours2016-01-05 16:00:00,B082016,36.85,2016-08-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,95.205078125,1,hours2016-01-05 16:00:00,ZSH6,8.54,2026-03-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,1818.75,1,days2016-01-05 16:00:00,ZSK6,8.54,2016-05-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,1818.75,1,hours2016-01-05 16:00:00,ZSN6,8.54,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,1818.75,1,days2016-01-05 16:00:00,6SH6,-1.0,2016-03-30 00:00:00,-0.00484575,0.0027695,1.003,6.34921E-4,1.14683E-4,0.01,1.00124,1,hours2016-01-05 16:00:00,6SM6,-1.0,2016-06-30 09:16:00,-0.0048,0.0028,1.003,6.15079E-4,1.08036E-4,0.01,0.999315,24,hours2016-01-05 16:00:00,6SU6,-1.0,2016-09-30 00:00:00,-0.0048,0.0028,1.003,6.54762E-4,1.17397E-4,0.01,0.617298,1,days

Problems with Day Trading TestAll of the collection types-- open prices, close prices, open dates, and close dates—were empty at both the trading row and summary info levels for some codes. This would seem to suggest that these contracts were never opened during the session, as some codes did have open dates and open prices. Inspecting the dictionary insertion code indicated no problems, as the date and price were added to “openDates” and “openPrices” fields of an item in the “tradingInfoTab” hash table for those contracts which were opened. However, none of the contracts were closed, and, in some cases where the contracts were opened, a profit was recorded. The latter issue was noted even when the contracts were opened with long positions (which should be recorded as a debit transaction). This is due to the program’s marking the position to market with each time step. The lack of opens for some contracts was clearly incorrect, as, for example, “GCG6” should have been opened in hour one and closed in hour 6. This was due to incorrect date parsing. The close logic is also incorrect, as the only time any open contracts were closed at was the ending time of the session. One error involved an incorrect date calculation in the “plus n hours” check, and another involved the incorrect checking of the time offset in cases like “hour 6”. An infelicity in Excel, which

stores the time “1/5/2016 00:00:00” as simply “1/4//2016” was corrected by adding one second to the start time (if the time step is hourly, the “day” offset logic will be an hour late to be triggered otherwise). The logic which tracks the last row of the Brownian returns needed to be corrected by setting the “dayStartR” row variable to be the index of the first row to be written on the next day (instead of the first row read as the previous day’s prices) and by correctly setting the second time step to be used for the first return. Cumulative profit for GCG6 was verified to be correct using the following “array formula” on the daily trading sheet: =SUM(IF(MOD(ROW(G3:G386),12)=3,G3:G386,0)). The header for the profit column in “daily trading results” was changed to “per period profit”. VaR was verified for one contract, B062016, which was opened once (and never closed, incorrectly). However, in the case where multiple opens and closes occurred, the last profit logging seems to have been ignored in the tally. One and ten-day VaR was confirmed for multiple opens and closes.As an aside, the model prices for the agricultural products are off by a factor of 100, due to the incorrect min-max range in the database (should be in terms of dollars, not cents). The model will need to be trained with dollar-based inputs and outputs, also.Another aside is that the “VaR” pricing design, which fetches every security’s price in order to obtain the current price for a single code, is extremely inefficient and must be written. In cases where HTTP bandwidth is constrained (such as when an inbound scan is run on data), the pricing of a single contract can last several minutes.Excel Array FormulasAn Excel spreadsheet formula containing notation such as A330:A365 in the field usually occupied by a single cell is utilizing array syntax, where, if the formula is entered using “control-shift-enter” instead of enter, the conditional logic is applied on a row-by-row basis to all cells in the range. The formula is stored in the sheet enclosed in “{}” to distinguish it from a standard formula. For example, the formula to sum the profit only for every row numbered 6 mod 18 (Brent, March, 2016, in this case), the following formula was applied.{=SUM(IF(MOD(ROW(G3:G386),12)=6,G3:G386,0))}

Model CSV Input ArchitectureThree modules will be utilized to generate the modelprices.csv file to be imported into the workbook and used in comparison with the (Brownian motion or historical) market returns. The C# Commodity module will generate a temporary CSV file after obtaining logistic regression and Naïve Bayes prices. The algorithm (logistic regression or Naïve Bayes) and degree (linear or quadratic) will be columns in the input file. The C++ currency module will invoke a (new) Covered Interest Parity (later Brownian and VaR also) pricing API and write a second temporary file. Note that, in either case, the model price of a given day will not be directly derived from the model price computed from the previous day (although the two prices are likely to be similar due to the similarity in model input parameters). A third Java merge module will combine these two CSV files, based on the sequence of securities provided by the securities master sheet, and output the final model prices file for import.

Merge Module (C++)

Excel

modelPrices.csv Run simulation using model prices

Export securities

An example of the securities input file format for commodities with one row is below.code,underlying,Maturity,annual drift,annual volatility,daily drift,daily volatility,day 0 rate,algorithm,units per contract,degreeGCG6,Gold,Feb-16,0.1,0.13,0.000396825,0.00818923,1102.8,Logistic Regression,100,1The currency futures model pricing logic, written in C++, required more modification of the existing pricing code than did the C# commodities module. This was because the Covered Interest Parity rate had been calculated in the GUI logic and was not accessible via an external API call. Valid price type strings are “Covered Interest Parity” and “99% VaR”. The existing logic from DBHelper, which retrieves a vector of “CIPData” objects for a given term, while in this case a per-code lookup is desired. The 99% VaR calculation involves a simple call to the Pricing module’s “getVarPrice” method after computing the day count between the present day and the maturity of the futures contract.

Update: Correction to Covered Interest Parity Calculation and Spot Rate SourceIn fact, the interest rate multiplier for the CIP formula, which uses IR1 as the foreign rate and IR2 as the domestic rate, was inverted. The formula, originally:cipPr = spotRate*(1.0+normRt1)/(1.0+normRt2);

was revised to read: cipPr = spotRate*(1.0+normRt2)/(1.0+normRt1);The modelprices.csv sheet will need to be regenerated and the simulations rerun in

order to assess the model’s performance. In addition, the spot rate was originally based on a distinct spot_rates table, but, due to

the lack of a market data module that can access such cash market data, it will be based on the front-month futures contract. An excerpt from a CSV file output by the updated code is below. date,code,maturity,price type,spot

rate,IR1,IR2,threshold,mean,variance,modelPrice,holding period, holding period units2016-12-06 09:00:01,6SU7,2017-09-30 09:16:00,COVERED INTEREST PARITY,1.05987,-

0.00656657,0.0105553,0,0.000634921,0.000114683,1.07476,1,hours2016-12-06 09:00:01,6SZ6,2016-12-30 09:16:00,COVERED INTEREST PARITY,1.05987,-

0.00524212,0.00250525,0,0.000615079,0.000108036,1.06041,24,hours2016-12-06 09:00:01,6SH7,2017-03-30 09:16:00,99%

VAR,0,0,0,0.01,0.000654762,0.000117397,0.778388,1,days2016-12-06 09:00:01,6JZ6,2016-12-30 09:16:00,PURCHASING POWER

PARITY,0,0,0,0,0.000396825,1.94444e-005,0.00949376,20,daysOne further correction which must be made to all queries is to remove the use of the

SQL now() function to specify the current time and to replace it with a string containing the output of the a time parameter passed to the method, so that the row selected is not from a time later than the current point in the simulation.

Time Interval Calculation for Model PricingIn order to determine a number of years used to adjust interest rates by in the CIP formula and the number of days to pass to the value-at-risk pricing call, two estimator functions have been written. In both cases, the number of seconds elapsed between the current date and the maturity is calculated and then divided by the number of seconds per unit time (either day or year). In either case, the possibility of a leap year is ignored.

Term Calculation for Interest RatesOne problem will be that, given different purchase times for contracts, the term may not be the full three months, six months, etc that a contract purchased on the maturity date of a prior contract would have. However, the database is populated manually with rates and likely will not have rates for the same currency with maturities differing by only a

Excel Export securities

day. Thus, linear interpolation will be utilized with a granularity of three months. For example, a 5-month rate will be (2/3)*6-month-rate+(1/3)*3-month-rate.

Sovereign Data Tables PopulationIn order to obtain the correct pricing for covered interest parity arbitrage, up-to-date information about the foreign exchange spot rates and the individual country’s interest rate (likely LIBOR in that currency) must be inserted into the MySQL tables. Currently, manual DB administrative processes are relied on for such data insertion. Note that rates for many terms, including a term of zero (months or years) must be inserted into the database. The source for LIBOR rates will be the Intercontinental Exchange (ICE), whose quotes are one-two days delayed. In the case of terms for which no rate is available (such as nine-month), linear interpolation (e.g. between six and twelve months) will be utilized. The spot rate data was not simple to locate, as many major providers will provide inconsistent quotes, i.e. they will quote in USD for currencies such as the Euro and quote in the foreign currency for others such as the Swiss Franc (i.e. give the USD-CHF rate instead of the CHF-USD rate). Although it lacks the NZD rate, Barchart’s forex/all site was chosen for its bidirectional cross table.Command Line for Currency CSVThis module will take a fragment of the security_master spreadsheet restricted only to currency futures and will extract the code and price type in order to generate a new output CSV file. The input file schema (of which only two columns, one and eight, are used) is as follows.code,underlying,maturity,annual drift,annual volatility,daily drift,daily volatility,day 0 rate,algorithm,units per contract,degreeThe headers for the output file are as indicated below.date,code,maturity,price type,spot rate,IR1,IR2,threshold,mean,variance,modelPrice

Note that, if invalid codes (such as those for commodity futures) are passed in the security master file, the price for these instruments is output as approximately zero (10^(-100)). However, in the case of the commodity futures simulation, the application crashes, warranting more robust code in this case.Commodity Model Prices Command LineA sample command line used to generate the commodity prices model CSV file is below.CommPricesCSV commview "04-16-2016 09:00:01" "05-16-2016 09:00:01" sec_master_comm.csv comm_model_prices.csv 1 days

Resource Constraint IssuesDatabase connections and threads may induce resource usage problems in the non-managed-code C++ environment that the currency CSV file is generated in. If the result set, statement, and connection objects are not explicitly deleted, the application will crash due to an exhaustion of all available database connections. The market data module, used for the download of a current price to use as a base for the VaR price, instantiates multiple background threads (via the CURL library) for each date and code for which the VaR price is required. If a problem with the HTTP connection occurs, this functionality can hang indefinitely (a timeout should be added).

Sample Run of Currency Model Price GenerationCurrPricesCSV rivendell gandalf gandalf 2016-01-03 2016-03-07 sec_master_curr.csv curr_model_prices.csvInitially, problems with the interest rate, CIP price, and VaR price were observed. The interest rate values were wrong because of the incorrect interpolation of the maturity date between three month intervals. The CIP lines were printed as-below (one price was checked manually in Octave for accuracy).date,code,maturity,price type,spot rate,IR1,IR2,threshold,mean,variance,modelPrice

2016-01-03 00:00:00,6SH6,2016-03-30 00:00:00,COVERED INTEREST PARITY,1.02286,-0.00764052,0.00605644,0,0.000634921,0.000114683,1.019532016-01-03 00:00:00,6SM6,2016-06-30 09:16:00,COVERED INTEREST PARITY,1.02286,-0.00709343,0.00850011,0,0.000615079,0.000108036,1.015062016-01-03 00:00:00,6SU6,2016-09-30 00:00:00,99% VAR,1.02286,-0.00709343,0.00850011,0.01,0.000654762,0.000117397,0.595979…2016-03-07 00:00:00,6SH6,2016-03-30 00:00:00,COVERED INTEREST PARITY,1.02286,-0.00770785,0.00433318,0.01,0.000634921,0.000114683,1.022092016-03-07 00:00:00,6SM6,2016-06-30 09:16:00,COVERED INTEREST PARITY,1.02286,-0.0074876,0.00680875,0.01,0.000615079,0.000108036,1.018252016-03-07 00:00:00,6SU6,2016-09-30 00:00:00,99% VAR,1.02286,-0.0074876,0.00680875,0.01,0.000654762,0.000117397,0.64923The 99% VaR rate was also incorrect initially due to the current price’s being set to 0. However, this pricing was valid, as the security, 6SU6, did not trade on the previous business day and thus had an empty “last price” field on the CME Group’s site. This problem is being corrected by utilizing the “previous settle” price from the CME whenever no price is available. Note that the HTML element to search on is “<code>_priorSettle”. If the prior settle price is also 0, then in fact a zero price will be used, pending implementation of a “default” rate for the underlying currency pair. Upon correcting the lack of a price for the September CHF contract (so that a prior settle rate of about 1.0363 was input), the VaR was a negative rate, which is both impractical and an incorrect calculation. This was due to an incorrect variance input into the pricing algorithm. After amending this issue, the correct value-at-risk price of about .64 (loss of about .38) was obtained (inverse CDF value for the standard normal distribution was computed to be 2.32, where 2.33 is the usual value). The complete output file for the currency futures is below.date,code,maturity,price type,spot rate,IR1,IR2,threshold,mean,variance,modelPrice2016-02-13 16:48:28,6SH6,2016-03-30 00:00:00,COVERED INTEREST PARITY,1.02286,-0.00768439,0.00493362,0,0.000634921,0.000114683,1.021262016-02-13 16:48:28,6SM6,2016-06-30 09:16:00,COVERED INTEREST PARITY,1.02286,-0.00735026,0.00739808,0,0.000615079,0.000108036,1.017192016-02-13 16:48:28,6SU6,2016-09-30 00:00:00,99% VAR,1.02286,-0.00735026,0.00739808,0.01,0.000654762,0.000117397,0.641696 Problem with End Date of Commodity Price CSV OutputStrangely, regardless of whether the simulation runs with future dates (end in February 2017) or past dates (ends in February 2016, run time of July, 2016), the final date for which a price is output is January 27, despite the fact that February 1 falls on a weekday in both years, and the currency program ran for all days through 2/1. Interestingly, the currency program seems to be the one which was implemented incorrectly, in this case. The commodity futures CSV program was started with a deltaT parameter of 20 days, meaning that time steps were in 20-day increments, with the last two dates being 1/7 and 1/27. The currency futures program added one day to the current date indiscriminantly, instead of adding deltaT days.

Merge of Currency and Commodity Price FilesA new Java module will read the output files of the commodity and currency modules, combine them in a single data structure, and write them back to a common CSV file to be imported into the multiasset_sim spreadsheet. The currency and commodity price information will be read into separate hash tables mapping the (code,date) pair to a PriceInfo object containing the spot price, maturity, interest rates, etc. in addition to the model price. The final file’s output lines will be compiled by extracting all codes for a

given date from one of the tables in the order specified by the securities master file (same order for each date).In order to improve the clarity of the application, the date formats of the output files for the separate commodity and currency CSV modules were standardized to be “yyyy-MM-dd HH:mm:ss” (the commodity format had been “yyyy-MM-dd” originally).Note that the code to parse the input files must expect the file to end with a blank line, due to the line feed after the last line. The usage application is below, and the output from a sample run follows.java MergeCSV /?MergeCSV <startDate> <endDate> <codeOrder> <commodityCSV> <currencyCSV> <outFile>startDate: yyyy-mm-dd HH:mm:ssendDate: yyyy-mm-dd HH:mm:ssNote that the training vectors for agricultural products are out-of-date and use the old cents pricing. Thus, the model prices for soybeans, corn, wheat, and sugar are incorrect. This can be corrected by re-training the logistic regression and Naïve Bayes models for these products (in this case, only soybeans are traded) and re-generating the commodities CSV file (and subsequently the merged CSV file).Fragments of the merged model prices file for commodities and currencies are below.date,code,spotComm,maturity,ir1,ir2,spotFX,mean,variance,modelPr2016-01-03 00:00:00,GCG6,1060.3,2016-02-29 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,1550.02016-01-03 00:00:00,GCJ6,1060.3,2016-04-30 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,1225.390625…2016-03-07 00:00:00,6SH6,-1.0,2016-03-30 00:00:00,-0.00770785,0.00433318,1.02286,6.34921E-4,1.14683E-4,0.01,1.022092016-03-07 00:00:00,6SM6,-1.0,2016-06-30 09:16:00,-0.0074876,0.00680875,1.02286,6.15079E-4,1.08036E-4,0.01,1.018252016-03-07 00:00:00,6SU6,-1.0,2016-09-30 00:00:00,-0.0074876,0.00680875,1.02286,6.54762E-4,1.17397E-4,0.01,0.64923Updates to CSV File FormatIn order to ensure exact compatibility between the file output by MergeCSV.java and the model_prices sheet in Excel, the following changes were made.

1. The spot column in the commodity futures CSV generation application was moved to the fifth position, following maturity (3rd) and price type (4th). A similar change was made to the merge application’s output.

2. The spotComm and spotFX distinction was eliminated from the combined CSV.3. The price type field was added to the commodity and merged CSV files.

Integrated Portfolio Performance SimulationIn order to determine the value-add of the machine learning and arbitrage algorithms, the trading profit should be computed for multiple portfolios using all algorithm permutations over varying time intervals (for which historical prices may or may not be available). After generating the securities master and model prices, the same simulation in Excel should be run via macro about 100 times and the average computed for the profit (Monte Carlo simulation). In addition, the risk of the portfolio (volatility) should be computed (currently, the volatility parameters for each contract are simply arbitrary hard-codings, but these should be fetched from the CME and ICE). The drift and volatility should be computed from historical data (drift) and the implied volatility of current options in the market (volatility, likely obtained by an inversion of the Black-Scholes function on the market price of the option). This can be done via an approach like the “fsolve” function of Matlab/Octave, which uses a Powell Dogleg algorithm to iteratively find the best volatility. Another option would be a stochastic volatility model

such as GARCH, a method designed to fit market prices such as the IVF model, or the computation of the historical volatility for returns on the futures contracts.Calling C# and C++ Model Price Executables from Visual BasicAssuming that the securities master sheet has already been output to a CSV file (handled by another new function), the shell function in VBA can be invoked to call the model executables. The trading_simulation sheet will contain settings for all parameters which had been passed in Windows Command Prompt scripts to the CurrPricesCSV, CommPricesCSV, and “java MergePrices” executables in the top two rows. Such parameters include DB DSN, DB user, DB password, start date, end date, delta t number, delta t units, security master file, commodity prices EXE path, currency prices EXE path, commodity CSV path, and currency CSV path. Note that, prior to invoking the CurrPricesCSV executable, the desired Curl, gnustep, and gtkmm libraries’ binary directories must be ahead of paths to any other versions of these libraries. The output of the Java merge module is the CSV file which will be copied into the workbook sheet automatically. After the model price load, the Brownian Motion trading and Monte Carlo simulation can be activated, thus enabling the entire process to be run with a single mouse click.The following steps would be followed to run the simulation.Besides code, underlying, algorithm, drift, volatility, maturity, day 0 rate, etc must be incorporated. The model prices CSV file output in the final merge step should follow the same contract order as the securities master sheet for each day. Thus, each line of the CSV file will be read into a ModelPriceInfo data structure and then written back to the spreadsheet. The ModelPriceInfo class will closely resemble the SecInfo class, but it will contain additional fields such as IR1, IR2, and spot price.

1. Rename the securities_master, curr_model_prices, comm_model_prices, and model_prices csv files in the paths pointed to in the multiasset_sim workbook.

2. Check that the securities_master sheet contains active contracts, changing them as needed.

3. Call the resetSheets subroutine to set up the control table codes and reset the range selections.

4. Call the loadModelPrices subroutine.5. Verify that the four CSV files were created and are valid.6. Verify the model_prices sheet in the workbook.

One problem discovered was that a call to the exe will not generate an exception, if the command-line parameters are incorrect. Thus, it is useful to keep the command prompt shell windows for the calls open and to set the wait parameter to true, causing the macro to wait for the exe to complete before resuming execution of the VBA. However, since no wait parameter exists in the Excel version of Shell (it is only in the full Visual Basic interpreter), the Windows Script Shell, WshShell (WScript.Shell), must be used. This object’s run method does allow a wait parameter to be passed. Note that a reference to the “Windows Scripting Host” COM module needed to be added. In addition, the path environment variable for the process needed to be modified using the Environment field of the WshShell object to prepend the gtkmm, curl, and gnustep directories.These adjustments enabled the CurrPricesCSV executable to be invoked correctly, but a malformed Security_Master.csv file caused an error to ensue. A screen shot of the CurrPricesCSV executables’s being invoked from the macro is below.

Note that, in order to make the parameters uniform across all three external executables, the start and end date format for the commodity futures pricing program must be “yyyy-MM-dd HH:mm:ss” (as opposed to “MM-dd-yyyy HH:mm:ss” originally implemented).VerificationThis functionality, with the exception of the reset of the model sheet has been verified. Note that the loadModelPrices subroutine will be invoked at the end of the resetSheets subroutine. After this reset occurs, the control table must be repopulated. Note that loadModelPrices was also initially called in runTradingSimBrownian, but this invocation will be removed.The simulation was verified to run to completion using this new model prices sheet. The Monte Carlo simulation also ran and showed updates for the price and some contracts’ open/close times. However, the Monte-Carlo-specific statistics did not print correctly, as per-simulation profit was logged as zero for all cases. This can be ameliorated by writing the total net profit after the final contract’s summary data at the completion of the runTradingSimBrownian subroutine. (Before calling this subroutine, the nSecs and summaryStartRow variables must be set by the loadRuntimeParams subroutine.) This problem was also verified to have been solved In addition, the closing behavior for at least one contract, ZSN7, was observed to be incorrect. This was remedied by changing the type of a difference from Integer to Double. Another problem was the failure for any trading or tick data logging for GCM7, June 2017 gold. The lack of logging of ticks to the database is due to the fact that no commodity ticks are logged to the currency database (they are in the commodity database). The failure to trade this code was due to the initial price setting of 900, which is too close to the model’s estimate of 850 (less than 10%). The summary data and partial Monte Carlo output after all bug fixes is below.

Code Open Date Close Date Open Price Close Price Profit

Transaction Costs

Maximal 1-day VaR

Maximal 10-day VaR

Net Profit

GCZ7

{2016/12/06 09:01:00, 2016/12/08 09:01:00,

{2016/12/07 09:01:00, 2016/12/09 09:01:00,

{1102.8, 1102.73941803081, 1103.1444291

{1102.54658055151, 1103.13006343638,

-1176.

37111.49

924343.50

1113735

.36

-1287.86

675

2016/12/10 09:01:00, 2016/12/12 09:01:00, 2016/12/14 09:01:00, 2016/12/16 09:01:00, 2016/12/18 09:01:00, 2016/12/20 09:01:00, 2016/12/22 09:01:00, 2016/12/24 09:01:00, 2016/12/26 09:01:00, 2016/12/28 09:01:00, 2016/12/30 09:01:00, 2017/01/01 09:01:00, 2017/01/03 09:01:00, 2017/01/05 09:01:00}

2016/12/11 09:01:00, 2016/12/13 09:01:00, 2016/12/15 09:01:00, 2016/12/17 09:01:00, 2016/12/19 09:01:00, 2016/12/21 09:01:00, 2016/12/23 09:01:00, 2016/12/25 09:01:00, 2016/12/27 09:01:00, 2016/12/29 09:01:00, 2016/12/31 09:01:00, 2017/01/02 09:01:00, 2017/01/04 09:01:00, 2017/01/06 09:01:00}

3246, 1104.30100962517, 1105.12834872375, 1105.74228586938, 1107.023779021, 1108.09212345684, 1108.68365506728, 1109.89598675067, 1111.4272816412, 1112.34589520692, 1112.8289088574, 1113.48976550721, 1113.79993088811, 1114.99155629871}

1103.4458605738, 1104.80354118861, 1105.58698888074, 1106.58170493032, 1107.75701827454, 1108.61284489548, 1109.3489531549, 1110.45166062138, 1111.80922428176, 1112.65204112643, 1112.98147601555, 1113.62940827401, 1114.1386408553, 1114.84020499006}

GCK7

{2016/12/06 09:01:00, 2016/12/08 09:01:00, 2016/12/10 09:01:00, 2016/12/12 09:01:00, 2016/12/14 09:01:00, 2016/12/16 09:01:00, 2016/12/18 09:01:00, 2016/12/20 09:01:00, 2016/12/22 09:01:00, 2016/12/24 09:01:00, 2016/12/26 09:01:00, 2016/12/28 09:01:00, 2016/12/30 09:01:00, 2017/01/01 09:01:00, 2017/01/03 09:01:00, 2017/01/06 09:01:00}

{2016/12/07 09:01:00, 2016/12/09 09:01:00, 2016/12/11 09:01:00, 2016/12/13 09:01:00, 2016/12/15 09:01:00, 2016/12/17 09:01:00, 2016/12/19 09:01:00, 2016/12/21 09:01:00, 2016/12/23 09:01:00, 2016/12/25 09:01:00, 2016/12/27 09:01:00, 2016/12/29 09:01:00, 2016/12/31 09:01:00, 2017/01/02 09:01:00, 2017/01/05 09:01:00}

{1103.9, 1104.58159750252, 1105.24738212676, 1107.21082999792, 1107.80141313814, 1108.30694948201, 1109.39523317682, 1110.27778255024, 1111.47086908531, 1112.80836152409, 1113.36039999386, 1114.03678097149, 1115.02313116599, 1116.18155478129, 1116.75902195295, 1118.30862634979}

{1104.34213796066, 1104.95133429189, 1106.19451544265, 1107.56797327305, 1108.14629642568, 1108.98849583529, 1109.97419665426, 1110.95463083854, 1111.95404585186, 1113.36785989897, 1114.22523667437, 1114.3426412749, 1115.78946613038, 1116.69257044997, 1117.79032583629}

-1784.

08111.83

094201.15

75813285

.23

-1895.91

474

GCM7

{2016/12/06 09:01:00, 2016/12/08 09:01:00, 2016/12/10 09:01:00,

{2016/12/07 09:01:00, 2016/12/09 09:01:00, 2016/12/11 09:01:00,

{1020, 1020.63293978795, 1022.11489426236, 1023.0411563

{1020.72429549701, 1021.51325420199, 1022.77747506808,

-1671.

17103.46

633886.92

69912291

.54

-1774.63

706

2016/12/12 09:01:00, 2016/12/14 09:01:00, 2016/12/16 09:01:00, 2016/12/18 09:01:00, 2016/12/20 09:01:00, 2016/12/22 09:01:00, 2016/12/24 09:01:00, 2016/12/26 09:01:00, 2016/12/28 09:01:00, 2016/12/30 09:01:00, 2017/01/01 09:01:00, 2017/01/03 09:01:00, 2017/01/05 09:01:00}

2016/12/13 09:01:00, 2016/12/15 09:01:00, 2016/12/17 09:01:00, 2016/12/19 09:01:00, 2016/12/21 09:01:00, 2016/12/23 09:01:00, 2016/12/25 09:01:00, 2016/12/27 09:01:00, 2016/12/29 09:01:00, 2016/12/31 09:01:00, 2017/01/02 09:01:00, 2017/01/04 09:01:00, 2017/01/06 09:01:00}

0416, 1023.95305830198, 1024.31190390923, 1025.64031679455, 1026.52731552836, 1027.71777958567, 1029.1541765012, 1029.94888861687, 1030.49382965826, 1031.6907543631, 1033.17188130168, 1033.80620736891, 1034.66339923518}

1023.54832394162, 1024.08607195781, 1024.9632997959, 1026.02924067643, 1027.17465606102, 1028.27022050209, 1029.74936354703, 1030.06819895072, 1031.33245611435, 1032.02748973837, 1033.55385252091, 1034.36604193914, 1035.04011463009}

B052017

{2016/12/06 09:01:00, 2016/12/08 09:01:00, 2016/12/10 09:01:00, 2016/12/12 09:01:00, 2016/12/14 09:01:00, 2016/12/16 09:01:00, 2016/12/18 09:01:00, 2016/12/20 09:01:00, 2016/12/22 09:01:00, 2016/12/24 09:01:00, 2016/12/26 09:01:00, 2016/12/28 09:01:00, 2016/12/30 09:01:00, 2017/01/01 09:01:00, 2017/01/03 09:01:00, 2017/01/05 09:01:00}

{2016/12/07 09:01:00, 2016/12/09 09:01:00, 2016/12/11 09:01:00, 2016/12/13 09:01:00, 2016/12/15 09:01:00, 2016/12/17 09:01:00, 2016/12/19 09:01:00, 2016/12/21 09:01:00, 2016/12/23 09:01:00, 2016/12/25 09:01:00, 2016/12/27 09:01:00, 2016/12/29 09:01:00, 2016/12/31 09:01:00, 2017/01/02 09:01:00, 2017/01/04 09:01:00, 2017/01/06 09:01:00}

{34.69, 34.6612822482212, 34.6125936084994, 34.5743061436993, 34.5365404193255, 34.5200961288267, 34.4607196189798, 34.4279259805527, 34.3655271237233, 34.327077502227, 34.2793264478249, 34.2363615495887, 34.1841310828296, 34.1243820935138, 34.0812882901733, 34.0599852046802}

{34.673377757293, 34.6258645876593, 34.5988979845986, 34.5494390718587, 34.5249821918235, 34.4970808284388, 34.4394157136932, 34.3879382325929, 34.3409275353738, 34.3030247590762, 34.2631254535539, 34.2071986507228, 34.1593267938815, 34.1033616837089, 34.0647705825817, 34.0367092550237}

-732.2

05 34.691384.36

94377.

759

-766.894

722B062017

{2016/12/06 09:01:00, 2016/12/08 09:01:00, 2016/12/10 09:01:00, 2016/12/12 09:01:00,

{2016/12/07 09:01:00, 2016/12/09 09:01:00, 2016/12/11 09:01:00, 2016/12/13 09:01:00,

{37.44, 37.3942993370796, 37.3510620382897, 37.3333753617072, 37.278595410

{37.4107002450227, 37.383585178085, 37.3363609633372, 37.3100236074939,

-598.4

56

37.44 1497.08426

4734.196

-635.896

309

2016/12/14 09:01:00, 2016/12/16 09:01:00, 2016/12/18 09:01:00, 2016/12/20 09:01:00, 2016/12/22 09:01:00, 2016/12/24 09:01:00, 2016/12/26 09:01:00, 2016/12/28 09:01:00, 2016/12/30 09:01:00, 2017/01/01 09:01:00, 2017/01/04 09:01:00, 2017/01/06 09:01:00}

2016/12/15 09:01:00, 2016/12/17 09:01:00, 2016/12/19 09:01:00, 2016/12/21 09:01:00, 2016/12/23 09:01:00, 2016/12/25 09:01:00, 2016/12/27 09:01:00, 2016/12/29 09:01:00, 2016/12/31 09:01:00, 2017/01/03 09:01:00, 2017/01/05 09:01:00}

2335, 37.232060727741, 37.1999406101894, 37.1755788158903, 37.1480821417272, 37.0873953681428, 37.0597404412511, 37.0242839614406, 36.9799129922041, 36.9409239905764, 36.8726936959795, 36.8273639926708}

37.2650585920499, 37.2186897500327, 37.1849764332472, 37.1676851535485, 37.12043353816, 37.0705503623212, 37.0327692076093, 36.9968724858791, 36.9628500961772, 36.8995819811821, 36.8585791438839}

B072017

{2016/12/06 09:01:00}

{2016/12/07 09:01:00} {39.36}

{39.3941715398595}

68.34308 39.36

1609.80112

5090.638

28.9830797

ZSN7

{2016/12/06 09:01:00, 2016/12/09 09:01:00, 2016/12/11 09:01:00, 2016/12/14 09:01:00, 2016/12/16 09:01:00, 2016/12/18 09:01:00, 2016/12/20 09:01:00, 2016/12/22 09:01:00, 2016/12/24 09:01:00, 2016/12/26 09:01:00, 2016/12/28 09:01:00, 2016/12/31 09:01:00, 2017/01/03 09:01:00, 2017/01/05 09:01:00}

{2016/12/08 09:01:00, 2016/12/10 09:01:00, 2016/12/13 09:01:00, 2016/12/15 09:01:00, 2016/12/17 09:01:00, 2016/12/19 09:01:00, 2016/12/21 09:01:00, 2016/12/23 09:01:00, 2016/12/25 09:01:00, 2016/12/27 09:01:00, 2016/12/30 09:01:00, 2017/01/02 09:01:00, 2017/01/04 09:01:00, 2017/01/06 09:01:00}

{8.676, 8.6638483049958, 8.65913117213162, 8.65083257596719, 8.64457860261281, 8.63652645088828, 8.62503481396426, 8.61604416048045, 8.60301166448292, 8.59539557206388, 8.58556191600815, 8.58051508879842, 8.5757159575731, 8.56796995393707}

{8.66844443449662, 8.66064465992475, 8.65252388618943, 8.64865054583146, 8.64045447986228, 8.6342685682421, 8.62001796012548, 8.61004409086706, 8.59859424223493, 8.59043202214212, 8.58149890606493, 8.57597914103836, 8.57115415472358, 8.56288808961681}

645.7105 43.38

1875.71701

5931.538

602.330525

ZSQ7 {2016/12/06 09:01:00, 2016/12/08 09:01:00, 2016/12/10 09:01:00, 2016/12/12 09:01:00, 2016/12/14 09:01:00, 2016/12/16 09:01:00,

{2016/12/07 09:01:00, 2016/12/09 09:01:00, 2016/12/11 09:01:00, 2016/12/13 09:01:00, 2016/12/15 09:01:00, 2016/12/17 09:01:00,

{8.706, 8.69679153266319, 8.69575964014394, 8.68642010655866, 8.67631746213585, 8.66097686628351, 8.6490020378

{8.70313663193553, 8.69522594201889, 8.68964068179067, 8.67766591839511, 8.6666690439193, 8.65534911285741,

808.6514

43.53 1747.50997

5526.112

765.121365

2016/12/18 09:01:00, 2016/12/20 09:01:00, 2016/12/22 09:01:00, 2016/12/24 09:01:00, 2016/12/26 09:01:00, 2016/12/28 09:01:00, 2016/12/30 09:01:00, 2017/01/01 09:01:00, 2017/01/03 09:01:00, 2017/01/05 09:01:00}

2016/12/19 09:01:00, 2016/12/21 09:01:00, 2016/12/23 09:01:00, 2016/12/25 09:01:00, 2016/12/27 09:01:00, 2016/12/29 09:01:00, 2016/12/31 09:01:00, 2017/01/02 09:01:00, 2017/01/04 09:01:00, 2017/01/06 09:01:00}

8124, 8.64280175979925, 8.6331227904573, 8.62636612827969, 8.61702876892721, 8.61334710385991, 8.61274985601777, 8.60418757907037, 8.59796912728709, 8.58814538632611}

8.64802936020327, 8.63475791228145, 8.62574605109992, 8.62204905521018, 8.61378123503528, 8.61051882044834, 8.60995622302405, 8.60102555512075, 8.59235689407559, 8.58021257176644}

ZSU7

{2016/12/06 09:01:00, 2016/12/08 09:01:00, 2016/12/10 09:01:00, 2016/12/12 09:01:00, 2016/12/14 09:01:00, 2016/12/16 09:01:00, 2016/12/18 09:01:00, 2016/12/20 09:01:00, 2016/12/22 09:01:00, 2016/12/24 09:01:00, 2016/12/26 09:01:00, 2016/12/28 09:01:00, 2016/12/30 09:01:00, 2017/01/02 09:01:00, 2017/01/06 09:01:00}

{2016/12/07 09:01:00, 2016/12/09 09:01:00, 2016/12/11 09:01:00, 2016/12/13 09:01:00, 2016/12/15 09:01:00, 2016/12/17 09:01:00, 2016/12/19 09:01:00, 2016/12/21 09:01:00, 2016/12/23 09:01:00, 2016/12/25 09:01:00, 2016/12/27 09:01:00, 2016/12/29 09:01:00, 2017/01/01 09:01:00, 2017/01/05 09:01:00}

{8.77, 8.76362210280963, 8.75172888067042, 8.75208250598825, 8.74215412041625, 8.72997329743778, 8.72144179109784, 8.71440933957253, 8.7098934592291, 8.70327610284554, 8.69301442862645, 8.68118785534401, 8.66674188231989, 8.66768294977861, 8.66467048510976}

{8.76518552557764, 8.75848787949012, 8.74684783218558, 8.74549527858761, 8.73602877112194, 8.72560843337191, 8.71965290694172, 8.71097228619782, 8.70203779684152, 8.69929737257331, 8.68819955863075, 8.67228423514003, 8.67095800435235, 8.66433586473424}

618.1697 43.85

1890.81919

5979.295

574.319704

6SU7 {2016/12/06 09:01:00, 2016/12/08 09:01:00, 2016/12/10 09:01:00, 2016/12/12 09:01:00, 2016/12/14 09:01:00, 2016/12/17 09:01:00, 2016/12/19 09:01:00, 2016/12/21 09:01:00,

{2016/12/07 09:01:00, 2016/12/09 09:01:00, 2016/12/11 09:01:00, 2016/12/13 09:01:00, 2016/12/16 09:01:00, 2016/12/18 09:01:00, 2016/12/20 09:01:00, 2016/12/22 09:01:00,

{1.0055, 1.00661977357818, 1.00859073319973, 1.00950665913459, 1.010442468253, 1.01170260760862, 1.01344386904786, 1.01499241853945, 1.0161183148

{1.00613617140779, 1.00725191582951, 1.00936851766562, 1.0103991845105, 1.01033264244859, 1.012274505296, 1.01447605406939, 1.01574709415391,

2244.009

128.0472

6552.65409

20721.31

2115.96214

2016/12/23 09:01:00, 2016/12/25 09:01:00, 2016/12/27 09:01:00, 2016/12/29 09:01:00, 2016/12/31 09:01:00, 2017/01/02 09:01:00, 2017/01/04 09:01:00, 2017/01/06 09:01:00}

2016/12/24 09:01:00, 2016/12/26 09:01:00, 2016/12/28 09:01:00, 2016/12/30 09:01:00, 2017/01/01 09:01:00, 2017/01/03 09:01:00, 2017/01/05 09:01:00}

3296, 1.01764973884435, 1.01920053669888, 1.01979284030943, 1.02103884115847, 1.02187902772602, 1.02279146091153, 1.02437738534206}

1.0166148986067, 1.01801151429317, 1.01932042910716, 1.02052305690194, 1.02152707831953, 1.02245482001321, 1.02380744447649}

6SZ7

{2016/12/06 09:01:00, 2016/12/08 09:01:00, 2016/12/10 09:01:00, 2016/12/12 09:01:00, 2016/12/14 09:01:00, 2016/12/17 09:01:00, 2016/12/19 09:01:00, 2016/12/21 09:01:00, 2016/12/23 09:01:00, 2016/12/25 09:01:00, 2016/12/27 09:01:00, 2016/12/29 09:01:00, 2016/12/31 09:01:00, 2017/01/02 09:01:00, 2017/01/04 09:01:00, 2017/01/06 09:01:00}

{2016/12/07 09:01:00, 2016/12/09 09:01:00, 2016/12/11 09:01:00, 2016/12/13 09:01:00, 2016/12/16 09:01:00, 2016/12/18 09:01:00, 2016/12/20 09:01:00, 2016/12/22 09:01:00, 2016/12/24 09:01:00, 2016/12/26 09:01:00, 2016/12/28 09:01:00, 2016/12/30 09:01:00, 2017/01/01 09:01:00, 2017/01/03 09:01:00, 2017/01/05 09:01:00}

{1.014, 1.015207578411, 1.01689821542475, 1.0180684148349, 1.01881650176201, 1.02040963916592, 1.02163827980568, 1.02216176304006, 1.02418506553403, 1.02511042361063, 1.0265334884764, 1.02818696765889, 1.02951939719901, 1.03108538856248, 1.03264959777209, 1.0339452613145}

{1.01463423965793, 1.01618228944146, 1.01757648872154, 1.01823592710017, 1.01959139076486, 1.02116483014126, 1.02181379711376, 1.02324230381754, 1.02462430015352, 1.0259342617987, 1.02723235737307, 1.02889180988434, 1.03054349896413, 1.03171377246316, 1.03311488909889}

2506.359

129.2432

6419.03021

20298.76

2377.11565

6SH8 {2016/12/06 09:01:00, 2016/12/08 09:01:00, 2016/12/10 09:01:00, 2016/12/12 09:01:00, 2016/12/14 09:01:00, 2016/12/16 09:01:00, 2016/12/18 09:01:00, 2016/12/20 09:01:00, 2016/12/22 09:01:00,

{2016/12/07 09:01:00, 2016/12/09 09:01:00, 2016/12/11 09:01:00, 2016/12/13 09:01:00, 2016/12/15 09:01:00, 2016/12/17 09:01:00, 2016/12/19 09:01:00, 2016/12/21 09:01:00, 2016/12/23 09:01:00,

{1.0198, 1.02165069541265, 1.02238226834546, 1.02344906596225, 1.02545707926334, 1.02749662953498, 1.02825595202218, 1.02917878106868, 1.03049563881767, 1.0323274907

{1.02073790174615, 1.02208693494979, 1.02308204212913, 1.02453543477582, 1.02614483140573, 1.02799797185052, 1.02918252737529, 1.0296264640433, 1.03114234967125,

-2871.

3

129.9838

6733.22961

21292.34

-3001.28

411

2016/12/24 09:01:00, 2016/12/26 09:01:00, 2016/12/28 09:01:00, 2016/12/30 09:01:00, 2017/01/01 09:01:00, 2017/01/03 09:01:00, 2017/01/05 09:01:00}

2016/12/25 09:01:00, 2016/12/27 09:01:00, 2016/12/29 09:01:00, 2016/12/31 09:01:00, 2017/01/02 09:01:00, 2017/01/04 09:01:00, 2017/01/06 09:01:00}

8013, 1.03334816659367, 1.03435575871632, 1.03574185549729, 1.03740538353709, 1.03854939333464, 1.03987022353999}

1.03323061445129, 1.0338272921043, 1.03516876207316, 1.03653632427243, 1.03794020992804, 1.03953651304529, 1.04047340992974}

6JZ7{2016/12/06 09:01:00}

{2016/12/07 09:01:00} {0.009787}

{9.79055902680392E-03}

88.97567

122.3375

2610.96599

8256.599

-33.3618

299-

2932.02306

…trial profit

1 -2342.062 -2227.153 -360.0914 -1992.565 -1381.146 -2724.727 -2760.748 -23589 -3235.2

10 -1990.9495 -2405.8596 -2233.4597 -3314.9398 -2269.4699 -2518.7

100 -2932.02Avg P&L -2432.04

New Securities Master Read/Write FunctionalityIn order to automatically copy the trader-specified securities master file into a CSV input for the pricing models, the readSecMaster function must be modified to include several fields. The logic to write the security_master.csv file was created for this new functionality, and it actually creates three CSV files: the two instrument-specific CSV files for commodity and currency futures and one aggregate file which mirrors the securities_master Excel sheet. The two new securities master files are illustrated below.Currenciescode,underlying,maturity,annual drift,annual volatility,daily drift,daily volatility,day 0 rate,algorithm,units per contract,degree,holding period(currently unused),holding period units(currently unused)6SU7,Swiss Francs,2017-09-30 09:16:00,0.16,0.17,6.34920634920635E-04,1.07089934019281E-02,1.0055,COVERED INTEREST PARITY,125000,1,1,hours

6SZ7,Swiss Francs,2017-12-31 09:16:00,0.155,0.165,6.15079365079365E-04,1.03940230077537E-02,1.014,COVERED INTEREST PARITY,125000,1,24,hours6SH8,Swiss Francs,2018-03-31 09:16:00,0.165,0.172,6.54761904761905E-04,1.08349815595978E-02,1.0198,99% VAR,125000,1,1,days6JZ7,Japanese Yen,2017-12-31 09:16:00,0.1,0.07,3.96825396825397E-04,4.40958551844098E-03,0.009787,PURCHASING POWER PARITY,12500000,1,20,daysCommoditiescode,underlying,maturity,annual drift,annual volatility,daily drift,daily volatility,day 0 rate,algorithm,units per contract,degree,holding period(currently unused),holding period units(currently unused)GCZ7,Gold,2017-12-30 09:16:00,0.1,0.13,0.000396825,0.00818923,1102.8,LOGISTIC REGRESSION,100,1,1,hoursGCK7,Gold,2017-05-30 09:16:00,0.11,0.125,0.000436508,0.00787426,1103.9,NAIVE BAYES,100,1,2,hoursGCM7,Gold,2017-06-30 09:16:00,0.11,0.125,0.000436508,0.00787426,900,NAIVE BAYES,100,1,20,daysB052017,Brent Oil,2017-05-30 09:16:00,-0.15,0.14,-0.000595238,0.008819171,34.69,NAIVE BAYES,1000,1,2,hoursB062017,Brent Oil,2017-06-30 09:16:00,-0.14,0.14,-0.000555556,0.008819171,37.44,NAIVE BAYES,1000,1,1,hoursB072017,Brent Oil,2017-07-30 09:16:00,0.16,0.135,0.000634921,0.008504201,39.36,NAIVE BAYES,1000,1,1,hoursZSN7,Soybeans,2017-07-30 09:16:00,-0.1,0.15,-0.000396825,0.009449112,8.676,NAIVE BAYES,5000,1,1,daysZSQ7,Soybeans,2017-08-30 09:16:00,-0.12,0.14,-0.00047619,0.008819171,8.706,NAIVE BAYES,5000,1,1,hoursZSU7,Soybeans,2017-09-30 09:16:00,-0.115,0.15,-0.000456349,0.009449112,8.77,NAIVE BAYES,5000,1,1,daysWeight Settings for Higher Classifier IDsAn exception occurred in the commodity futures logistic regression price computation due to the lack of weights. This was due to the fact that the database was not populated with weights for any classifiers beyond the first three, but the CommPricesCSV executable calls the Algorithm class constructor with the number of classifiers set to ten. This variable should be parameterized within the CommPricesCSV command line and in the Excel runtime parameters. The CommPricesCSV executable will then construct the Algorithm object using the parameter in the Excel sheet, and pass the value of false for the nClassifiersUnset parameter to the computePrice method.Code File PathThere is some disconnect between the Excel VBA simulation and the Java merge program, in that the Visual Basic is printing the entire security master sheet in CSV form, but the Java program needs only the code field from each line to validate the order of contracts. Thus, the VBA will pass the security master’s path as the codeFile parameter to MergeCSV.Reset of Model SheetNote that the “reset” subroutine should also include new functionality to delete the data from and print the headers for the “model_prices” worksheet. The loadRuntimeParams method will be called in the parent resetSheets subroutine to load the necessary sheet name and row number global variables. This code has also been successfully tested.Before:

maturity price typespot rate

IR1

IR2

threshold

mean

variance

model price

holding period

holding period units

12/31/2017

LOGISTIC REGRESSION

1343.51 0 0 0 0 0 950 1 hours

5/31/2017 NAIVE BAYES

1343.51 0 0 0 0 0 850 2 hours

6/30/2017 NAIVE BAYES

1343.51 0 0 0 0 0 850 20 days

After:date

code

maturity

price type

spot rate

IR1

IR2

threshold

mean

variance

model price

holding period

holding period units

Sample OutputThe final model_prices.csv excerpt for a test case is:date,code, maturity,price type, spot, ir1,ir2,threshold,mean,variance,modelPr,holdingPeriod,hpUnits2016-12-06 09:01:00,GCZ7,2017-12-31 00:00:00,LOGISTIC REGRESSION,1075.8,0.0,0.0,0.0,0.0,0.0,950.0,1,hours2016-12-06 09:01:00,GCK7,2017-05-31 00:00:00,NAIVE BAYES,1343.51,0.0,0.0,0.0,0.0,0.0,850.0,2,hours2016-12-06 09:01:00,GCM7,2017-06-30 00:00:00,NAIVE BAYES,1075.8,0.0,0.0,0.0,0.0,0.0,850.0,20,days2016-12-06 09:01:00,B052017,2017-05-31 00:00:00,NAIVE BAYES,44.68,0.0,0.0,0.0,0.0,0.0,43.75,2,hours2016-12-06 09:01:00,B062017,2017-06-30 00:00:00,NAIVE BAYES,44.68,0.0,0.0,0.0,0.0,0.0,43.75,1,hours2016-12-06 09:01:00,B072017,2017-07-31 00:00:00,NAIVE BAYES,44.68,0.0,0.0,0.0,0.0,0.0,43.75,1,hours2016-12-06 09:01:00,ZSN7,2017-07-31 00:00:00,NAIVE BAYES,10.165,0.0,0.0,0.0,0.0,0.0,6.8125,1,days2016-12-06 09:01:00,ZSQ7,2017-08-31 00:00:00,NAIVE BAYES,10.165,0.0,0.0,0.0,0.0,0.0,6.8125,1,hours2016-12-06 09:01:00,ZSU7,2017-09-30 00:00:00,NAIVE BAYES,10.165,0.0,0.0,0.0,0.0,0.0,6.8125,1,days2016-12-06 09:01:00,6SU7,2017-09-30 09:16:00,COVERED INTEREST PARITY,1.14975,-0.00656657,0.0105553,0.0,6.34921E-4,1.14683E-4,1.16591,1,hours2016-12-06 09:01:00,6SZ7,2017-12-30 09:16:00,COVERED INTEREST PARITY,1.14975,-0.26775,-0.254506,0.0,6.15079E-4,1.08036E-4,1.17246,24,hours2016-12-06 09:01:00,6SH8,2018-03-30 09:16:00,99% VAR,0.0,0.0,0.0,0.01,6.54762E-4,1.17397E-4,0.522028,1,days2016-12-06 09:01:00,6JZ7,2017-12-30 09:16:00,PURCHASING POWER PARITY,0.0,0.0,0.0,0.0,3.96825E-4,1.94444E-5,0.00983806,20,days2016-12-07 09:01:00,GCZ7,2017-12-31 00:00:00,LOGISTIC REGRESSION,1072.1,0.0,0.0,0.0,0.0,0.0,950.0,1,hours2016-12-07 09:01:00,GCK7,2017-05-31 00:00:00,NAIVE BAYES,1343.51,0.0,0.0,0.0,0.0,0.0,850.0,2,hours2016-12-07 09:01:00,GCM7,2017-06-30 00:00:00,NAIVE BAYES,1072.1,0.0,0.0,0.0,0.0,0.0,850.0,20,days…

This was read into the Excel sheet as:date code maturity price type

spot rate IR1 IR2

threshold

mean

variance

modelPrice

holding period

holding period units

12/6/2016 9:01

GCZ7

12/31/2017

LOGISTIC REGRESSION

1075.8 0 0 0 0 0 950 1 hours

12/6/2016 9:01

GCK7

5/31/2017 NAIVE BAYES

1343.51 0 0 0 0 0 850 2 hours

12/6/2016 9:01

GCM7

6/30/2017 NAIVE BAYES

1075.8 0 0 0 0 0 850 20 days

12/6/2016 9:01

B052017

5/31/2017 NAIVE BAYES

44.68 0 0 0 0 0 43.75 2 hours

12/6/2016 9:01

B062017

6/30/2017 NAIVE BAYES

44.68 0 0 0 0 0 43.75 1 hours

12/6/2016 9:01

B072017

7/31/2017 NAIVE BAYES

44.68 0 0 0 0 0 43.75 1 hours

12/6/2016 9:01 ZSN7

7/31/2017 NAIVE BAYES

10.165 0 0 0 0 0

6.8125 1 days

12/6/2016 9:01

ZSQ7

8/31/2017 NAIVE BAYES

10.165 0 0 0 0 0

6.8125 1 hours

12/6/2016 9:01 ZSU7

9/30/2017 NAIVE BAYES

10.165 0 0 0 0 0

6.8125 1 days

12/6/2016 9:01

6SU7

9/30/2017 9:16

COVERED INTEREST PARITY

1.14975

-0.00657

0.010555 0

0.000635

0.000115

1.16591 1 hours

12/6/2016 9:01 6SZ7

12/30/2017 9:16

COVERED INTEREST PARITY

1.14975

-0.26775

-0.25451 0

0.000615

0.000108

1.17246 24 hours

12/6/2016 9:01 6SH8

3/30/2018 9:16 99% VAR 0 0 0 0.01

0.000655

0.000117

0.522028 1 days

12/6/2016 9:01 6JZ7

12/30/2017 9:16

PURCHASING POWER PARITY 0 0 0 0

0.000397

1.94E-05

0.009838 20 days

12/7/2016 9:01

GCZ7

12/31/2017

LOGISTIC REGRESSION

1072.1 0 0 0 0 0 950 1 hours

12/7/2016 9:01

GCK7

5/31/2017 NAIVE BAYES

1343.51 0 0 0 0 0 850 2 hours

12/7/2016 9:01

GCM7

6/30/2017 NAIVE BAYES

1072.1 0 0 0 0 0 850 20 days

…

Tracking Portfolio VolatilityOne statistic missing from the initial simulation program is the Sharpe Ratio, which measures (mu-r)/sigma, where mu is the expected return of the portfolio, r is the risk-free rate, and sigma is the volatility. Given all portfolio daily returns, the volatility can be computed as follows.

√ 1n∑i=1n

¿¿¿

Note that the returns (as a percentage of the initial investment) must be tracked along with the profit/loss amount in order to compute volatility and the Sharpe Ratio.

Test of Two Month SimulationOnce the correct training vectors had been loaded into the database, the count for each underlying was reduced to about 100 and the training run in commodities to output the comm_model_prices.csv file. Then, after ensuring that the interest rates had been adequately set in the currency futures database, the curr_model_prices.csv file was generated. The MergeCSV Java class was used to generate a common model price file, hybrid_model_prices.csv, and this was copied into the multiasset_sim workbook. Then the following steps were carried out.

1. Clear the Brownian_daily_results and daily_trading results data2. Run the “runtradingsimbrownian” macro

One problem is that the simulation requires a manual copy of the first day’s rows from the security master into the Brownian_daily_results sheet, when copying these rows automatically would be a simple task.The macro output in the Brownian daily sheet, daily trading sheet, and summary sheet was confirmed to be correct. This included the opening and closing of the positions for each contract, the enforcement of the 10% price gap between the market and model price to open based on a machine learning price, and the .01% change needed to determine the close based on profit/loss. One peculiarity was that a profit was earned for all long positions repeatedly. However, over a holding period of more than a month, this is a likely scenario, due to the positive drift of all underlyings. After correcting the drift of five contracts to be negative, profits were negative in five of the twelve positions. Another issue was that, when utilizing an open criterion based on the difference between the model and market prices, “canOpen” will return true for each day. Thus, a check on the dictionary of TradingRows to determine whether the contract of that code is already open is necessary. This induced all positions to be closed out. Another problem was that changes to the quantity column of the control sheet seemed to be ignored. This was due to a syntactic error (using != instead of Not…=) which the interpreter does not catch. Lastly, negative (i.e. explicit sell) positions were tested for two contracts by setting the open side to “sell” (alternatively to setting side to “buy” and number of contracts to a negative value), and positions were correctly less than zero.

Monte Carlo Simulation of ProfitThe macro subroutine “runTradingSimBrownian” was rewritten to be a function returning the total position’s profit (which must be in cell L33). This macro was invoked from a cell by setting the cell value with “=runTradingSimBrownian()”, but this invocation enabled neither any modification of the workbook sheets nor any write-back of the profit to the target cell. This occurred, because functions cannot modify the Excel environment (whereas subroutines can). Thus, “runTradingSimBrownian” was reverted a subroutine and a wrapper subroutine was written to call it 100 times, each time copying the “L33” output into the profit column. Excel will then compute the average of this column. This approach functions correctly, but is rather slow (as each macro invocation within the simulation takes about 10 seconds). The mean profit was 27434.37 in the author’s simulation.

Sanity Check of Model PricesRegardless of the profitability of the trading, it is beneficial to compare the model prices to the actual market price on the dates of the simulation to discern whether any gross inaccuracies in the model exist. Any price disparities greater than 20% need to be examined critically. One problem observed was with the filtering of security codes. A March, 2016 Brent contract was input into the system on 4/16 without any error or negative price to notify the user. A gold contract about 118 months away from maturity (Feb 2026) was also processed, although no gold contracts beyond 72 months from the contract month would be listed.Model error which can be explained by inadequate training data, as in the 100% price disparity of the June Brent contract, is not necessarily a failure of the system. However, the operation of the simulation process is inadequate, as such a model would be essentially useless if trained in such a fashion prior to live trading. The soybean price for May was estimated at about 18.19, which was 8.62 above the market price on that day and about 5.50 above the six-year high of 12.65 (observed in 2013). The soybean pricing was carried out by the Naïve Bayes algorithm, as was Brent. Thus, even considering that antiquated data had been used to train the model, the performance of the algorithm is still inadequate. In the currency area, the covered interest rate parity estimate for the Swiss Franc with a September maturity was also inaccurate, with a .6875 value about 29 cents below the low since August of 2013.

Date and Time UtilitiesIn order to facilitate the time series simulation, functions to increment the date and determine the number of days in the simulation (adding one to the date difference between start and end) were written. The “strToTm” function needed to be modified to set hours, minutes, and seconds to 0 by default. Interestingly, in converting “struct tm” times from a file to “time_t” times, the “tm_isdst” daylight savings time must be correctly set (to a negative value, meaning “unknown”), or the system will incorrectly interpret the time to be a DST time (if the value is positive) and shift it back one hour in the winter. The addOneDay currency logic was modified to not lose or gain an hour when shifting into or out of daylight savings (this would cause some confusion, if the original time before the addition was in the 2am-3am hour, but such a situation seems unlikely).Note that the commodity futures program to generate model prices experienced no such complications, as the “DateTime” struct in c# automatically adjusted the time to accommodate for daylight savings time when incrementing the day, it seems. However, in the hour-by-hour adjustment, an hour is not correctly shifted forward or back, suggesting a lack of consideration of DST. An attempt to remedy this was made by explicitly specifying the “Kind” property to be “Local” (as opposed to “Unspecified”). However, this is ineffective. In fact, a Microsoft site specifically indicates that the DateTime struct does not automatically correct for daylight savings time. In order to

move the time ahead on the second Sunday of March at 2 am, Boolean flags are maintained for “previous time DST” and “current time DST”, based on checking the DateTime object against the TimeZone class’s “IsDaylightSavings” property. If the previous value is false and the current value is true, the time is incremented by an hour. Note that, for an hour of “2” in March, the DST check is performed using an hour one hour later (as there is no 2 am hour on the day that the DST changeover occurs). For the November case of falling back, though, the situation is more difficult. A data structure must be retained indicating whether or not the daylight savings reset has already occurred. This can be done via a dictionary mapping the year to a “DST ended” Boolean flag, or, if a simple loop is occurring, via a “dstEnded” flag which is reset to false whenever daylight savings begins and true once the daylight savings check returns false. If the month is November and the hour is 1, the opposite of the “DST ended” flag is the return value of the “checkDST” function.However, the MergeCSV Java class also added 3600*24 seconds onto an original date in order to increment it by a day (as did the c++ code initially). This can be remedied using the Java Calendar class’s add method and DST_OFFSET field. The Java code handles the DST begin and end dates correctly (moving ahead an hour or back an hour to result in 23-hour or 25-hour days), but the DST_OFFSET value, constant at 16, seems meaningless.The modifications were tested and are illustrated below, with the currency CSV output for the second Sunday of March 2015 (DST began) and the first Sunday of November 2015 (DST ended).begin2015-03-07 09:00:01,6JZ6,2016-12-30 00:00:00,PURCHASING POWER PARITY,0,2.52962e-321,0,0.01,0.000396825,1.94444e-005,0.00949376,20,days2015-03-08 09:00:01,6SU6,2016-09-30 00:00:00,PURCHASING POWER PARITY,0,2.52962e-321,0,0.01,0.000634921,0.000114683,0.784163,1,hoursEnd2015-10-31 09:00:01,6JZ6,-1.0,2016-12-30 00:00:00,2.53E-321,0.0,0.0,3.96825E-4,1.94444E-5,0.01,0.00949376,20,days2015-11-01 09:00:01,GCU6,0.0,2016-09-30 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,950.0,1,hoursThe Excel macro’s support of daylight savings adjustments also must be assessed. In fact, after testing the March 2015 dataset, it was apparent that the VBA “DateAdd” function did not support adding the additional hour for DST. Daylight savings begin/end checks must be implemented in VBA, as must the increment of the hour and decrement of the hour on such respective occasions. The excerpts below show adjustments for the beginning of DST (3/8/2015) and end of DST (11/1/2015).Begin DST

3/8/2015 1:00 6SH7 0.001010081 1.0308097853/8/2015 1:00 6JZ6 0.000500938 0.0098466863/8/2015 3:00 GCU6 0.00024322 1111.2985333/8/2015 3:00 GCV6 0.00041891 1114.3185433/8/2015 3:00 GCZ6 0.000701203 907.04789033/8/2015 3:00 B102016 -0.000458572 34.33911955

End DST11/1/2015 1:00 GCU611/1/2015 1:00 GCV611/1/2015 1:00 GCZ6

11/1/2015 1:00B102016

11/1/2015 1:00B112016

11/1/2015 1:00B122016

11/1/2015 1:00 ZSU611/1/2015 1:00 ZSX611/1/2015 1:00 ZSF711/1/2015 1:00 6SU611/1/2015 1:00 6SZ611/1/2015 1:00 6SH711/1/2015 1:00 6JZ611/1/2015 1:00 GCU611/1/2015 1:00 GCV611/1/2015 1:00 GCZ6

11/1/2015 1:00B102016

11/1/2015 1:00B112016

11/1/2015 1:00B122016

11/1/2015 1:00 ZSU611/1/2015 1:00 ZSX611/1/2015 1:00 ZSF711/1/2015 1:00 6SU611/1/2015 1:00 6SZ611/1/2015 1:00 6SH711/1/2015 1:00 6JZ611/1/2015 2:00 GCU6

Incorporating Quandl DataIn order to eliminate dependency on data downloaded from HTTP and on Brownian Motion data (which lacks patterns which might exist in real markets), the “market” prices will be (hopefully) based on delayed tick data from the free databases hosted by Quandl. The following data will be sought.

1. Interest rates (currency arbitrage)2. Spot exchange rates (currency arbitrage)3. Commodity futures prices4. Currency futures prices5. Mortgage-backed securities prices and yields (FNMA and FMAC) (not yet part of

this testing framework)

Migrating to Third-Party Platform: QuantiacsThis site provides a limited amount of free market data, a backtesting API (runts function), technical indicators library (RSI, exponential moving average, etc), and (untested by author) a means to upload the system into a live commercial trading environment. APIs exist in MatLab and Python and involve passing around large

matrices for open prices, close prices, etc. The system allows a subset of equity and futures contracts to be traded by embedding the algorithm within a function to be called by the “runts” function. Data files are downloaded via HTTP, stored in the file system, and read into matrices. This will be a useful platform for backtesting a single strategy in a neutral environment and as an early means to build a track record (no capital need be supplied by the trader, and 10% of the profits can be obtained). The first stage of Quantiacs use will be to upload an Octave (Matlab) port for the covered interest parity currency arbitrage strategy. In the trading system, the computation of returns by multiplying exposure (number of long/short contract, negative if short) by the single-contract return to obtain the return for the contract was not the intent of the author.The trading system is called once for each date in the trading period, and cumulative equity both by position and over the fund is computed. However, it is unclear that the fund equity (which sums the returns all contracts and multiplies the previous fund equity by (1+sum)) is valid. It is unclear how either the number of contracts bought or the connection to an exchange or brokerage’s order entry system is to be made. While the equity calculation of equity is uncertain and the market data is inadequate for the currency arbitrage algorithms (missing interest rates, PPP data, etc), a hybrid approach using the pricing model output values from the C++ code in a CSV file and the frequently-updated front-month currency futures market data from Quantiacs should be feasible. It is desirable to see the production results of a covered interest parity algorithm where real funds are involved. Risk management (limits and hedges) should be accounted for prior to submission of the algorithm to the external server.Quantiacs and Octave DifficultiesUnfortunately, many points of confusion about the data flow in these scripts have arisen. In order to debug them, the debugger was broken into by inserting the “keyboard” call in the script. After the script halts, “dbtype” prints a range of lines in the source. The “dbStep” and “dbNext” functions are equivalent to “step” and “next” in gdb. In order to break into the debugger via ctrl-c, the “debug_on_interrupt(1)” command is entered prior to running the script.One problem noted frequently was the lack of console I/O, despite the presence of “disp” or “printf” calls. This was corrected via a “fflush(stdout)” line wherever immediate I/O was required. The latency in some points is significant, but this is expected for a backtest spanning over twenty years. Parallelizing some of the matrix operations might improve performance, but the code does not appear to have been written for such an implementation.Points to note about the market data provided (and symbology) are:

1. Only the front-month futures contracts appear to be tradable (no expiry is a part of the symbol)

2. The quotes are the contract prices, not the value of one unit of the underlying, as the CME quote is (e.g. the CME quote for wheat would be in cents per bushel, but the Quantiacs quote would be in dollars per 5000-bushel contract).

Another source of confusion was the “technical indicators” library, which provides utilities such as an “RSI matrix”. This function prints a relative strength indicator matrix, but only the last two dates for any given contract have entries which are not “not a number”. This function depends on the formula: RSI = 100-100/(1+RS*), where RS* = (average of up closes)/(average of down closes). The simple moving average of the last 100 prices is computed using the Matlab (equivalent in Octave) “filter” function, which computes a rational transfer function. Basically, this takes the linear product of the 100 most recent inputs x and a vector b, then divides it by a divisor. The filter is applied row-wise over each column of the “down” and “up” matrices. It seems that all

rows except for the last two are “NaN”, as the moving average would be invalid, if there were not 100 dates to consider the average over, and the original matrices of rises and falls contain 101 rows. However, why the “up” and “down” matrices consist of only “1” and “0” entries, is unclear. It is unclear whether the “up” entries should be the rising close prices (0 if not a gain), the gain amount of up closes, or the “1” entries currently used. It is difficult to compare this to the online outputs, as most RSI calculations use a 14-day metric. The “lookback” parameter is counter-intuitive, as it induces the last n rows of the data loaded to be passed to the trading system function. This is handled by MatLab/Octave’s capability to index matrices by a Boolean vector. In this shorthand a Boolean vector can serve as a row or column selector. For example, in M(v,:), where v is a Boolean vector, only the rows where v(i)=true are output. The “sampleend” (endInSample in Python) parameter is parsed by the “loaddata.m” script to determine the last row of data read from the data file, and “samplebegin” (beginInSample in Python) indicates which day to call the trading system on first. The first trade day is “sampleBegin” + n-1, where n is the lookback parameter (factoring in holidays and weekends). This is a sliding window, whose begin and end dates move forward each day. Note that the system functionality is highly sensitive on these parameters being valid, as an incorrect begin or end date can induce an error which only indicates that the “returns” data structure is empty. The graph plotted by the runts statistic was difficult to read, but this may have been due to the octave configuration (mostly remedied in the Python version). Another source of confusion was the market returns, which is (close-prevclose-rollAdjustment)/prevClose. This statistic, which is purely the data’s price output, does not always display when the combo-box selection is updated.In order to test a covered interest parity algorithm, it was hoped that the CSV file output by the c++ code could be easily loaded into Octave and interpreted. However, Octave’s “csvread” function does not correctly parse the file, likely due to the presence of strings and dates (some of which contain spaces). Nonetheless, Octave’s support of polymorphic arrays via the “cell” object and the “textread” function, which mimics C’s “scanf” in its processing of formatted input, enables the file to be read into a matrix whose contents can be accessed by column name, as follows.[date,code,maturity,pricetype,spotrate,IR1,IR2,threshold,mean,variance,modelPrice,holdingperiod, holdingperiodunits]=textread('quant_cip.csv',"%s,%s,%s,%s,%f,%f,%f,%f,%f,%f,%f,%d,%s","delimiter",",","headerlines",1)Floating point elements, like “modelprice”, can be manipulated numerically.While it makes little sense for simulation-time prices to be used as real-time trading input, the simulation can be run to output recent-date price estimates, which will, for now, be used as a “best effort” model of the current price. The last line only will be used for now, with other lines being factored in to more sophisticated trend-based algorithms later, if possible. Actually, earlier lines will be factors in backtesting (when settings.lookback in the Octave code is adjusted). The securities traded are configured by the settings.markets parameter.Example of the currency futures model price file and output of some columns in Octave are below.Note how the spot price, interest rates, and model prices vary by day for the same security.date,code,maturity,price type,spot rate,IR1,IR2,threshold,mean,variance,modelPrice,holding period, holding period units2016-04-27 09:00:00,6SH6,2016-03-30 00:00:00,COVERED INTEREST PARITY,1.002,-0.00731096,0.00168904,0,0.000634921,0.000114683,1.0027,1,hours2016-04-27 09:00:00,6SM6,2016-06-30 09:16:00,COVERED INTEREST PARITY,1.002,-0.00629851,0.00270149,0,0.000615079,0.000108036,1.00042,24,hours

2016-04-27 09:00:00,6SU6,2016-09-30 00:00:00,99% VAR,1.002,-0.00629851,0.00270149,0.01,0.000654762,0.000117397,0.721047,1,days2016-04-28 09:00:00,6SH6,2016-03-30 00:00:00,COVERED INTEREST PARITY,1.001,-0.00698288,0.00227466,0.01,0.000634921,0.000114683,1.00175,1,hours2016-04-28 09:00:00,6SM6,2016-06-30 09:16:00,COVERED INTEREST PARITY,1.001,-0.0054642,0.00298337,0.01,0.000615079,0.000108036,0.999541,24,hours2016-04-28 09:00:00,6SU6,2016-09-30 00:00:00,99% VAR,1.001,-0.0054642,0.00298337,0.01,0.000654762,0.000117397,0.722112,1,days2016-04-29 09:00:00,6SH6,2016-03-30 00:00:00,COVERED INTEREST PARITY,1.003,-0.00559973,0.00226685,0.01,0.000634921,0.000114683,1.00366,1,hours2016-04-29 09:00:00,6SM6,2016-06-30 09:16:00,COVERED INTEREST PARITY,1.003,-0.00499226,0.00267183,0.01,0.000615079,0.000108036,1.00169,24,hours2016-04-29 09:00:00,6SU6,2016-09-30 00:00:00,99% VAR,1.003,-0.00499226,0.00267183,0.01,0.000654762,0.000117397,0.723179,1,days

>> [modeldate,code,maturity,ptype,spotrate,ir1,ir2,thresh,mean,var,modelPrice,hp,hpunits] = textread('quant_cip.csv',"%s,%s,%s,%s,%f,%f,%f,%f,%f,%f,%f,%d,%s","headerlines",1,"delimiter",",");>> modelPricemodelPrice =

1.02358 1.02125 0.72105 1.02362 1.02137 0.72211 1.02353 1.02153 0.72318

modeldate ={ [1,1] = 2016-04-27 09:00:00 [2,1] = 2016-04-27 09:00:00 [3,1] = 2016-04-27 09:00:00 [4,1] = 2016-04-28 09:00:00 [5,1] = 2016-04-28 09:00:00 [6,1] = 2016-04-28 09:00:00 [7,1] = 2016-04-29 09:00:00 [8,1] = 2016-04-29 09:00:00 [9,1] = 2016-04-29 09:00:00}How to set the “p” output variable is unclear, as is how to obtain a clearly-rendered chart. “p” was resolved to be a 1xnMarkets matrix, but the graph always scrolled off-screen upon completion of the simulation. The trading system would run only if at least two markets, cash and another, were usedUsing a sample end date of 1/3/1990 and lookback of 2, none of the performance metrics computed correctly (volatility was zero and divide-by-zero errors ensued), and errors occurred in the call to “computeFees” by the plotting logic.

The use of this API seems further complicated by a bug in Octave whereby, in order to use the HTTP functionality of urlwrite after obtaining network connectivity, Octave must be restarted.A larger problem is that the Quantiacs site does not permit the upload of more than one file per account, it seems, making the use of external data files written by the C++ and C# pricing engines untenable, unless such files are posted to the web and retrieved via Octave’s “urlwrite” command.An example model price file-- containing Swiss Franc, wheat, and corn hourly price information to be parsed-- is below.date,code,spotComm,maturity,ir1,ir2,spotFX,mean,variance,threshold,modelPr,holdingPeriod,hpUnits2016-05-13 09:00:01,6SM6,-1.0,2016-06-30 09:16:00,-0.00508431,0.00261046,1.003,1.98413E-4,3.57143E-6,0.0,1.00199,1,hours2016-05-13 09:00:01,ZCN6,3.715,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,400.0,2,hours2016-05-13 09:00:01,ZWN6,4.73,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,550.0,20,days2016-05-13 10:00:01,6SM6,-1.0,2016-06-30 09:16:00,-0.00508458,0.00261028,1.003,1.98413E-4,3.57143E-6,0.0,1.00199,1,hours2016-05-13 10:00:01,ZCN6,3.715,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,400.0,2,hours2016-05-13 10:00:01,ZWN6,0.0,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,550.0,20,days2016-05-13 11:00:01,6SM6,-1.0,2016-06-30 09:16:00,-0.00508486,0.00261009,1.003,1.98413E-4,3.57143E-6,0.0,1.00199,1,hours2016-05-13 11:00:01,ZCN6,3.5675,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,400.0,2,hours2016-05-13 11:00:01,ZWN6,0.0,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,550.0,20,days2016-05-13 12:00:01,6SM6,-1.0,2016-06-30 09:16:00,-0.00508513,0.00260991,1.003,1.98413E-4,3.57143E-6,0.0,1.00199,1,hours2016-05-13 12:00:01,ZCN6,3.715,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,400.0,2,hours2016-05-13 12:00:01,ZWN6,4.73,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,550.0,20,days2016-05-13 13:00:01,6SM6,-1.0,2016-06-30 09:16:00,-0.00508541,0.00260973,1.003,1.98413E-4,3.57143E-6,0.0,1.00199,1,hours2016-05-13 13:00:01,ZCN6,3.715,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,400.0,2,hours2016-05-13 13:00:01,ZWN6,0.0,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,550.0,20,days2016-05-13 14:00:01,6SM6,-1.0,2016-06-30 09:16:00,-0.00508568,0.00260955,1.003,1.98413E-4,3.57143E-6,0.0,1.00199,1,hours2016-05-13 14:00:01,ZCN6,3.715,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,400.0,2,hours2016-05-13 14:00:01,ZWN6,0.0,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,550.0,20,days2016-05-13 15:00:01,6SM6,-1.0,2016-06-30 09:16:00,-0.00508595,0.00260936,1.003,1.98413E-4,3.57143E-6,0.0,1.00199,1,hours2016-05-13 15:00:01,ZCN6,3.5675,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,400.0,2,hours

2016-05-13 15:00:01,ZWN6,4.73,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,550.0,20,days2016-05-13 16:00:01,6SM6,-1.0,2016-06-30 09:16:00,-0.00508623,0.00260918,1.003,1.98413E-4,3.57143E-6,0.0,1.00199,1,hours2016-05-13 16:00:01,ZCN6,3.715,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,400.0,2,hours2016-05-13 16:00:01,ZWN6,4.73,2016-07-31 00:00:00,0.0,0.0,0.0,0.0,0.0,0.0,550.0,20,daysThe Quantiacs Python API requires that the settingsCache variable be cleared between runs of the interpreter, if new data is to be downloaded. In addition, the “toolbox” library is sensitive to the names of the trading system parameters (they must exactly match the given DATE, OPEN, CLOSE, VOL, etc even in case), due to its use of reflection. In addition any failure due to a parameter misnaming can only be corrected by re-downloading the data files, it seems. The simulator is also sensitive to the values returned by the user’s myTradingSystem function, as, if the (positions, settings) vector is invalid, the next day’s dataset will not be configured correctly (leading to an error which cannot be easily deciphered).Demonstration Algorithm: Commodity Pairs TradingTwo pairs of commodity futures contracts: oil-natural gas and gold-platinum were selected to trade the spread of. The metric to trade against is the exponentially-weighted moving average (EWMA) of the spread. If the difference between the two contracts, exceeds the EWMA of fthe difference, a short position in the first contract and long position in the second contract should be taken. If the difference is less than the EWMA, a long position in the first contract and short position in the second contract should be assumed. The exponentially-weighted moving average of a time series involves weighting terms farther in the past with a lower fraction. The parameters for the trading algorithm are the EWMA’s “alpha”, the thresholds for opening a position, and the hedge ratio for the trade. Here, for a series of variables Xt and average St, St = Xt *alpha + (1-alpha)* St-1.The hedge ratio determines, for each new contract long, how many of the other contract are sold,

Bibliographyhttps://www.quantiacs.com/For-Quants/GetStarted/QuantiacsToolbox.aspx Page with links to Quantiacs API documentationhttps://msdn.microsoft.com/en-us/library/ms973825.aspx#datetime_topic6 Discussion of daylight savings time in .NEThttp://msdn.microsoft.com/en-us/library/office/ff838835.aspx Programmatically writing a formula to an Excel sheethttps://msdn.microsoft.com/en-us/library/office/gg278437.aspx Using Shell function to invoke an exe from a macrohttp://stackoverflow.com/questions/11528694/read-parse-text-file-line-by-line-in-vba Reading a filehttps://technet.microsoft.com/en-us/library/ee156590.aspx WshShell discussionhttps://technet.microsoft.com/en-us/library/ee156595.aspx Discussion of setting environment variables for shellhttps://stackoverflow.com/questions/16515177/scripting-dictionary-keys-to-listbox-vba-excel Guide to Scripting.Dictionary