Logarithmic Normalization (Logaritmik Normalizasyon)

Logarithmic Normalization, diğer normalizasyon yapı taşlarından farklı olarak doğrudan toplama değil çarpmaya dayalı bir mantıkla çalışır. Değerleri toplamadan önce logaritmalarını alır, bu yüzden oyun teorisi tabanlı yöntemler ve geometrik ortalamaya dayanan birleştirme adımlarıyla doğal bir uyum taşır. Çıktısı bir sıralama değildir; sütun içindeki büyüklük farklarını log ölçeğinde ifade eden, DecisionMind'ın bir sonraki adımda kullanacağı normalize edilmiş bir tablodur. Zavadskas ve Turskis, 2008'de oyun teorisi bağlamında bu normalizasyon biçimini önermiştir; amaçları, klasik doğrusal normalizasyonun büyük ölçek farklarını olduğundan fazla öne çıkarmasını engellemektir.

Yöntemin sorduğu soru şudur: bu seçeneğin log ölçeğindeki payı ne kadardır? Doğrudan büyüklükler yerine büyüklüklerin logaritmaları toplanır ve paylaştırılır. Logaritma toplamak, orijinal sayıları çarpmaya eşdeğerdir; bu yüzden yöntem, kriterlerin birbirini çarpımsal biçimde etkilediği durumlarla, örneğin üretim miktarı ile birim verim arasındaki ilişkiyle, doğal bir uyum kurar. Felsefi sonucu şudur: 10 ile 100 arasındaki fark, doğrusal ölçekte on kat gibi görünürken log ölçeğinde çok daha küçük bir farka iner. Yöntem, büyük mutlak farkları yumuşatarak seçenekler arasındaki orantısal ilişkiyi korumayı seçer; bu, verinin ölçek farkı büyükse bir avantaj, küçük bir fark gerçekten önemliyse bir dezavantajdır.

Yöntem iki adımda ilerler.

Birinci adım, referans değerin bulunması. Fayda kriterinde sütundaki her değerin doğal logaritması alınır ve bu logaritmaların toplamı hesaplanır.

İkinci adım, log toplamına bölme. Fayda kriterinde her hücrenin logaritması, log toplamına bölünür. Maliyet kriterinde önce fayda formülüyle geçici bir pay hesaplanır, sonra bu payın biri eksiği alınıp sütunun geri kalanına yeniden paylaştırılır. Örnek olarak bir maliyet sütununda değerler 54,1, 46,8 ve 81,0 olsun. Logaritmaları sırasıyla 3,9906, 3,8459 ve 4,3944'tür, toplamları 12,2309 eder. İlk değerin geçici payı 3,9906/12,2309 = 0,3262 olur. Bu payın biri eksiği 0,6738'dir; üç seçeneğin bu eksik değerleri toplandığında 2,0000 çıkar, çünkü üç payın toplamı zaten 1'dir. İlk seçeneğin nihai maliyet payı 0,6738/2,0000 = 0,3369 olur; en düşük maliyete sahip seçenek bu ikinci çevirmeden sonra en yüksek payı alır.

Sıfır ve negatif değerler bu yöntemde tanımsızdır. Doğal logaritma sıfırda tanımsızdır, eksi sonsuza gider; negatif sayılarda ise reel sayılar kümesinde hiç tanımlı değildir. Bu yüzden yöntem yalnız kesinlikle pozitif veri ister. Veride sıfır ya da negatif değer varsa yöntem uygulanmadan önce tüm sütuna sabit bir sayı eklenerek veri pozitif aralığa kaydırılmalıdır; bu kaydırma miktarı raporda belirtilmelidir, çünkü sonucu etkiler.

Adımların formülleri DecisionMind'daki yöntem sayfasında verilir; bu kart formül taşımaz.

Normalize edilmiş değer, bir seçeneğin o kriterdeki log ölçekli payını gösterir; başka bir şey söylemez. Sütundaki tüm paylar toplandığında her zaman 1 eder, tıpkı Linear Sum Normalization'da olduğu gibi; ama pay burada doğrudan büyüklüklerden değil büyüklüklerin logaritmalarından hesaplanmıştır. Bu yüzden iki seçenek arasındaki ham değer farkı çok büyük olsa bile normalize edilmiş pay farkı görece küçük kalabilir. Bu nedenle:

"Bu seçeneğin üretimi diğerinin altı katı, demek ki payı da altı kat büyük olmalı"

yerine:

"Üretim farkı log ölçeğinde daha küçük göründüğü için pay farkı da orantılı biçimde küçüktür; ham üretim tablosu ayrıca gösterilmelidir"

biçiminde yazmak doğrudur.

Yöntem kesin veri ister: her hücrede tek bir kesinlikle pozitif sayı. DecisionMind'da bu yapı taşının bulanık, gri ya da sezgisel veri türlerinde ayrı bir uzantısı yoktur; her veri türü kendi ev sahibi yönteminin kendi normalizasyon adımını kullanır. Elinizde şunlar olmalı: satırlarda seçenekler, sütunlarda kriterler, her hücrede sıfırdan kesinlikle büyük bir sayı ve her kriter için yön bilgisi. Yöntem ağırlık üretmez, ağırlık da istemez. En az iki seçenek gerekir; değerler arasındaki ölçek farkı ne kadar büyükse yöntemin sıkıştırma etkisi o kadar belirginleşir.

Verileriniz kesin ve kesinlikle pozitifse, kriterler arasında büyük ölçek farkı varsa, örneğin bir kriter onlarla diğeri binlerle ölçülüyorsa, bu yöntem uygundur. Oyun teorisi tabanlı ya da çarpımsal birleştirme mantığı taşıyan ev sahibi yöntemlerle doğal bir uyum kurar. Kullanılmaması gereken durum, verinin sıfır ya da negatif değer içermesidir; bu durumda önce veri kaydırılmalı ya da min-max normalizasyonuna geçilmelidir. Değerler arasındaki büyük mutlak farkın kararda olduğu gibi görünmesi isteniyorsa da bu yöntem tercih edilmemelidir, çünkü log ölçek bu farkı kasıtlı olarak küçültür.

Veri kesin, kesinlikle pozitif, ölçek farkı büyük → Logarithmic Normalization

Veri sıfır veya negatif içeriyor → Min-Max Normalization

Büyük fark olduğu gibi yansısın isteniyor → Linear Max ya da Linear Sum Normalization

Ev sahibi yöntem TOPSIS ve klasik biçimi korunacaksa → Vector Normalization

Sonuç bir pay olarak okunacak ama log sıkıştırması istenmiyorsa → Linear Sum Normalization

Yöntemin üstünlüğü, büyük ölçek farklarını taşıyan verilerde tek bir aşırı değerin tüm tabloyu domine etmesini engellemesidir. Zavadskas ve Turskis (2008), bu biçimin özellikle çarpımsal birleştirme yapan yöntemlerde tutarlı sonuç verdiğini göstermiştir. Log ölçek, oransal ilişkileri (bir değerin diğerinin kaç katı olduğunu) doğrusal ölçekten daha sadık koruyabilir; bu, kriterlerin doğası gereği çarpımsal olduğu alanlarda bir avantajdır.

Zayıflığı, yalnız kesinlikle pozitif veriyle çalışmasıdır; sıfır ya da negatif değer içeren hiçbir tabloya doğrudan uygulanamaz. Jahan ve Edwards (2015), normalizasyon biçiminin seçiminin sıralama sonucunu ciddi ölçüde etkileyebileceğini, log tabanlı yöntemlerin de bu etkiye dahil olduğunu göstermiştir. Vafaei, Ribeiro ve Camarinha-Matos (2018), farklı normalizasyon biçimlerinin aynı tabloya farklı sıra verebildiğini sayısal örneklerle göstermiştir. Log sıkıştırması, gerçek dünyada önemli olan büyük bir farkı (örneğin çok daha ucuz bir seçenek) sonuçta daha az belirgin gösterebilir; bu, verinin doğasına göre bir avantaj değil bir dezavantaj olabilir.

En sık hata, veride sıfır ya da negatif değer varken yöntemi doğrudan uygulamaktır; logaritma tanımsız kalır ve hesap çöker ya da fark edilmeden hatalı bir sayı üretir. İkinci hata, log ölçekli payı doğrudan ham büyüklük farkı gibi yorumlamaktır; iki seçeneğin payı yakınsa bile ham değerleri arasında büyük bir fark olabilir. Üçüncü hata, veriyi pozitif aralığa kaydırırken kaydırma miktarını raporlamamaktır; farklı kaydırma miktarları farklı sonuç verir. Dördüncü hata, bu yöntemi toplamsal (doğrudan toplanan) bir ev sahibi yöntemle kullanıp çarpımsal mantığın avantajını hiç kullanmamaktır.

Temel ilke şudur:

Logarithmic Normalization, büyüklükleri çarpımsal bir ölçekte paylaştırır; bu, büyük ölçek farklarını yumuşatır ama küçük bir farkın gerçekte önemli olduğu durumlarda bu önemi de gizleyebilir.