Mining On-Shelf High-Utility Itemsets from a Transaction Database using the FOSHU Algorithm (SPMF documentation)
This example explains how to run the FOSHU algorithm using the SPMF open-source data mining library.
How to run this example?
- If you are using the graphical interface, (1) choose the "FOSHU" algorithm, (2) select the input file "DB_FOSHU.txt", (3) set the output file name (e.g. "output.txt") (4) set the minimum utility ratio to 0.8 and (5) click "Run algorithm".
- If you want to execute this example from the command line,
then execute this command:
java -jar spmf.jar run FOSHU DB_FOSHU.txt output.txt 30 in a folder containing spmf.jar and the example input file DB_FOSHU.txt. - If you are using the source code version of SPMF, launch the file "MainTestFOSHU_saveToFile.java" in the package ca.pfv.SPMF.tests.
What is FOSHU?
FOSHU (Fournier-Viger et al, 2015) is an algorithm for discovering high-utility itemsets in a transaction database containing utility information and information about the time periods where items are sold. The task of on-shelf high-utility itemset mining is an extension of the task of high utility itemset mining.
The FOSHU algorithm for on-shelf-high-utility itemset mining is interesting because it addresses two limitations of high-utility itemset mining algorithms. First, most algorithms cannot handle databases where items may have negative unit profit/weight. But such items often occur in real-life transaction databases. For example, it is common that a retail store will sell items at a loss to stimulate the sale of other related items or simply to attract customers to their retail location. If classical HUIM algorithms are applied on database containing items with negative unit profit, they can generate an incomplete set of high-utility itemsets. Second, most algorithms consider that items have the same shelf time, i.e. that all item are on sale for the same time period. However, in real-life some items are only sold during some short time period (e.g. the summer). Algorithms ignoring the shelf time of items have a bias toward items having more shelf time since they have more chance to generate a high profit.
FOSHU is the state-of-the-art algorithm for on-shelf high-utility itemset mining. It was shown to outperform TS-HOUN by up to three orders of magnitude in terms of execution time.
This is the original implementation of FOSHU.
What is the input?
FOSHU takes as input a transaction database with information about the utility of items and their shelf time time, and a minimum utility threshold min_utility ratio (a positive double value in the [0,1] interval). For example, let's consider the following database consisting of 5 transactions (t1,t2, ..., t5) and 7 items (1, 2, 3, 4, 5, 6, 7). This database is provided in the text file "DB_FOSHU.txt" in the package ca.pfv.spmf.tests of the SPMF distribution.
| Transaction | Items | Transaction utility (positive) | Item utilities for this transaction | Time period |
| t1 | 1 3 4 | 3 | -5 1 2 | 0 |
| t2 | 1 3 5 7 | 17 | -10 6 6 5 | 0 |
| t3 | 1 2 3 4 5 6 | 25 | -5 4 1 12 3 5 | 1 |
| t4 | 2 3 4 5 | 20 | 8 3 6 3 | 1 |
| t5 | 2 3 5 7 | 11 | 4 2 3 2 | 2 |
Each line of the database represents a transaction and contains the following information:
- a set of items (the second column of the table),
- the sum of the utilities (e.g. profit) of items having positive utilities in this transaction (the third column of the table),
- the utility of each item for this transaction (e.g. profit generated by this item for this transaction)(the fourth column of the table).
- the time period where this transaction occurred (the fifth column).
Note that the value in the third column for each line is the sum of the positive values in the fourth column. Moreoever, note that utility values may be positive or negative integers. Time periods are values numbered 0,1,2,3..., which may represent for example periods such as "summer", "fall", "winter" and "spring".
What are real-life examples of such a database? There are several applications in real life. The main application is for customer transaction databases. Imagine that each transaction represents the items purchased by a customer. The first customer named "t1" bought items 1, 3 and 4. The amount of profit generated by the sale of each of these item is respectively -5 $, 1 $ and 2 $. The total amount of money spent in this transaction is -5 + 1 + 2 = 3 $. This transaction was done during time period "0", which may for example represents the summer.
What is the output?
The output of the FOSHU algorithm is the set of on-shelf high utility itemsets having a relative utility no less than the min_utility_ratio threshold set by the user. To explain what is an on-shelf high utility itemset, it is necessary to review some definitions. An itemset is an unordered set of distinct items. The utility of an itemset in a transaction is the sum of the utility of its items in the transaction. For example, the utility of the itemset {1, 3, 4} in transaction t1 is -5 + 1 + 2 = 3, and the utility of {1, 3, 4} in transaction t3 is -5 + 1 + 12 = 7. The utility of an itemset in a database is the sum of its utility in all transactions where it appears. For example, the utility of {1, 3, 4} in the database is the utility of {1, 3, 4} in t1 plus the utility of {1, 3, 4} in t3, for a total of -2 + 8 = 6. The relative utility of an itemset is the utility of that itemset divided by the sum of the transaction utilities for the time period where the itemset was sold (including the negative utilities. For example, itemset {1, 3, 4} was sold in time periods "0" and "1". The total utility of time period "0" and "1" is 5 + 40 = 45. Thus, the relative utility of {1, 3, 4} is 6 / 45 = 0.13. The relative utility can be interpreted as a ratio of the profit generated by a given itemset during the time period when it was sold.
A on-shelf high utility itemset is an itemset such that its relative utility is no less than min_utility_ratio. For example, if we run FOSHU with a minimum utility of 0.8, we obtain the following on-shelf high-utility itemsets:
| itemsets | utility ($) | relative utility |
| {2, 5, 7} | 9 $ | 0.81 |
| {2, 3, 5, 7} | 11 $ | 1 |
| {5, 7} | 16 $ | 1 |
| {3, 5, 7} | 24 $ | 1.5 |
| {1, 3, 5, 7} | 7 $ | 1.4 |
| {3, 7} | 15 $ | 0.9375 |
| {2, 4, 5} | 36 $ | 0.9 |
| {2, 3, 4, 5} | 40 $ | 1 |
| {2, 3, 4} | 34 $ | 0.85 |
If the database is a transaction database from a store, we could interpret these results as all the groups of items bought together that generated a ratio of at least 0.8 on the total profit during the time period when they were sold.
Input file format
The input file format of FOSHU is defined as follows. It is a text file. Each lines represents a transaction. Each line is composed of three sections, as follows.
- First, the items contained in the transaction are listed. An item is represented by a positive integer. Each item is separated from the next item by a single space. It is assumed that all items within a same transaction (line) are sorted according to a total order (e.g. ascending order) and that no item can appear twice within the same transaction.
- Second, the symbol ":" appears and is followed by the transaction utility (an integer).
- Third, the symbol ":" appears and is followed by the utility of each item in this transaction (an integer), separated by single spaces.
- Fourth, the symbol ":" appears and is followed by a positive integer such as 0,1,2.... indicating the time period of the transaction
For example, for the previous example, the input file is defined as follows:
1 3 4:3:-5 1 2:0
1 3 5 7:17:-10 6 6 5:0
1 2 3 4 5 6:25:-5 4 1 12 3 5:1
2 3 4 5:20:8 3 6 3:1
2 3 5 7:11:4 2 3 2:2
Consider the first line. It means that the transaction {1,3, 4} has a total utility of 3 and that items 1, 3 and 4 respectively have a utility of -5, 1 and 2 in this transaction. The following lines follow the same format.
Output file format
The output file format of FOSHUis defined as follows. It is a text file, where each line represents a on-shelf high utility itemset. On each line, the items of the itemset are first listed. Each item is represented by an integer, followed by a single space. After, all the items, the keyword " #UTIL: " appears and is followed by the utility of the itemset. Then, the keyword "#RUTIL:" appears followed by the relative utility of this itemset. For example, we show below the output file for this example.
7 2 5 #UTIL: 9 #RUTIL: 0.8181818181818182
7 2 5 3 #UTIL: 11 #RUTIL: 1.0
7 5 #UTIL: 16 #RUTIL: 1.0
7 5 3 #UTIL: 24 #RUTIL: 1.5
7 5 3 1 #UTIL: 7 #RUTIL: 1.4
7 3 #UTIL: 15 #RUTIL: 0.9375
4 2 5 #UTIL: 36 #RUTIL: 0.9
4 2 5 3 #UTIL: 40 #RUTIL: 1.0
4 2 3 #UTIL: 34 #RUTIL: 0.85
For example, the second line indicates that the itemset {2, 3, 5, 7} has a utility of 11 $ and a relative utility of 1. The other lines follows the same format.
Performance
On-shelf high utility itemset mining is a more difficult problem than frequent itemset mining. Therefore, on-shelf high-utility itemset mining algorithms are generally slower than frequent itemset mining algorithms. The FOSHU (2015) algorithm is up to 1000 times faster than TS-HOUN, the previous state-of-the-art algorithm for on-shelf high-utility itemset mining.
Implementation details
The version of FOSHU offered in SPMF is the original implementation.
Where can I get more information about the FOSHU algorithm?
This is the reference of the article describing the FOSHU algorithm:
Fournier-Viger, P., Zida, S. (2015). FOSHU: Faster On-Shelf High Utility Itemset Mining– with or without negative unit profit. Proc. 30th Symposium on Applied Computing (ACM SAC 2015). ACM Press, pp. 857-864.
Besides, for a general overview of high utility itemset mining, you may read this survey paper.