|
2 | 2 | % Setup file for ARM Version 1.0 README.txt file by Iztok Fister |
3 | 3 | % |
4 | 4 | % Created: 15/9/20 |
5 | | -% Last Modified: 16/9/20 |
6 | | -% Revision: 1.0 |
| 5 | +% Last Modified: 16/11/21 |
| 6 | +% Revision: 1.0.1 |
7 | 7 | % *************************************************************** |
8 | 8 |
|
9 | 9 | README.txt describes how to configure a universal ARM Solver (uARMSolver) |
10 | 10 | using a setup file. The setup file consists of three sections, including: |
11 | 11 |
|
12 | 12 | - a problem definition, |
13 | | -- parameter setting of a selected algorithm for solving ARM, |
| 13 | +- parameter setting of a selected algorithm for solving ARM, and |
14 | 14 | - parameter setting of a selected visualization method. |
15 | 15 |
|
16 | | -Let us mention that each line started with '%' character denotes a |
17 | | -comment and consequently the corresponding lines are avoided from |
18 | | -syntax checking. |
| 16 | +Lines starting with the '%' character are comments and are not checked for |
| 17 | +syntax. |
19 | 18 |
|
20 | | -Problem definition started with reserved word 'Problem', where a |
21 | | -definitions of specific parameters follows between curly brackets. |
22 | | -Each line of parameter definition consists of three parts: parameter |
23 | | -name, equal sign '=', and the assigned value. There are the following |
| 19 | +The problem definition begins with the reserved word 'Problem', then |
| 20 | +curly brackets enclosing a series of parameter definitions. Each |
| 21 | +parameter definition is a line of the form: |
| 22 | + |
| 23 | + <parameter> = <value> |
| 24 | + |
| 25 | +The following parameters are supported: |
| 26 | + |
| 27 | + Tdbase_name = <file_name> |
| 28 | + path of the transaction database |
| 29 | + Rule_name = <file_name> |
| 30 | + path of an existing archive of mined association rules |
| 31 | + Out_name = <file_name> |
| 32 | + path where the archive of mined association rules will be written |
| 33 | + Period = <integer_value> |
| 34 | + how many periods are captured by archive files |
| 35 | + |
| 36 | +The 'Period' parameter determines whether more transaction databases or |
| 37 | +archive files are processed by the solver simultaneously. When its value |
| 38 | +is more than one, the solver expects that files are named with extensions |
| 39 | +according to their sequence numbers, e.g., .1, .2, ..., .k). When the |
| 40 | +'Period' is set to one, a single input file representing the transaction |
| 41 | +database or ARM archive is processed. |
| 42 | + |
| 43 | +A line of the form: |
| 44 | + |
| 45 | + Algorithm = <mnemonic> |
| 46 | + |
| 47 | +selects a particular ARM solver algorithm. For example, the Differential |
| 48 | +Algorithm has mnemonic 'DE', Particle Swarm Optimization has mnemonic |
| 49 | +'PSO', and so on. |
| 50 | + |
| 51 | +When the algorithm is `NONE`, the solver does not perform optimization. |
| 52 | +Instead, it expects an ARM archive produced by another traditional |
| 53 | +algorithm (such as Apriori) and focuses on the visualization section of |
| 54 | +the process. |
| 55 | + |
| 56 | +Next are algorithm-specific parameter blocks. These begin with a line of |
| 57 | +the form |
| 58 | + |
| 59 | + <mnemonic>_PARAM |
| 60 | + |
| 61 | +followed by curly brackets enclosing a series of parameter definitions of |
| 62 | +the form |
| 63 | + |
| 64 | + <mnemonic>_<param> = <value> |
| 65 | + |
| 66 | +For example, the Differential Algorithm (DE) supports the following |
24 | 67 | parameters: |
25 | 68 |
|
26 | | -- 'Tdbase_name' = <file_name>: parameter <file_name> identifies a path, |
27 | | -where the transaction database is located, |
28 | | -- 'Rule_name' = <file_name>: parameter <file_name> identifies a path, |
29 | | -where the existing archive of mined association rules exists, |
30 | | -- 'Out_name' = <file_name>: parameter <file_name> identifies a path, |
31 | | -where the arhive of mined association rules needs to be stored, |
32 | | -- 'Period' = <integer_value>: parameter <integer_value> determines, how |
33 | | -many periods are captured by particular archive files. |
34 | | - |
35 | | -Actually, the last parameter determines, if more transaction databases or |
36 | | -archive files are processed by the solver simultaneously. Indeed, when the |
37 | | -value of the 'Period' parameter is more than one, the solver expect that |
38 | | -an extension of each specific file is denotes as a sequence number (e.g., |
39 | | -.1, .2, ..., .k). In contrast, when the period is set to one, normally, |
40 | | -one input file representing the transaction database or ARM archive is |
41 | | -processed. |
42 | | - |
43 | | -The algorithm section is devoted for selecting a particular algorithm in |
44 | | -role of ARM solver. The algorithm selection is realized through a token |
45 | | -'Algorithm', which a mnemonic of the definite algorithm follows. For |
46 | | -instance, Differential Algorithm is selected using token <DE>, the Particle |
47 | | -Swarm Optimization using token <PSO>, etc. Interestingly, there exists also |
48 | | -selection <NONE> determining that no optimization algorithm is used. In this |
49 | | -case, the solver expect ARM archive produced by the other traditional |
50 | | -algorithms (like Apriori), and focus itself on the visualization section |
51 | | -of the process. |
52 | | - |
53 | | -After selecting the appropriate optimization algorithm, parameter setting |
54 | | -determining its behavior follows. Each parameter setting starts with the |
55 | | -mnemonic of the algorithm to which the word 'PARAM' is concatenated using |
56 | | -a '_' character. Then, parameter setting follows enclosed between two |
57 | | -curly brackets. For DE algorithm, we can specify the following parameters |
58 | | -introduced in form of "'ALG_Parameter' = <Value>": |
59 | | - |
60 | | -- 'DE_NP' = <integer_value>: the population size of DE algorithm, |
61 | | -- 'DE_FES' = <integer_value>: the maximum number of fitness function evaluations, |
62 | | -- 'DE_RUNS' = <integer_value>: the maximum number of an independent DE runs, |
63 | | -- 'DE_F' = <float_value>: the scaling factor used by DE mutation strategy, |
64 | | -- 'DE_CR' = <float_value>: the crossover parameter controlling the DE mutation strategy, |
65 | | -- 'DE_STRATEGY' = <integer_value in [1,12]>: the specific DE mutation strategy. |
66 | | - |
67 | | -Similarly, also parameters of the other optimization algorithms are specified. |
68 | | - |
69 | | -Although not implemented yet, the solver will support also visualization section, |
70 | | -in which an appropriate visualization method is selected and the parameter setting |
71 | | -of the selected method are determined. Actually, this section is devoted for |
72 | | -definition of the algorithm necessary for preparing data from the ARM archive that |
73 | | -serve for visualization method. We plan to implement two algorithms for preparing |
74 | | -River flov (token <FLOW>) and Metro map (token <METRO>) visualization methods that |
75 | | -can be selected using reserved word 'Visualization'. If token <NONE> is selected, |
76 | | -no visualization preparation is demanded. |
| 69 | + DE_NP = <integer_value> |
| 70 | + population size of DE algorithm |
| 71 | + DE_FES = <integer_value> |
| 72 | + maximum number of fitness function evaluations |
| 73 | + DE_RUNS = <integer_value> |
| 74 | + maximum number of an independent DE runs |
| 75 | + DE_F = <float_value> |
| 76 | + scaling factor used by DE mutation strategy |
| 77 | + DE_CR = <float_value> |
| 78 | + crossover parameter controlling the DE mutation strategy |
| 79 | + DE_STRATEGY = <integer_value in [1,12]> |
| 80 | + specific DE mutation strategy |
| 81 | + |
| 82 | +In the future, the solver will support a visualization method. A line of |
| 83 | +the form: |
| 84 | + |
| 85 | + Visualization = <mnemonic> |
| 86 | + |
| 87 | +selects a particular method of preparing the data from the ARM archive for |
| 88 | +visualization. |
| 89 | + |
| 90 | +Two algorithms are planned: |
| 91 | + |
| 92 | + FLOW |
| 93 | + River flow |
| 94 | + METRO |
| 95 | + Metro map |
| 96 | + |
| 97 | +Method 'NONE' will disable visualization preparation. |
| 98 | + |
| 99 | +Visualization methods will have method-specific parameter blocks similar to the |
| 100 | +algorithm-specific parameter blocks for the ARM solver. |
0 commit comments