• No results found

CHAPTER 5 RESULT STUDY 1: VALIDITY AND RELIABILITY ANALYSIS

5.6 Test Scale Reliability

University

of Cape

Town

111

University

of Cape

Town

112

hierarchical data is generally represented within Windows and allows the criteria to be logically grouped and ordered within the text file.

2. The second reason for this selection was as a result of the user interface software component that was used to graphically represent a tree structure. This component could natively illustrate a tree structure if the underlying file structure was tab-delimited. This saved several hours of software development as the component could both read a tab-delimited file and represent a tree as well as write back the modified tree structure as a tab-delimited file.

3. Finally, a tab-delimited file could be modified by a novice Windows user more easily than a Excel file or an XML file

User interface components were designed to aid the user in generating and editing a script file. For the purposes of this chapter, it is worthwhile summarising that a script is essentially a self-describing file detailing the simulation parameters to be run. An example of a script file, as copied out of its text file, is illustrated in figure 7-4. Note the hierarchical tree structure inherent in the layout of the text file; created through the use of tabbed spacing.

University

of Cape

Town

113

TEST G E&P HP1_00001 SubTest SA All L

Factors

Factor 1

Name = EBITMarginRelative_on_StockPickDate Rolling Days = 30

Weight = 40 ExclNegSQLData = No ExclNegPerChgData = No Factor 2

Name = PEMarginRelative_on_StockPickDate Rolling Days = 130

Weight = 60 ExclNegSQLData = Yes ExclNegPerChgData = No Days

Holding Period = 30 Use Calendar Months = TRUE Monthly Holding Period = 1 Correlation

Use Correlated Groups = FALSE Correlate to INDEX Code = J203 Rolling Back Days 30 Minimum Trading Days 30 From1 0

To1 10 From2 0 To2 0 From3 0 To3 0 Fund Cash

InvestorsCash = 1,000,000.00 Opening Short = 0.00 Debt = 0.00 Ranking Table

Short BOTTOM SHORT 0 Long TOP LONG 20 Ascending = True Auto Exits

Sell=FALSE DynamicFloor=FALSE Risk Capital Rate = 0 Short Loss Limit = 0 Long Loss Limit = 0 RelativePositioning=FALSE RelativeCalendarDays = 20 CoverShortBelow = 60 SellLongAbove = 60 Rates

Cash Allocation Rate = 0 Cash Collateral Rate = 0 Equity Margin Rate = 0 Avg Borrow Rate = 0.5 Purchase Brokerage = 0.25 Sale Brokerage = 0.25 Performance Fee Rate = 0 Mgmt Fee Rate = 0 Long/Short Liquidity Constraints

Long % Daily VT = 25 Long Days to enter = 10 Short % Daily VT = 25 Short Days to enter = 10

%NAV Shorts Limit = 100

%NAV Longs Limit = 100 Universe Filter

Universe Filter Filename = G_E&P.sql Filter by = Liquidity

Filter Method = NA Position Size = 1000000

% of Daily VT = 50 Days for Avg = 50 Days to enter = 5 Perf Indices/Rates/Rel Index Category

Benchmark Index = OILEPWD Perf Index 1 = M2DWM2$

Perf Index 2 = S&PCOMP Perf Index 3 = MSWRLD$

BA Rate = US_CASH PRIME Rate = US_PRIME Rel Index Category = 1 General

Subtest Description = G Oil L Subtest Currency = USD

Fig 7-4: Example of a script file

University

of Cape

Town

114 Within the software user interface, the hierarchical tree structure was chosen to display this data to the user. This method of data representation is understood by users of the Windows operating system due to its prevalence throughout the operating system and within most desktop applications. Through this interface, the user can clearly understand the parameters that make up the test to be run in the simulator, but also has the ability to change these parameters and re-save the data to file. The individual parameters have been grouped to represent their functional role within the simulator.

The illustration on the right shows the simulation parameters for a single test, TEST MastersDemo. Some of the branches of the tree have been expanded for illustrative purposes. This is essentially a text file and as such, can be edited using any text editor.

Fig 7-5: TreeView UI component

University

of Cape

Town

115

An architectural benefit of creating a parameter file which in essence is a configuration file, is that the file represents the sum total of user interaction with the system; since the user does not interact with the system post simulator execution, other than to review the results.

As such, these parameters can be parsed for configuration issues before execution to ensure simulator runtime stability. Prior to a simulation executing, the script was parsed for two reasons; one being to initialise the variables of the simulator to the configured values, the other to sanity check the values and datatypes. For example, the boolean SELL parameter accepts TRUE or FALSE. If the user has entered another datatype, for example an integer value, it would halt the execution and request a script modification. Apart from datatype checking, value range checking was also applied at this stage to reduce simulation errors later on. An example of a value range error would be one where the user cannot enter a Cash Allocation Rate of 300 as this is an out-of-range number for this context.

The tree structure aids batch simulations by collapsing simulation parameters at the TEST level. Figure 7-6 is an example of what the user would see in a batch script which contains several tests. One of the tests has been expanded to illustrate the same parameters as illustrated in figure 7-5. This ensured that the simulator was extensible to cater for multiple tests.

University

of Cape

Town

116

Figure 7-6 highlights part of the user interface that was developed to aid in the visualisation, creation and editing of script files.