This is our internal-style reference page. It collects model families we use repeatedly, the assumptions we keep explicit, and the typical outputs we report. Bu sayfa bir “başvuru” sayfası gibi düşünülmeli. Sık kullandığımız model ailelerini, açık tuttuğumuz varsayımları ve raporlamada kullandığımız tipik çıktıları bir araya getirir.
For applied examples, see Projects & Demos. For citeable results, see Publications. Uygulamalı örnekler için Projeler & Demolar, atıf verilecek sonuçlar için Yayınlar sayfasına bakabilirsiniz.
We write down the decision setting, constraints, and what is treated as known vs unknown. Karar ortamını, kısıtları ve bilinen/bilinmeyen ayrımını en başta netleştiririz.
Models are checked under parameter shifts and scenario changes, not only on “average” cases. Modelleri sadece “ortalama” senaryoda değil; parametre kaymaları ve farklı senaryolarda da deneriz.
We prefer outputs that can be verified: objective values, constraints, and decision implications. Doğrulanabilir çıktıları tercih ederiz: amaç değerleri, kısıtlar ve karar etkileri.
Problem statement · model definition · parameter table · evaluation protocol · results summary · limitations Problem tanımı · model tanımı · parametre tablosu · değerlendirme protokolü · sonuç özeti · sınırlılıklar
Nash-style interaction models for competing decision-makers. Used when strategic responses matter. Rekabet eden karar vericiler için Nash türü etkileşim modelleri. Stratejik tepki önemliyse kullanılır.
Outputs: equilibrium conditions, sensitivity, stability notes Çıktı: denge koşulları, duyarlılık, istikrar notları
Coalition formation and contribution allocation. Often used with Shapley-style explanations. Koalisyon oluşumu ve katkı dağıtımı. Sıkça Shapley tabanlı açıklamalarla birlikte kullanılır.
Outputs: coalition structure, fairness indicators, payoff allocation Çıktı: koalisyon yapısı, adalet göstergeleri, paylaştırma
Leader–follower settings. Used when one actor moves first and others react under constraints. Lider–takipçi kurgusu. Bir aktör önce karar veriyor ve diğerleri kısıtlarla tepki veriyorsa kullanılır.
Outputs: best-response maps, leader objective, feasibility regions Çıktı: tepki fonksiyonları, lider hedefi, uygunluk bölgeleri
Tabular learning for small/medium state-action spaces. Useful for clear, step-by-step demonstrations. Küçük/orta boyutlu durum-eylem uzaylarında tablo tabanlı öğrenme. Adım adım anlatım için elverişlidir.
Outputs: learned policy, Q-table diagnostics, convergence behavior Çıktı: öğrenilen politika, Q-tablosu teşhisi, yakınsama davranışı
Used when agents learn while affecting each other’s rewards. Reporting focuses on stability and variance. Etmenler öğrenirken birbirinin ödülünü etkiliyorsa kullanılır. Raporlama istikrar ve varyans odaklıdır.
Outputs: policies, reward curves, ablations, failure cases Çıktı: politikalar, ödül eğrileri, ablation, başarısız senaryolar
We define state, action, reward, and constraints explicitly. If the reward is “shaped”, we say so. Durum, eylem, ödül ve kısıtlar açık tanımlanır. Ödül “şekillendirilmişse” bu açıkça yazılır.
Outputs: MDP notes, reward design, evaluation protocol Çıktı: MDP notu, ödül tasarımı, değerlendirme protokolü
Linear / mixed-integer formulations when constraints need to be enforced exactly. Kısıtların “kesin” uygulanması gerekiyorsa doğrusal / karma tamsayılı formülasyonlar.
Outputs: feasibility, objective value, constraint activity Çıktı: uygunluk, amaç değeri, aktif kısıtlar
Used when exact methods are too costly. Reporting includes runtime, variance, and baseline comparison. Kesin yöntemler maliyetliyse kullanılır. Raporlama: süre, varyans ve temel yöntem karşılaştırması.
Outputs: best/mean results, runtime, sensitivity Çıktı: en iyi/ortalama sonuç, süre, duyarlılık
For expensive evaluations. We use GPR where uncertainty estimates are useful in decision-making. Maliyetli değerlendirmelerde kullanılır. GPR, belirsizlik tahmini karar için işe yarıyorsa tercih edilir.
Outputs: prediction + uncertainty, calibration checks Çıktı: tahmin + belirsizlik, kalibrasyon kontrolleri
Tasks and vehicles are often heterogeneous. We keep energy and communication as first-class constraints (not as “afterthought” penalties), and we document stability criteria when coalitions are allowed. Görevler ve araçlar çoğu zaman heterojendir. Enerji ve haberleşme kısıtlarını en baştan modele dahil ederiz (sonradan ceza terimi olarak eklemek yerine). Koalisyon varsa istikrar ölçütlerini mutlaka yazarız.
Typical outputs: allocation map, energy use, delay metrics, stability check Tipik çıktı: tahsis haritası, enerji kullanımı, gecikme metrikleri, istikrar kontrolü
We treat forecasting as a decision input. Evaluation includes errors and the downstream impact. Tahmini karar girdisi olarak ele alırız. Değerlendirme hata metrikleri + karar etkisini içerir.
Efficiency benchmarking and productivity change across time. Reporting emphasizes comparability. Verimlilik kıyaslaması ve zamanla üretkenlik değişimi. Raporlama karşılaştırılabilirlik odaklıdır.
We use these methods for decision briefs: what changes, where to intervene, and what the trade-offs are. Karar özetlerinde kullanırız: ne değişiyor, nereye müdahale edilmeli, ödünleşimler neler.
Mean–variance style baselines when risk/return trade-offs are the focus. Risk–getiri ödünleşimi merkezdeyse mean–variance tabanlı temel yaklaşımlar.
Outputs: weights, risk metrics, turnover notes Çıktı: ağırlıklar, risk metrikleri, işlem sıklığı notu
A structured approach built around daily returns/volatility, transition modeling, and evaluation with risk-oriented metrics. Günlük getiri/volatilite, geçiş modelleme ve risk odaklı metriklerle değerlendirme üzerine kurulu yaklaşım.
Outputs: evolution path, test performance, risk profile Çıktı: evrim yolu, test performansı, risk profili
Surrogates reduce compute cost. We keep uncertainty visible when discussing decisions. Surrogate’lar hesaplama maliyetini düşürür. Karar konuşurken belirsizlik görünür tutulur.
Outputs: backtests, stress tests, calibration checks Çıktı: backtest, stres testleri, kalibrasyon kontrolleri
These entries are meant to keep terminology consistent across projects. When a project uses a variant, we note it on the project page. Bu içerikler proje sayfalarında aynı dili ve kavramları korumak için var. Bir projede farklı bir varyant kullanılıyorsa, o sayfada ayrıca not düşeriz.
