Pythagorean fuzzy COPRAS

Three things change. The decision logic stays the same.

Cells. In crisp COPRAS every cell is a single number. Here every cell is a pair: μ, the support degree, and ν, the rejection degree. These two values must satisfy μ² + ν² ≤ 1. The hesitancy margin, π = √(1 − μ² − ν²), is derived from these two degrees; it is not asked of the expert separately. Criterion weights remain crisp numbers and come from outside.

Scale equalisation. Crisp COPRAS turns every column into a share by dividing it by its own total. PF-COPRAS does not do this, because support-rejection pairs already lie between 0 and 1. In its place comes a swap of μ and ν on the cost criterion. DecisionMind builds two separate normalised matrices here: one for the benefit sum, with the cost columns replaced by their complement; the other for the cost sum, with the columns left unchanged. This dual route was chosen because it reproduces the founding application paper's own tables; the detail serves the same purpose as the benefit-sum and cost-sum logic on the base method card.

Score, and the benefit and cost sums. Every weighted cell is converted to a single number with the score function, s = μ² − ν². This step, already a number in crisp COPRAS, here passes first through the support-rejection pair. The average of the scores on the benefit columns gives a "favourable indicator"; the average of the scores on the cost columns gives an "unfavourable indicator". Crisp COPRAS divides these two totals directly; PF-COPRAS folds the unfavourable indicator into the relative significance value through an exponential weighting. This is a combination rule somewhat different from the crisp method's ratio, but it does the same job: rewarding low cost.

Result and defuzzification. The output is a benefit degree, divided by the highest value and converted to a percentage; the best alternative takes 100. This is the same as in crisp COPRAS. Uncertainty collapses to a single number the moment cells are converted to a score; in PF-COPRAS, μ, ν and π all three dissolve into a single score number, and every subsequent step runs on that number.

DecisionMind fixes the score function, the cost complement, and the exponentially weighted relative-significance calculation in PF-COPRAS. Criterion weights come from outside as crisp numbers; the method does not generate weights.

The benefit degree states how far behind an alternative sits, in this set, relative to the best alternative; this is the same as in crisp COPRAS. What differs is that beneath this degree now lies a support-rejection pair that has been reduced to a score. A small benefit-degree gap between two alternatives can close easily if the input pairs' μ and ν values sit close to one another; the robustness of this gap must be tested by looking at how much support and rejection was given on which criterion.

Thus instead of writing:

"PF-COPRAS found this alternative eighty-eight per cent successful"

the report should read:

"With these weights and this alternative set, this is the alternative with the highest benefit-cost balance; the second alternative reaches eighty-eight point four six per cent of the benefit this alternative provides, and this gap depends on how certain the input pairs are"

This extension is used when experts give a judgement both strong support and marked reservation, and you want to report the result directly as a percentage. If the sum of the two degrees exceeds 1, the intuitionistic fuzzy constraint forces these pairs to shrink, because that constraint keeps the sum at no more than 1. Pythagorean fuzzy solves this problem. A measured value is not turned directly into a support-rejection pair. It is first converted into a judgement, and only then are μ and ν derived from separate sources; the detail is on the data-type card. The table must be of a single data type; part crisp and part Pythagorean is not allowed. The base method's exit condition applies here too. If no compromise is acceptable on one criterion, this extension is also compensatory, and lets a low cost mask a high benefit.

Domain violation. Every cell must satisfy μ ∈ [0,1], ν ∈ [0,1] and μ² + ν² ≤ 1. Entering the calculation without this check invalidates the method.

Writing ν as 1 − μ. In that case the sum always comes to exactly 1. The hesitancy margin is zeroed. The extra region the Pythagorean structure offers over the intuitionistic one is never used.

Changing the score function and expecting the same result. s = μ² − ν² is the canonical choice, but not the only one. Computing the benefit and cost sums with a different score can give a different benefit degree.

Reading the benefit degree as an absolute quality percentage. This mistake exists in crisp COPRAS too. It is even more misleading with Pythagorean input, because the same percentage can come from different support-rejection pairs, and a reader who does not see these pairs may mistake the percentage for certainty.

Turning a measured value directly into μ. Scaling a measured quantity such as price or time to 0-1 and writing it as μ, with ν given as its complement, does not produce a judgement. It only conceals crisp data.

The governing principle is this:

A PF-COPRAS result is a summary of the relative balance between the alternatives' benefit and cost sums. A percentage relative to the best is not an absolute measure of success, and the report must show this distinction.