Grey VIKOR (Chang, Liu and Wei, 2001)

Three things change; the idea of the two conditions (acceptable advantage and acceptable stability) does not, but DecisionMind does not compute either of them in this extension.

Cells. In crisp VIKOR every cell is a single number. Here every cell is a lower and an upper bound (a grey number); it carries no most-likely point or distribution. Criterion weights remain crisp numbers, not grey; DecisionMind offers no group mechanism in this extension for combining several decision-makers' scores. The compromise coefficient v is likewise not a parameter open to the user: DecisionMind holds v fixed at 0.5 here, whereas crisp VIKOR and this family's fuzzy and neutrosophic members allow it to be changed.

Scale equalisation. The real difference comes before scale equalisation: DecisionMind whitens every grey cell before the calculation starts, that is, it reduces the lower and upper bound to a single number by averaging them. Crisp VIKOR's linear normalisation (against the best and worst value) is then applied, unchanged, to this single number.

Distance / score / aggregation. Once whitenisation is complete, group utility and individual regret are computed exactly as in crisp VIKOR: S is the sum of the weighted normalised differences, R is the largest of them. There is no separate distance measure specific to the grey structure; whitenisation makes one unnecessary.

Result and defuzzification. The output is already a single number (Q), because defuzzification happened at the very first step. The practical consequence is this: two grey numbers with the same midpoint but different widths produce, in this engine, an identical S, R and Q. A cell with bounds [0.60; 0.60], for instance, and one with bounds [0.30; 0.90] give the same result. The principle warned of on the Grey data-type card, that "whitenisation is a result step, not something added to the data from the outset," is reversed here: DecisionMind's Grey VIKOR performs whitenisation at the input stage. This is a design choice of this engine and must be stated as such in the report; the width of the bounds does not affect the decision, only their midpoint does.

DecisionMind selects the best/worst values, in this extension, from the whitened column, keeps normalisation identical to crisp VIKOR's, and fixes v at 0.5. It does not compute the two conditions (acceptable advantage, acceptable stability); it produces only the Q ranking.

A smaller Q is better, as in crisp VIKOR. But the engine does not test, in this extension, the two conditions described on the base VIKOR card, namely acceptable advantage and acceptable stability; this is where the difference lies. DecisionMind gives only the Q ranking; the user must work out, from the S and R columns and the number of alternatives, against the relevant threshold, whether there is a single compromise solution or a compromise set.

Thus instead of writing:

"According to Grey VIKOR the best alternative is A2"

the report should read:

"With the whitened midpoints and v = 0.5, A2 has the smallest Q; because DecisionMind does not test the acceptable-advantage and acceptable-stability conditions in this extension, whether this gap is large enough must be assessed separately by looking at the S and R columns"

Use this when only a lower and an upper bound are known about criterion values, no value in between is considered any more likely than another, and honesty with this limited information matters. Typical cases: new-market or new-facility decisions made with little data, supplier quotations given as "somewhere between this and that", criteria with a short track record.

If a most-likely value within the bounds is known, the fuzzy extension is more suitable; if the bounds are the ends of a distribution, probabilistic methods should be preferred. Compressing information that has no real bounds into a grey number erases available information, as the Grey data-type card warns. If the table is mixed, DecisionMind requires a single data type; a measured criterion is then also written into a grey cell, with equal bounds, that is, zero width. The base VIKOR's exit condition applies here too: if no compromise is acceptable on one criterion, methods built on dominance should be used instead.

Reading a most-likely value into the bounds that is not there. Declaring the midpoint of a grey number "most likely" and interpreting DecisionMind's whitenisation this way is wrong; the midpoint is only a computational convenience, and the data-type card's warning that "a most-likely value carries no information" still holds.

Entering a lower bound larger than the upper bound. In every cell the lower bound must be smaller than or equal to the upper bound; otherwise whitenisation produces a meaningless number.

Recording only the midpoint, without ever keeping the raw bounds. Even though DecisionMind's engine already whitens internally, the user should enter the raw lower and upper bound and state the data source in the report; discarding the bounds from the outset and writing only the midpoint makes it impossible to recover the width later for a sensitivity check, and hides from the reader the difference between "I applied Grey VIKOR" and "I applied crisp VIKOR".

Assuming that "width is information too, so the engine must be seeing it". DecisionMind's Grey VIKOR does not see width; two grey numbers of different widths with the same midpoint give an identical result. If width is meant to affect the decision, this extension is not the right tool.

The governing principle is this:

In Grey VIKOR the calculation is carried by the midpoint of the bounds, not the bounds themselves; in a problem where width is expected to affect the decision this extension is the wrong tool, and the raw bounds must always be kept alongside the report.