---
title: 'PNUL: Positive & Negative Utility Lists'
url: https://www.emergentmind.com/topics/positive-and-negative-utility-lists-pnul
type: topic
---

# PNUL: Positive & Negative Utility Lists

Positive and Negative Utility Lists (PNUL) are a vertical list structure for high-utility pattern mining in databases that may contain both positive and negative utility values. In the formulation introduced for the TPU algorithm, PNUL stores transaction-level information for an itemset while separating its positive contribution, negative contribution, and a positive-only remaining-utility term. This separation is the central design choice that permits exact utility computation together with safe upper-bound pruning in top-\(k\) periodic high-utility pattern mining, where ordinary utility-list pruning is unsafe or too weak when negative utilities are present [2509.15732].

## 1. Definition and representational role

In the relevant mining literature, PNUL denotes the **Positive and Negative Utility List**. The paper defining TPU states that PNUL is the vertical list structure used to represent utilities of itemsets when the database may contain both positive and negative utility values, and that TPU is designed for extracting top-\(k\) periodic and high-utility patterns “that may or may not include negative utility values” [2509.15732]. In the same source, the formal definition appears under the name **PNU-list**, while the surrounding discussion uses **PNUL**; these are the same structure up to naming.

Formally, for an itemset \(X\) in \(\mathcal{D}\), the PNU-list of \(X\), denoted \(X.\mathrm{PNUL}\), consists of the itemset \(X\) itself and a list of all transactions containing \(X\). Each list entry is a 4-tuple
\[
[tid, pu, nu, ru],
\]
where \(tid\) is the transaction identifier, \(pu\) is the positive utility of \(X\) in that transaction, \(nu\) is the negative utility of \(X\) in that transaction, and \(ru\) is the sum of the utilities of all positive items following \(X\) in that transaction according to the global order \(\prec\) [2509.15732].

| Field | Meaning |
|---|---|
| \(tid\) | identifier of a transaction containing \(X\) |
| \(pu\) | positive utility of \(X\) in that transaction |
| \(nu\) | negative utility of \(X\) in that transaction |
| \(ru\) | remaining utility from positive suffix items after \(X\) |

The defining motivation is that ordinary utility-list formulations do not handle mixed-sign utilities well. TPU therefore adopts a list that separates positive and negative accumulated utility and retains a remaining-utility term based only on positive suffix items. This supports exact utility evaluation while preserving a valid upper bound for extension pruning. The related-work discussion in the TPU paper directly attributes PNUL to FHN and states that it was designed to mine high-utility itemsets with negative items efficiently; TPU reuses that style of list rather than a standard utility list [2509.15732].

## 2. Mathematical semantics

The underlying utility model begins at the item level. For an item \(x\) in transaction \(T_i\),
\[
U(x,T_i) = iu(x,T_i) \times eu(x).
\]
For an itemset \(X\) in transaction \(T\), the positive and negative parts are defined separately:
\[
PU(X,T) = \sum_{i \in X \wedge eu(i) > 0} U(i,T),
\]
\[
NU(X,T) = \sum_{i \in X \wedge eu(i) < 0} U(i,T).
\]
At database level, total utility is
\[
U(X) = PU(X) + NU(X).
\]
The TPU paper also gives the database-level formulas
\[
PU(X) = \sum_{X \subseteq T_j \subseteq \mathcal{D}} PU(X,T_j), \qquad
NU(X) = \sum_{X \subseteq T_j \subseteq \mathcal{D}} NU(X,T_j),
\]
with \(U(X)=PU(X)+NU(X)\) [2509.15732].

The remaining-utility component is defined transaction by transaction as
\[
ru(X, T_{tid}) = \sum_{i \in T_{tid} \wedge x \prec i \wedge \forall x \in X} PU(i, T_{tid}).
\]
Thus \(ru\) is computed only from positive utilities of suffix items that appear after all items of \(X\) in the total order \(\prec\). That order is defined so that negative items come before positive items, and within the same sign class items are sorted by ascending RTWU. The restriction of \(ru\) to positive suffix utility is essential: including negative suffix utility would not preserve the same useful upper-bound property, and mixing positive and negative contributions would make the standard remaining-utility bound invalid or too loose in the negative-utility setting [2509.15732].

A cautious interpretation directly implied by the structure is that database-level aggregates can be read from the PNUL of \(X\) by summing fields over entries, namely \(PU(X)\) from all \(e.pu\), \(NU(X)\) from all \(e.nu\), and \(RU(X)\) from all \(e.ru\). The paper does not explicitly write these summation-over-list equations, but it states that this is the standard interpretation of utility-list fields and that the reading is implied by the definitions and pruning properties [2509.15732].

## 3. Construction and join mechanics

Within TPU, PNUL construction begins after an initial preprocessing phase. The algorithm first scans the database to compute utility and periodic information for single items, applies PIU to raise the threshold, keeps promising items in \(I^\star\), orders them by \(\prec\), and then scans \(\mathcal{D}\) again to construct the PNUL and PEUCS [2509.15732].

For 1-itemsets, the paper does not provide line-by-line pseudocode, but the implied construction is explicit enough. Each reordered transaction contributes one tuple \([tid, pu, nu, ru]\) to every surviving item it contains. For a singleton \(\{i\}\), \(pu\) is \(U(i,T)\) if \(eu(i)>0\) and 0 otherwise; \(nu\) is \(U(i,T)\) if \(eu(i)<0\) and 0 otherwise; \(ru\) is the sum of positive utilities of items appearing after \(i\) in the reordered transaction. The source labels this as an interpretation induced by the formal definition rather than a separately stated theorem [2509.15732].

For larger itemsets, PNULs are built by the **Construct** procedure. Let \(P\) be a prefix, with \(P_m = P \cup \{m\}\), \(P_n = P \cup \{n\}\), and \(m \prec n\). The output is \(P_{mn}=P\cup\{m,n\}\). Construction proceeds by matching entries with the same \(tid\) between \(P_m.\mathrm{UL}\) and \(P_n.\mathrm{UL}\). When \(P.\mathrm{UL}=null\), meaning that 1-itemsets are joined to form a 2-itemset, the new tuple is
\[
emn = [em.tid,\; em.pu + en.pu,\; em.nu + en.nu,\; en.ru].
\]
When \(P.\mathrm{UL}\neq null\), the prefix contribution is subtracted once to avoid double counting:
\[
emn = [em.tid,\; em.pu + en.pu - e.pu,\; em.nu + en.nu - e.nu,\; en.ru].
\]
The use of \(en.ru\) as the new remaining utility reflects that after appending \(n\), the suffix relevant for future extensions is exactly the suffix after \(n\) [2509.15732].

The join phase also embeds pruning. The procedure initializes
\[
sumUtility = PU(P_m) + RU(P_m).
\]
If a tuple \(em \in P_m.\mathrm{UL}\) has no matching tuple in \(P_n.\mathrm{UL}\), it updates
\[
sumUtility \mathrel{-}= (em.pu + em.ru),
\]
and decrements support of \(P_m\). If afterward
\[
sumUtility < minutil \quad \parallel \quad sup(P_m) < supportPruning,
\]
the procedure returns null. The first condition is utility look-ahead pruning based on \(PU+RU\); the second is support-based pruning linked to periodicity feasibility. The TPU paper mentions **supportPruning** in pseudocode but does not formally define its exact formula there. It does, however, state that periodic constraints induce a support range, such as \(1 \le sup(X) \le 9\) in the running example, so the support test is explicitly period-related even when the exact expression is implicit [2509.15732].

## 4. Pruning logic and interaction with periodicity

The core PNUL-based upper bound is the RU pruning property:
\[
\text{if } RU(X) + PU(X) < minutil,
\]
then neither \(X\) nor its extensions are high-utility itemsets. Because \(RU(X)\) contains only positive suffix utility, it safely upper-bounds the utility that can still be gained by extending \(X\), even when some items have negative utility. This is the main correctness rationale for separating \(PU\) and \(NU\) [2509.15732].

The TPU paper states the exact-utility identity
\[
U(X) = PU(X) + NU(X),
\]
so PNUL serves a dual function: it provides exact utility through \(PU+NU\) and a pruning upper bound through \(PU+RU\). The proof intuition supplied in the paper is that for \(X \subseteq Y\),
\[
U(Y) < RU(X)+PU(X).
\]
Negative additions cannot increase utility, so excluding them from the upper bound is safe and useful rather than conservative in the wrong direction [2509.15732].

Periodicity is coupled to PNUL through transaction identifiers rather than through extra per-entry fields. The periodic definitions used by TPU are
\[
Per(X)=\{tid_{i+1}-tid_i \mid i=0,1,2,\ldots,k\},
\]
with \(tid_0=0\) and the last boundary equal to the database size, together with
\[
maxPer(X) = \max(Per(X)), \qquad
minPer(X) = \min(Per(X)),
\]
and
\[
avgPer(X) = \frac{\sum_{k\in Per(X)} k}{|Per(X)|} = \frac{|\mathcal{D}|}{(|sup(X)|+1)}.
\]
PNUL provides the ordered \(tid\) sequence from which these quantities can be computed or updated [2509.15732].

For 2-itemsets, TPU stores periodicity directly in **PEUCS**, where each entry records \(RTWU\), Utility, \(minPer\), \(maxPer\), and support. For larger itemsets, periodic information is maintained during PNUL construction by the auxiliary procedure **getPeriod** and related updates on the sequence of retained tids. Thus period-related metadata is maintained alongside the list, not inside each PNUL tuple. A common misconception is that PNUL entries themselves include period fields; in TPU they do not. The entry schema remains exactly \([tid,pu,nu,ru]\), while periodicity is derived externally from the tids or stored in PEUCS for pairs [2509.15732].

The same paper also redefines transaction utility and RTWU to remain valid in the presence of negative utilities:
\[
RTU(T_k) = PU(T_k, T_k),
\]
\[
RTWU(X) = \sum_{X \subseteq T_k \subseteq \mathcal{D}} RTU(T_k).
\]
Because RTU contains only positive utility, RTWU remains an upper bound even with negative items. This feeds initial filtering and co-occurrence pruning before PNUL joins are attempted [2509.15732].

## 5. Use within TPU and worked examples

In TPU’s search phase, PNUL is the core representation for recursive pattern extension. For each candidate \(P_m\), TPU checks whether it is itself a periodic high-utility itemset by combining exact utility \(U(P_m)=PU(P_m)+NU(P_m)\) with periodicity constraints \(minPer \le minPer(P_m)\), \(maxPer(P_m)\le maxPer\), and \(minAvg \le avgPer(P_m)\le maxAvg\). Before generating descendants, it applies the PNUL-based upper bound
\[
PU(P_m)+RU(P_m)\ge minutil,
\]
together with \(maxPer(P_m)\le maxPer\) and \(avgPer(P_m)\le maxAvg\). Only itemsets passing these tests are extended. Candidate generation is then a PNUL join, while PEUCS reduces unnecessary joins by supplying pairwise RTWU, utility, and periodicity information [2509.15732].

PNUL also interacts indirectly with TPU’s threshold-raising strategies. PIU is computed during the first scan from single-item utilities satisfying periodic constraints. PCUD is derived from PEUCS or PCUDM values for 2-itemsets that satisfy periodicity and RTWU pruning. PRU uses utilities of all 1-itemsets and 2-itemsets currently known to satisfy periodicity, stored in a priority queue, to further raise \(minutil\). The TPU paper explicitly states that by using this information one can “swiftly determine whether to construct the UL of an itemset, thereby avoiding numerous UL join operations.” By the reported experiments, these threshold-raising strategies reduced runtime by approximately 5\% on the datasets used in the experiments, by up to 50\% on the mushroom\_negative and kosarak\_negative datasets, and by up to 10\% on the chess\_negative dataset; memory consumption was reduced by about 2\%, with the largest reduction of about 30\% on mushroom\_negative [2509.15732].

The paper gives one explicit PNUL example for the itemset \(\{c,d,b\}\):
\[
\begin{array}{cccc}
\text{tid} & pu & nu & ru \\
3 & 17 & -3 & 12 \\
8 & 13 & -1 & 6 \\
10 & 8 & -2 & 0
\end{array}
\]
using the global order
\[
g \prec e \prec c \prec a \prec d \prec b \prec f.
\]
In \(T_3\), the reordered transaction is \(\{g\!:\!-6, c\!:\!-3, d\!:\!12, b\!:\!5, f\!:\!12\}\), so for \(cdb\) the positive utility is \(12+5=17\), the negative utility is \(-3\), and the remaining utility is 12 from suffix item \(f\). In \(T_8\), \(pu=3+10=13\), \(nu=-1\), and \(ru=6\); in \(T_{10}\), there is no suffix positive item after \(b\), so \(ru=0\). Summing the entries yields
\[
PU(cdb)=38,\qquad NU(cdb)=-6,\qquad U(cdb)=32,\qquad RU(cdb)=18
\]
as implied by PNUL semantics [2509.15732].

The same source reconstructs a singleton example for the negative item \(c\). Across transactions \(T_1,T_3,T_5,T_6,T_8,T_9,T_{10}\), each PNUL entry for \(c\) has \(pu=0\), \(nu=U(c,T)\), and \(ru\) equal to the positive suffix utility after \(c\). The resulting totals are \(PU(c)=0\), \(NU(c)=-16\), \(U(c)=-16\), and \(RU(c)=168\). This illustrates a characteristic PNUL phenomenon: an itemset can have low or negative exact utility but still possess substantial extension potential because its positive suffix utility remains large. A further reconstructed example joins the PNULs of \(c\) and \(d\) to obtain \(cd\), with
\[
PU(cd)=42,\quad NU(cd)=-15,\quad U(cd)=27,\quad RU(cd)=80.
\]
In the running example, the threshold after PIU, PCUD, and PRU reaches \(minutil=90\), so \(cd\) is not itself a top-\(k\) PHUI, but its upper bound \(PU(cd)+RU(cd)=122\) prevents immediate RU pruning; by contrast, \(df\), \(bf\), and \(f\) become the final top-\(k\) periodic high-utility patterns [2509.15732].

## 6. Relation to adjacent structures and terminological ambiguity

PNUL belongs to the utility-list family but differs from both ordinary utility lists and compressed positive-utility variants. The TPU paper notes that its recursive pseudocode sometimes uses the generic notation “UL,” but in context that UL is a PNUL when negative values are allowed. It also distinguishes PNUL from the **M-list** of PHMN, another structure for periodic high-utility mining with negative values. In TPU, PNUL is therefore best understood as a positive/negative-aware utility list, while PEUCS is the companion pairwise summary used for pre-join pruning and threshold raising [2509.15732].

A useful background point comes from the **PUN-list** structure introduced for MIP. PUN-list is described as “a highly compressed format of utility-list,” stores exact utility information, upper-bound information via anterior utility, and auxiliary data for joins, and supports direct HUIM by joining node-based summaries rather than transaction-based entries. However, that work is explicitly confined to the standard positive-utility setting and “does not mention ‘Positive and Negative Utility Lists’ (PNUL), nor negative profits/utilities.” Its relevance to PNUL is therefore methodological rather than direct: it provides a precedent for compression, join design, and branch-and-bound organization, but not a correctness treatment for mixed-sign utilities [1510.02188].

There is also a distinct and unrelated use of positive/negative lists in qualitative decision theory. In that literature, a decision is represented by the sets \(A^+\) and \(A^-\) of arguments in favor of and against the decision, and comparison rules such as BiPoss, Discri, BiLexi, and Lexi are defined on ordinal importance levels. This is not the same object as the PNUL structure used in utility-list mining; the former concerns qualitative comparison of pros and cons, whereas the latter is a transaction-indexed data structure for exact utility computation and pruning in high-utility pattern mining [1401.3444].

Taken together, these distinctions clarify the place of PNUL in the broader landscape. In high-utility mining, PNUL is not merely a storage convention. It is the structure that makes it possible to separate exact positive and negative utility contributions while preserving a positive-only upper bound for future extensions. That combination is the mathematical basis for TPU’s one-phase, list-based mining of top-\(k\) periodic high-utility patterns in databases containing negative utilities [2509.15732].

Source: https://www.emergentmind.com/topics/positive-and-negative-utility-lists-pnul