Logarithmic Normalization

Unlike the other normalisation building blocks, Logarithmic Normalization works on a logic based on multiplication rather than direct summation. It takes the logarithm of every value before summing them, which is why it sits naturally alongside game-theoretic methods and aggregation steps built on the geometric mean. Its output is not a ranking; it is a normalised table, expressing the magnitude differences within a column on a logarithmic scale, that DecisionMind uses in the next step. Zavadskas and Turskis proposed this form of normalisation in 2008, in a game-theory context, with the aim of stopping classical linear normalisation from overstating large scale differences.

The question this method asks is: what share does this alternative take on a logarithmic scale? Rather than the raw magnitudes themselves, the logarithms of the magnitudes are summed and distributed. Summing logarithms is equivalent to multiplying the original numbers, which is why the method fits naturally with situations where criteria affect one another multiplicatively, such as the relationship between production volume and unit yield. The philosophical consequence follows: a difference between 10 and 100 looks like a tenfold gap on a linear scale, but shrinks to a much smaller difference on a logarithmic one. The method chooses to preserve the proportional relationship between alternatives by softening large absolute differences; this is an advantage where the data's scale difference is large, and a disadvantage where a small difference is genuinely important.

The method proceeds through two steps.

First, finding the reference value. For a benefit criterion, the natural logarithm of every value in the column is taken, and the sum of these logarithms is calculated.

Second, dividing by the sum of the logarithms. For a benefit criterion, each cell's logarithm is divided by the sum of the logarithms. For a cost criterion, a provisional share is first calculated using the benefit formula, then one minus this share is taken and redistributed across the rest of the column. For example, take a cost column with values 54.1, 46.8 and 81.0. Their logarithms are 3.9906, 3.8459 and 4.3944 respectively, summing to 12.2309. The first value's provisional share is 3.9906/12.2309 = 0.3262. One minus this share is 0.6738; when the three alternatives' one-minus values are summed they come to 2.0000, because the three provisional shares already sum to 1. The first alternative's final cost share is 0.6738/2.0000 = 0.3369; the alternative with the lowest cost takes the highest share after this second inversion.

Zero and negative values are undefined in this method. The natural logarithm is undefined at zero, running to negative infinity, and is not defined at all over the real numbers for negative values. The method therefore requires strictly positive data. If the data contains a zero or negative value, the whole column must be shifted into positive territory by adding a fixed constant before the method is applied; this shift amount must be stated in the report, because it affects the result.

The formulas behind each step are given on the DecisionMind method page; this card carries no formulas.

The normalised value shows an alternative's log-scale share on that criterion, and nothing more. As with Linear Sum Normalization, all the shares in a column always sum to 1, but here the share is calculated not from the raw magnitudes directly but from their logarithms. This means that even where the raw gap between two alternatives is very large, the gap between their normalised shares can remain comparatively small. Thus instead of writing:

"This alternative's output is six times the other's, so its share should also be six times as large"

the report should read:

"Because the production difference looks smaller on the log scale, the share difference is correspondingly small; the raw production table should also be shown"

The method requires crisp data: a single strictly positive number per cell. DecisionMind holds no separate fuzzy, grey or intuitionistic extension of this building block; every data type uses its own host method's own normalisation step. You need alternatives in rows, criteria in columns, a number strictly greater than zero in every cell, and direction information for every criterion. The method neither produces weights nor requires them. A minimum of two alternatives is needed; the larger the scale difference between values, the more pronounced the method's compression effect becomes.

If your data is crisp and strictly positive, and there is a large scale difference between criteria, for instance where one criterion is measured in tens and another in thousands, this method is suitable. It sits naturally alongside host methods built on game-theoretic or multiplicative aggregation logic. It should not be used when the data contains a zero or negative value; the data should first be shifted, or min-max normalisation used instead. It is also unsuited to cases where you want a large absolute difference between values to show up in the decision as it stands, because the log scale deliberately shrinks that difference.

Data crisp, strictly positive, large scale difference → Logarithmic Normalization

Data contains zero or negative values → Min-Max Normalization

A large difference should be reflected as it stands → Linear Max or Linear Sum Normalization

The host method is TOPSIS and its classical form is to be kept → Vector Normalization

Result to be read as a share but log compression is not wanted → Linear Sum Normalization

The method's strength is that it stops a single extreme value from dominating the whole table in data sets carrying a large scale difference. Zavadskas and Turskis (2008) showed that this form gives consistent results particularly in methods with multiplicative aggregation. The log scale can preserve proportional relationships (how many times larger one value is than another) more faithfully than a linear scale; this is an advantage where criteria are multiplicative by nature.

Its weakness is that it works only with strictly positive data; it cannot be applied directly to any table containing zero or negative values. Jahan and Edwards (2015) showed that the choice of normalisation form can seriously affect the ranking outcome, with log-based methods among those included in this effect. Vafaei, Ribeiro and Camarinha-Matos (2018) showed with numerical examples that different normalisation forms can give the same table a different order. Log compression can make a large difference that matters in the real world, such as a much cheaper alternative, appear less pronounced in the result; depending on the nature of the data, this can be a disadvantage rather than an advantage.

The most common mistake is applying the method directly when the data contains a zero or negative value; the logarithm is then undefined, and the calculation either collapses or produces an incorrect number unnoticed. A second mistake is interpreting the log-scaled share directly as a raw magnitude difference; two alternatives can have a close share even though their raw values differ substantially. A third is failing to report the shift amount when shifting data into positive territory; different shift amounts give different results. A fourth is using this method with an additive (directly summing) host method and never drawing on the advantage of its multiplicative logic.

The governing principle is this:

Logarithmic Normalization distributes magnitudes on a multiplicative scale; this softens large scale differences, but it can also mask the importance of a small difference that genuinely matters.