Opsiyon nedir?

Opsiyon, sahibine belirli bir varlığı gelecekte belirli bir kullanım fiyatından alma veya satma hakkı verir. Call opsiyonu alma, put opsiyonu ise satma hakkıdır. Buradaki kritik kelime “hak”tır: Opsiyon sahibi işlemi gerçekleştirmek zorunda değildir.

Burada $S_T$ vade sonundaki varlık fiyatını, $K$ ise kullanım fiyatını gösterir.

Modelin teorik zemini

Black-Scholes, varlık fiyatının geometrik Brown hareketi izlediğini varsayar:

Bu denklemde $\mu$ beklenen getiri oranı, $\sigma$ volatilite ve $dW_t$ rastgele şoku temsil eder. Geometrik yapı sayesinde fiyatın negatif olması engellenir. Model ayrıca işlem maliyeti bulunmadığını, risksiz faiz oranının sabit olduğunu, varlığın sürekli alınıp satılabildiğini ve piyasanın arbitraja izin vermediğini kabul eder.

Asıl matematiksel sihir, opsiyon ile temel varlıktan oluşturulan delta-nötr portföyde gerçekleşir. Portföy çok kısa bir süre için fiyat hareketlerine karşı dengelenirse rastgelelik ortadan kaldırılabilir. Risksiz hale gelen portföy, arbitraj olmaması nedeniyle risksiz faiz oranıyla büyümelidir. Bu fikir şu kısmi diferansiyel denklemi doğurur:

Avrupa tipi, temettüsüz bir call opsiyonunun kapalı form çözümü şöyledir:

$N(x)$ standart normal dağılımın kümülatif dağılım fonksiyonudur. $S_0$ bugünkü fiyatı, $T$ vadeye kalan süreyi ve $r$ sürekli bileşik risksiz faiz oranını belirtir.

Algoritmik uygulama

Formülü Python ile doğrudan hesaplayabiliriz:

from math import log, sqrt, exp, erf

def normal_cdf(x):
    # Standart normal dağılımın kümülatif olasılığını hesaplar.
    return 0.5 * (1.0 + erf(x / sqrt(2.0)))

def black_scholes_call(S, K, T, r, sigma):
    if T <= 0:
        return max(S - K, 0.0)
    if sigma <= 0:
        return max(S - K * exp(-r * T), 0.0)

    d1 = (log(S / K) + (r + 0.5 * sigma**2) * T) / (sigma * sqrt(T))
    d2 = d1 - sigma * sqrt(T)
    return S * normal_cdf(d1) - K * exp(-r * T) * normal_cdf(d2)

fiyat = black_scholes_call(100, 105, 1, 0.04, 0.25)
print(f"Call fiyatı: {fiyat:.2f}")

Fonksiyon önce vade ve volatilite gibi sınır durumlarını denetler; ardından $d_1$ ve $d_2$ değerlerini hesaplayarak teorik call fiyatını üretir. Gerçek uygulamalarda temettü, piyasa spread’i ve veri kalitesi de hesaba katılmalıdır.

Parametreler fiyatı nasıl etkiler?

Modelin en tartışmalı girdisi volatilitedir. Piyasa fiyatından tersine hesaplanan örtük volatilite, yatırımcıların gelecekteki belirsizlik beklentisini yansıtır. Gerçekte volatilite sabit değildir; ayrıca fiyatlarda sıçramalar ve kalın kuyruklar görülebilir. Bu yüzden Black-Scholes nihai gerçek değil, güçlü bir referans modelidir: Mantığı öğrenildiğinde binom ağaçları, Monte Carlo simülasyonu ve stokastik volatilite modelleri çok daha anlaşılır hale gelir.

``

Nesne neden “dilimlenir”?

Bir türetilmiş sınıf nesnesini kavramsal olarak iki parçalı düşünebiliriz:

Temel sınıf türünde değer saklayan bir değişkenin kapasitesi ise yalnızca temel bölüme uygundur. Dolayısıyla aşağıdaki atamada Calisan nesnesinin Yazilimci sınıfına özgü kısmı hedef nesneye sığmaz. C++ bu kısmı hata vermeden dışarıda bırakır.

#include <iostream>
#include <string>

class Calisan {
public:
    std::string ad;

    virtual void tanit() const {
        std::cout << ad << ": Calisan\n";
    }
};

class Yazilimci : public Calisan {
public:
    std::string dil;

    void tanit() const override {
        std::cout << ad << ": " << dil << " gelistiricisi\n";
    }
};

int main() {
    Yazilimci y;
    y.ad = "Ada";
    y.dil = "C++";

    Calisan c = y; // Nesne dilimlenir
    c.tanit();     // Ada: Calisan
}

tanit() sanal olmasına rağmen sonuç değişmez. Çünkü c, artık bağımsız ve gerçek bir Calisan nesnesidir. İçinde Yazilimci kimliği bulunmadığından sanal fonksiyon mekanizmasının çağırabileceği türetilmiş davranış da kalmamıştır. virtual, dilimlenmeyi önlemez; yalnızca nesneye referans veya işaretçi üzerinden erişildiğinde dinamik türü kullanır.

Fonksiyon parametrelerindeki gizli tuzak

Dilimlenme yalnızca açık atamalarda oluşmaz. Temel sınıfı değer olarak kabul eden fonksiyonlar da aynı soruna yol açar:

void bilgiYaz(Calisan calisan) { // Değer ile alınıyor
    calisan.tanit();
}

Yazilimci y;
bilgiYaz(y); // Parametre oluşturulurken dilimlenir

Çözüm, parametreyi çoğunlukla sabit referansla almaktır:

void bilgiYaz(const Calisan& calisan) {
    calisan.tanit(); // Gerçek türe göre çağrı yapılır
}

Bu yöntem hem türetilmiş kimliği korur hem de gereksiz nesne kopyasını engeller. Fonksiyon nesneyi değiştirmeyecekse const kullanılması niyeti açıkça belirtir.

Koleksiyonlarda doğru tür seçimi

std::vector<Calisan> içine Yazilimci eklemek de nesneyi dilimler. Farklı türetilmiş türleri aynı koleksiyonda polimorfik olarak saklamak için akıllı işaretçiler kullanılabilir:

#include <memory>
#include <vector>

std::vector<std::unique_ptr<Calisan>> ekip;
ekip.push_back(std::make_unique<Yazilimci>());

for (const auto& kisi : ekip) {
    kisi->tanit();
}

Burada vektör nesnelerin kendilerini değil, temel sınıf türündeki sahiplik işaretçilerini saklar. Gerçek nesneler türetilmiş türleriyle yaşamaya devam eder. Temel sınıf üzerinden silme yapılacağı için yıkıcının da sanal olması gerekir:

virtual ~Calisan() = default;

Özetle, değer semantiği bilinçli bir temel sınıf kopyası istendiğinde uygundur; polimorfik davranış istendiğinde ise referanslar, işaretçiler ve akıllı işaretçiler tercih edilmelidir. Derleyicinin sessiz kalması işlemin zararsız olduğu anlamına gelmez: Nesnenin yalnızca üst dilimini servis edip geri kalanını mutfakta unutmuş olabilirsiniz.

``

Sorun yalnızca delete unutmak değildir

Manuel kaynak yönetiminde genellikle kaynağın yaşam süresini zihnimizde takip ederiz: kaynağı edin, kullan ve serbest bırak. İdeal akış şöyle düşünülebilir:

Ancak bir exception oluştuğunda fonksiyon normal dönüş noktasına ulaşmaz. C++ çalışma zamanı stack unwinding işlemini başlatır; yani çağrı yığınındaki yerel nesneler geriye doğru yok edilir. Ham işaretçinin kendisi yok olur fakat işaret ettiği dinamik nesne otomatik olarak silinmez.

#include <stdexcept>

void veriyiIsle() {
    int* sayilar = new int[1000];

    sayilar[0] = 42;
    throw std::runtime_error("Dosya okunamadı");

    delete[] sayilar; // Bu satıra hiçbir zaman ulaşılamaz.
}

Buradaki sızıntının matematiksel özeti basittir:

Fonksiyon her çağrıldığında yeni bir blok ayrılır. Hata tekrarlanırsa kayıp miktarı birikir. Tek çağrıdaki sızıntı $M$ bayt ve hatalı çağrı sayısı $n$ ise toplam kayıp yaklaşık $n \times M$ olur.

try-catch ile temizlik yeterli mi?

Kaynağı catch bloğunda temizlemek mümkündür, fakat çözüm hızla kırılganlaşır:

void veriyiIsle() {
    int* sayilar = new int[1000];

    try {
        riskliIslem(sayilar);
    } catch (...) {
        delete[] sayilar;
        throw; // Orijinal exception yeniden gönderilir.
    }

    delete[] sayilar;
}

Bu kod sızıntıyı önleyebilir; ancak hem normal hem de hatalı yol için aynı temizlik işlemi yazılmıştır. Fonksiyona dosya tanıtıcısı, kilit veya ikinci bir bellek bloğu eklendiğinde olası çıkış yolları çoğalır. Ayrıca yanlış sırada temizlik yapmak ya da bir kaynağı iki kez serbest bırakmak mümkündür.

Güvenli çözüm: RAII

RAII, kaynağın yaşam süresini bir nesnenin yaşam süresine bağlar. Kullanıcı manuel olarak yıkıcı çağırmaz; kapsam sona erdiğinde yıkıcı dil tarafından otomatik çağrılır. Exception oluşması da bu davranışı bozmaz.

#include <memory>
#include <stdexcept>

void veriyiIsle() {
    auto sayilar = std::make_unique<int[]>(1000);
    sayilar[0] = 42;

    throw std::runtime_error("İşlem başarısız");
}

std::unique_ptr, dizinin tek sahibidir. Stack unwinding sırasında sayilar nesnesinin yıkıcısı çalışır ve dinamik dizi serbest bırakılır. Açık bir delete[] satırına ihtiyaç kalmaz.

Çoğu durumda dinamik dizi için daha doğal seçenek std::vector kullanmaktır:

#include <vector>

void veriyiIsle() {
    std::vector<int> sayilar(1000);
    sayilar.at(0) = 42;
    riskliIslem(sayilar.data());
}

RAII yalnızca bellek için değildir. Dosyalar, mutex kilitleri, soketler ve veritabanı bağlantıları da aynı ilkeyle kapsüllenebilir. Temel kural şudur: Kaynağı edinen nesne, onu bırakmaktan da sorumlu olmalıdır. Böylece exception geldiğinde temizlik bir dilek değil, kapsam mekanizmasının garantisi olur.

``

Problem neden zordur?

Finansal dolandırıcılık tespiti, klasik bir ikili sınıflandırma problemine benzer. Her işlem için model iki olasılıktan birini tahmin eder:

• $y=0$: Normal işlem
• $y=1$: Dolandırıcılık

Model; tutar, saat, konum, cihaz, iş yeri kategorisi ve müşterinin geçmiş davranışları gibi özellikleri kullanarak $P(y=1\vert x)$ olasılığını hesaplar. Bu olasılık belirlenen eşikten yüksekse işlem incelemeye gönderilir veya geçici olarak durdurulur.

Asıl sorun, veri kümesinin son derece dengesiz olmasıdır. Bir milyon işlem içinde yalnızca bin dolandırıcılık bulunabilir. Her işleme “normal” diyen tembel bir model, %99,9 doğruluk elde eder; fakat tek bir suçluyu bile yakalayamaz. Yani yüksek accuracy, burada tek başına etkileyici görünen ama pek işe yaramayan bir vitrindir.

Precision ve recall arasındaki denge şu formülle özetlenebilir:

Model neye bakar?

Ham işlem verileri çoğu zaman yeterli değildir. Etkili sistemler, davranışı temsil eden yeni özellikler üretir. Örneğin müşterinin son bir saatte yaptığı işlem sayısı, mevcut tutarın ortalama harcamaya oranı veya ardışık işlemler arasındaki coğrafi mesafe hesaplanabilir.

Örneğin İstanbul’da yapılan bir işlemin beş dakika ardından Tokyo’da fiziksel kart kullanılması, “imkânsız seyahat” sinyalidir. Yine de tek bir sinyal kesin suç kanıtı değildir. Müşteri VPN kullanıyor, seyahat ediyor veya alışılmadık ama tamamen meşru bir alışveriş yapıyor olabilir.

Hangi algoritmalar kullanılır?

Lojistik regresyon açıklanabilir ve hızlı bir başlangıç modelidir. Karar ağaçları, Random Forest ve özellikle XGBoost gibi yöntemler karmaşık ilişkileri daha iyi yakalayabilir. Etiketlenmiş dolandırıcılık örneklerinin az olduğu durumlarda Isolation Forest veya Autoencoder gibi anomali tespiti yöntemleri devreye girer.

Aşağıdaki örnek, dengesiz sınıflara ağırlık vererek basit bir model eğitir:

from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import classification_report

# Az görülen dolandırıcılık sınıfına otomatik olarak daha fazla önem verir.
model = RandomForestClassifier(
    n_estimators=200,
    class_weight='balanced',
    random_state=42
)

model.fit(X_train, y_train)
predictions = model.predict(X_test)
print(classification_report(y_test, predictions))

class_weight='balanced', azınlık sınıfındaki hataların model açısından daha maliyetli olmasını sağlar. Alternatif olarak SMOTE ile sentetik örnek üretilebilir; ancak zaman sıralı finans verilerinde veri sızıntısını önlemek için eğitim ve test ayrımı kronolojik yapılmalıdır.

Gerçek sistemlerde karar nasıl verilir?

Üretim ortamında model genellikle tek başına karar vermez. Model skoru, kural motoru ve risk politikaları birlikte çalışır. Düşük riskli işlem onaylanabilir, orta riskli işlem için ek doğrulama istenebilir, yüksek riskli işlem ise engellenip uzman incelemesine gönderilebilir.

Dolandırıcıların davranışları sürekli değiştiği için model de düzenli olarak izlenmeli ve yeniden eğitilmelidir. Buna concept drift denir. Başarılı bir sistem yalnızca geçmiş suçları ezberlemez; yeni saldırı biçimlerine uyum sağlar, yanlış alarmları kontrol eder ve kararlarının nedenini açıklayabilir. Kısacası makine öğrenmesi dijital bir dedektiftir; fakat iyi veri, doğru metrikler ve insan denetimi olmadan büyüteci ters tutabilir.

El-göz kalibrasyonu neyi çözer?

El-göz kalibrasyonunun amacı kamera koordinat sistemi ile robotun uç efektörü veya tabanı arasındaki dönüşümü bulmaktır. Kamera robotun bileğine takılıysa eye-in-hand, çalışma alanını dışarıdan izliyorsa eye-to-hand düzeni kullanılır.

Bir rijit dönüşüm, dönme matrisi $R$ ve öteleme vektörü $t$ ile ifade edilir:

Klasik hand-eye problemi çoğunlukla şu denklem üzerinden çözülür:

Burada $A_i$ robotun iki poz arasındaki hareketini, $B_i$ kameranın aynı pozlar arasındaki hareketini, $X$ ise aranan kamera-robot dönüşümünü temsil eder. Ölçümler gürültülü olduğundan eşitlik pratikte tam sağlanmaz; algoritma en uygun $X$ dönüşümünü tahmin eder.

Küçük açı, büyük sorun

Dönüş hataları özellikle sinsidir. Yaklaşık $theta$ radyanlık açısal hata, kameradan $d$ uzaklıktaki bir hedefte şu büyüklükte konum sapması oluşturabilir:

Örneğin $theta = 0.5° \approx 0.0087$ radyan ve $d = 1$ metre ise sapma yaklaşık $8.7$ milimetredir. Hassas montaj yapan bir robot için bu değer oldukça büyüktür. Üstelik TCP yanlış tanımlanmışsa hata, robot bileğini döndürdükçe yön değiştiren dairesel bir davranış gösterebilir.

Aşağıdaki Python kodu, küçük açı yaklaşımıyla uzaklığa bağlı yanal hatayı hesaplar:

import math

def lateral_error(distance_m, angle_deg):
    # Dereceyi radyana çevirip yaklaşık yanal sapmayı bulur.
    angle_rad = math.radians(angle_deg)
    return distance_m * angle_rad

for distance in [0.25, 0.5, 1.0]:
    error_m = lateral_error(distance, 0.5)
    print(f"{distance:.2f} m -> {error_m * 1000:.2f} mm")

Bu basit hesap, kalibrasyon raporunda küçük görünen açısal artıkların neden çalışma alanının uzak bölgelerinde ciddi sonuçlar doğurduğunu gösterir.

Kalibrasyon neden kötü çıkar?

En yaygın nedenlerden biri, örnek pozların birbirine fazla benzemesidir. Robot yalnızca doğrusal hareket ettirilirse sistem bazı dönüş bileşenlerini yeterince gözlemleyemez. Farklı eksenlerde dönüşler, çeşitli mesafeler ve çalışma hacmini kapsayan pozlar kullanılmalıdır. Bulanık görüntü, hatalı kalibrasyon deseni ölçüsü, gevşek kamera bağlantısı ve otomatik odak değişimi de sonucu bozar.

Yalnızca düşük yeniden izdüşüm hatasına güvenmek de tehlikelidir. Kamera iç kalibrasyonu başarılı görünürken kamera-robot dönüşümü yanlış olabilir. Bu nedenle doğrulama, eğitimde kullanılmamış pozlarla yapılmalıdır.

Sağlam doğrulama stratejisi

Robotu bilinen kontrol noktalarına yönlendirin ve konum hatasını her eksen için ölçün. Ardından farklı bilek açılarını, yakın-uzak hedefleri ve görüntü merkezinden kenarlara doğru noktaları test edin. Hata mesafeyle büyüyorsa dönme; yaklaşık sabit kalıyorsa öteleme problemi düşünülmelidir.

Son olarak medyan hata kadar maksimum hatayı da raporlayın. Ortalama değer güzel görünürken tek bir uç poz üretim hattını durdurabilir. İyi el-göz koordinasyonu, yalnızca bir kalibrasyon matrisi hesaplamak değil; mekanik sağlamlık, zaman senkronizasyonu, çeşitli örnekleme ve bağımsız doğrulamayı birlikte yönetmektir.

``

Tek Sunucu Neden Yetmez?

Her oyuncu hareket, yetenek kullanımı, envanter yönetimi ve sohbet gibi olaylar üretir. Oyuncu başına saniyede ortalama $r$ mesaj, eşzamanlı oyuncu sayısı da $N$ ise sistemin karşılaması gereken yaklaşık mesaj yükü şöyledir:

Örneğin 10.000 oyuncunun saniyede 15 mesaj ürettiği bir dünyada sunucular saniyede yaklaşık 150.000 mesajı işlemelidir. Üstelik bazı hareketler çevredeki diğer oyunculara da gönderilir. Her veriyi herkese yayınlamak maliyeti hızla $O(N^2)$ seviyesine taşıyabileceğinden MMORPG mimarileri dünyayı mantıksal parçalara ayırır.

Sunucu Katmanları

Oyuncu genellikle doğrudan oyun dünyasının merkezine bağlanmaz. İstek, uzmanlaşmış servislerden oluşan bir yolculuk yapar.

Bu ayrım sayesinde sohbet sistemindeki yoğunluk savaş hesaplamalarını durdurmaz. Ayrıca her servis bağımsız biçimde ölçeklenebilir.

Shard, Zone ve Instance Farkı

Shard, aynı oyunun ayrı bir kopyasıdır; oyuncular bunu genellikle “sunucu seçimi” olarak görür. Zone, tek dünyanın coğrafi bölümlere ayrılmasıdır. Instance ise zindan gibi belirli bir grup için geçici oluşturulan özel alandır.

Bir karakter bölge sınırını geçtiğinde eski zone sunucusu karakter durumunu yeni sunucuya aktarır. Bu handoff işlemi sırasında iki sunucunun kısa süreli koordinasyon kurması gerekir; aksi hâlde karakter kopyalanabilir veya kaybolabilir.

Interest Management: Herkesi Herkese Gösterme

Bir oyuncunun kıtanın diğer ucundaki hareketleri bilmesine gerek yoktur. Sunucu, dünyayı hücrelere böler ve yalnızca görüş alanındaki nesneleri gönderir. Görüş yarıçapı $d$ olan bir oyuncu için ilgi alanı kabaca $A = \pi d^2$ olur.

Basitleştirilmiş bir yayın mantığı şöyle yazılabilir:

def broadcast_movement(player, spatial_grid):
    nearby = spatial_grid.query(player.position, radius=80)

    for entity in nearby:
        if entity.id != player.id:
            entity.connection.send({
                "type": "movement",
                "player_id": player.id,
                "position": player.position
            })

Bu kod, hareket paketini yalnızca yakındaki varlıklara göndererek bant genişliği ve işlemci tüketimini azaltır. Gerçek sistemlerde grid, quadtree veya spatial hashing kullanılabilir.

Sunucu Otoritesi ve Tutarlılık

İstemciye tamamen güvenilirse oyuncu “Ben ışınlandım ve boss’u tek vuruşta yendim” diyebilir. Bu nedenle çoğu MMORPG server-authoritative çalışır: İstemci niyeti bildirir, sonucu sunucu hesaplar. İstemci gecikmeyi gizlemek için tahmin yapabilir; ancak son söz sunucudadır.

Tüm veriler aynı tutarlılık seviyesine ihtiyaç duymaz. Hasar ve eşya transferi güçlü tutarlılık isterken oyuncunun birkaç santimetrelik konumu eventual consistency ile yönetilebilir. Kritik ekonomi işlemlerinde idempotency anahtarları ve veritabanı transaction’ları, aynı satın alma paketinin iki kez işlenmesini önler.

Gecikme, Tick ve Dayanıklılık

Zone sunucuları dünyayı belirli aralıklarla günceller. Tick hızı $f$ ise bir tick süresi yaklaşık $T = 1/f$ saniyedir. 20 Hz çalışan bir sistem dünyayı her 50 milisaniyede bir hesaplar.

Sunucu çökmesine karşı karakter durumu periyodik kaydedilir; kritik olaylar mesaj kuyruğuna veya event log’a yazılır. Load balancer yeni bağlantıları sağlıklı sunuculara gönderirken izleme araçları CPU, gecikme ve paket kaybını takip eder. Sonuçta kesintisiz görünen fantastik dünya; bölümlendirme, ilgi alanı filtreleme, otoriter simülasyon ve dikkatli veri yönetiminin birlikte yaptığı oldukça gerçek bir mühendislik büyüsüdür.

Bir finansal piyasayı yalnızca son işlem fiyatından izlemek, futbol maçını sadece skor tabelasından takip etmeye benzer. Order book, yani emir defteri ise sahanın tamamını gösterir: Hangi fiyatlarda alıcılar bekliyor, satıcılar nerede yoğunlaşıyor ve likidite hangi tarafta inceliyor? Doğru algoritmalarla bu hareketli tabloyu inceleyerek piyasanın kısa vadeli yapısı hakkında değerli ipuçları çıkarabiliriz.

``

Emir defterinin temel mantığı

Emir defteri, gerçekleşmeyi bekleyen limit alış ve satış emirlerinin fiyat seviyelerine göre sıralanmış hâlidir. En yüksek alış fiyatına best bid, en düşük satış fiyatına ise best ask denir. Bu iki fiyat arasındaki fark spread olarak tanımlanır:

Spread küçüldükçe piyasanın genellikle daha likit olduğu düşünülür. Ancak tek başına spread yeterli değildir. En iyi fiyat seviyesinde yalnızca birkaç birim emir varsa büyük bir piyasa emri fiyatı hızla kaydırabilir.

Çoğu borsada eşleştirme motoru fiyat-zaman önceliği kullanır. Daha iyi fiyat önceliklidir; aynı fiyattaki emirler arasında önce giren emir önce gerçekleşir. Piyasa emirleri ise beklemez, defterdeki uygun limit emirlerini tüketir.

Dengesizlik ve mikro fiyat

Defter analizinin popüler ölçülerinden biri order book imbalance değeridir. En iyi seviyedeki alış miktarı $B$, satış miktarı $A$ olsun:

$I$ değeri $1$ seviyesine yaklaştığında alış tarafı, $-1$ seviyesine yaklaştığında satış tarafı daha ağırdır. Sıfıra yakın değerler dengeli bir görünüm sunar. Bununla birlikte büyük alış miktarı kesin yükseliş anlamına gelmez; emir gerçekleşmeden iptal edilebilir.

Bir başka ölçü olan mikro fiyat, orta noktayı mevcut miktarlarla ağırlıklandırır:

Mikro fiyat orta fiyattan yukarıdaysa alış baskısının, aşağıdaysa satış baskısının daha güçlü olduğu düşünülebilir.

Python ile basit analiz

Aşağıdaki fonksiyon, en iyi alış ve satış seviyelerinden spread, orta fiyat, dengesizlik ve mikro fiyat hesaplar:

def book_metrics(bids, asks):
    # Her eleman: (fiyat, miktar)
    best_bid, bid_qty = max(bids, key=lambda x: x[0])
    best_ask, ask_qty = min(asks, key=lambda x: x[0])

    spread = best_ask - best_bid
    midpoint = (best_bid + best_ask) / 2
    total_qty = bid_qty + ask_qty

    imbalance = (bid_qty - ask_qty) / total_qty
    microprice = (
        best_ask * bid_qty + best_bid * ask_qty
    ) / total_qty

    return {
        'spread': spread,
        'midpoint': midpoint,
        'imbalance': imbalance,
        'microprice': microprice
    }

bids = [(99.90, 12), (99.80, 25)]
asks = [(100.00, 5), (100.10, 18)]
print(book_metrics(bids, asks))

Bu örnek yalnızca ilk seviyeyi inceler. Gerçek sistemlerde ilk 5, 10 veya 20 fiyat seviyesi ağırlıklı olarak değerlendirilir. Yakın seviyelere daha fazla önem vermek için $w_i=e^{-\lambda i}$ gibi azalan bir ağırlık kullanılabilir.

Gürültü, spoofing ve doğru yorum

Order book bir niyet tablosudur; gerçekleşmiş işlemlerin kaydı değildir. Büyük bir emir güçlü destek gibi görünürken aniden iptal edilebilir. Spoofing, yatırımcıları yanıltmak amacıyla büyük emir gösterip bunları gerçekleşmeden kaldırma davranışıdır. Bu nedenle algoritma; emir ekleme, iptal ve gerçekleşme hızlarını birlikte izlemelidir.

Sağlam bir yaklaşım, order book verisini işlem hacmi, order flow imbalance ve fiyat değişimiyle birleştirir. Ayrıca sonuçlar farklı piyasa koşullarında geriye dönük test edilmelidir. Emir defteri geleceği söyleyen kristal küre değildir; fakat doğru ölçümlerle piyasanın kısa vadeli baskısını gösteren oldukça hassas bir radar olabilir.

``

DDA neden kullanılır?

Geleneksel oyunlarda oyuncu başlangıçta kolay, normal veya zor gibi sabit bir seviye seçer. Ancak bir oyuncunun nişan alma becerisi iyi, kaynak yönetimi kötü olabilir. Üstelik beceri seviyesi oyun boyunca değişir. Sabit seçim, bu farklılıkları yakalamakta yetersiz kalır.

DDA’nın temel amacı oyuncuyu akış bölgesinde tutmaktır. Akış teorisine göre görev çok kolaysa sıkılma, çok zorsa kaygı oluşur. İdeal durumda zorluk $D$, oyuncu becerisi $S$ değerine yakın olmalıdır:

Aradaki fark büyüdükçe deneyim bozulabilir. Bunu basit bir denge hatasıyla gösterebiliriz:

$E$ büyük ve pozitifse oyun kolay, büyük ve negatifse oyun zor demektir. Sistem, $E$ değerini sıfıra yaklaştırmaya çalışır.

Sistem oyuncuyu nasıl ölçer?

Önce anlamlı sinyaller toplanır. Ölüm sayısı, isabet oranı, bölüm tamamlama süresi, kalan sağlık, kullanılan yardım miktarı ve başarısız deneme sayısı bunlardan bazılarıdır. Tek bir ölçüte güvenmek yanıltıcıdır; hızlı oynayan biri dikkatsiz, yavaş oynayan biri ise keşif meraklısı olabilir.

Ölçümler normalize edilerek birleşik bir beceri puanı üretilebilir:

Burada $A$ isabet oranını, $H$ hayatta kalma başarısını, $T$ ise hedef süreye göre performansı temsil eder. Katsayılar oyunun önceliklerine göre değiştirilir.

Basit bir uygulama

Aşağıdaki Python sınıfı, son performans puanlarının ortalamasını alır ve hedef zorluğu küçük adımlarla günceller:

class DifficultyManager:
    def __init__(self):
        self.difficulty = 0.5
        self.history = []

    def update(self, accuracy, survival, speed):
        score = 0.4 * accuracy + 0.3 * survival + 0.3 * speed
        self.history.append(score)
        self.history = self.history[-5:]

        skill = sum(self.history) / len(self.history)
        change = (skill - self.difficulty) * 0.2
        self.difficulty = max(0.1, min(1.0, self.difficulty + change))
        return self.difficulty

Son beş sonucun kullanılması, tek bir kötü maçın sistemi paniğe sürüklemesini engeller. 0.2 katsayısı değişimin hızını sınırlar; böylece düşmanlar bir anda salyangozdan terminatöre dönüşmez. Döndürülen değer düşman sağlığına, yapay zekâ tepki süresine veya kaynak miktarına uygulanabilir.

Neler ayarlanabilir?

İyi bir DDA sistemi hile yapıyormuş gibi görünmemelidir. Oyuncu sırf başarılı olduğu için kurşunlarının sebepsiz yere kaçtığını hissederse sistem güven kaybeder. Bu nedenle değişiklikler yumuşak, sınırlı ve mümkünse oyun dünyası içinde anlamlı olmalıdır.

Sonuç olarak DDA yalnızca düşmanların canını artıran bir düğme değildir; ölçüm, modelleme ve deneyim tasarımının birleşimidir. En başarılı sistem oyuncuyu cezalandırmaz veya kayırmaz. Onun becerisine uygun, heyecanlı ve adil görünen bir mücadeleyi sessizce sahneye koyar.

Roguelike oyunlarda ölüm, kısa bir yükleme ekranından çok daha fazlasıdır. Saatlerdir geliştirdiğiniz karakterin, topladığınız eşyaların ve kurduğunuz planların tek bir hatayla silinmesi mümkündür. Kalıcı ölüm olarak bilinen bu mekanik, oyuncuya yalnızca kaybetme korkusu yaşatmaz; karar verme, öğrenme ve risk değerlendirme biçimini de kökten değiştirir. ``

Ölüm neden bu kadar önemlidir?

Geleneksel oyunlarda ölüm çoğunlukla geçici bir aksaklıktır. Oyuncu kayıt noktasına döner ve aynı bölümü küçük değişikliklerle tekrarlar. Roguelike türünde ise ölüm, mevcut koşunun sonudur. Bu nedenle oyuncu yalnızca ekrandaki düşmanla değil, verdiği kararların geri döndürülemezliğiyle de mücadele eder.

Bu fark, roguelike felsefesinin merkezindeki fikri ortaya çıkarır: Oyuncu karakteri kaybedebilir, fakat öğrendiklerini kaybetmez. Bir canavarın saldırı düzenini, zehrin etkisini veya hangi eşyanın hangi durumda değerli olduğunu öğrenmek, görünmeyen bir gelişim sistemidir.

Riskin matematiği

Oyuncu bir odaya girmeden önce çoğu zaman sezgisel bir beklenen değer hesabı yapar. Bir kararın yaklaşık değeri şöyle gösterilebilir:

Burada $P_b$ başarı olasılığını, $O$ elde edilecek ödülü, $P_k$ kayıp olasılığını ve $M$ kaybın maliyetini temsil eder. Kalıcı ölümde $M$ çok büyüktür; çünkü yalnızca birkaç sağlık puanı değil, bütün koşu tehlikededir. Bu yüzden ödül yüksek olsa bile düşük başarı olasılığı oyuncuyu geri çekilmeye yöneltebilir.

Ancak insan zihni kusursuz bir hesap makinesi değildir. Nadir bir eşya görüldüğünde açgözlülük, uzun süren başarılı bir koşuda aşırı güven veya son anda gelen panik matematiksel değerlendirmeyi bozar. Roguelike oyunlar tam da bu duygusal çatışmadan beslenir: Mantık kapıyı kapatmayı söylerken merak içeride ne olduğunu fısıldar.

Basit bir risk modeli

Bir oyunda karar puanlaması aşağıdaki gibi modellenebilir:

def risk_puani(odul, basari_ihtimali, kayip, kaynak_orani):
    beklenen_kazanc = odul * basari_ihtimali
    beklenen_kayip = kayip * (1 - basari_ihtimali)

    # Kaynaklar azaldıkça aynı tehlike daha ciddi kabul edilir.
    baski_carpani = 1 + (1 - kaynak_orani)
    return beklenen_kazanc - beklenen_kayip * baski_carpani

Bu kod, ödül ile olası kaybı karşılaştırır. kaynak_orani, oyuncunun sağlık, iksir veya mühimmat gibi kaynaklarının ne kadarının kaldığını belirtir. Sonuç negatifse çatışmadan kaçınmak mantıklı olabilir. Elbette iyi bir roguelike, bütün bilgileri açıkça sunmaz; belirsizlik, kararın heyecanını artırır.

Korkaklık mı, ustalık mı?

Kalıcı ölüm başlangıçta oyuncuyu aşırı temkinli yapabilir. Her sandık tuzak, her koridor tehdit gibi görünür. Deneyim arttıkça temkin yerini hesaplanmış cesarete bırakır. Usta oyuncu hiçbir risk almayan kişi değildir; hangi riskin gerekli olduğunu anlayan kişidir.

Bu süreçte davranışlar belirgin biçimde değişir:

• Kaynaklar hemen tüketilmek yerine kritik anlar için saklanır.
• Bilinmeyen düşmanlara doğrudan saldırmak yerine gözlem yapılır.
• Kaçış, başarısızlık değil stratejik bir araç olarak görülür.
• Kısa vadeli ödüller, uzun vadeli hayatta kalmayla karşılaştırılır.
• Her ölümden sonra neden-sonuç ilişkisi kurulmaya çalışılır.

Yenilginin anlamı

Roguelike türü, başarısızlığı oyunun karşıtı olmaktan çıkarıp oyunun parçasına dönüştürür. Adil tasarlanmış bir ölüm, oyuncuya cezadan çok ders verir: Yanlış eşya mı seçildi, gereksiz çatışmaya mı girildi, yoksa bilinmeyen bir mekanik mi gözden kaçtı?

Sonuç olarak kalıcı ölüm, yapay bir zorluk düğmesi değildir. Oyuncunun eşyalarla, zamanla ve kendi duygularıyla ilişkisini değiştiren felsefi bir tasarım tercihidir. Karakterler tekrar tekrar ölürken oyuncu giderek daha dikkatli, bilgili ve soğukkanlı hâle gelir. Roguelike deneyiminin gerçek kahramanı ekrandaki savaşçı değil, her yenilgiden sonra yeniden düşünen oyuncudur.

Bir yıldızın önünden geçen gezegen, yıldız ışığının çok küçük bir bölümünü engeller. Teleskop açısından bu olay, parlaklıkta düzenli aralıklarla tekrarlanan sığ düşüşler olarak görünür. Ancak yıldız lekeleri, cihaz gürültüsü ve veri boşlukları da benzer izler bırakabilir. Geçiş fotometrisinin asıl heyecanı, bu kozmik saklambaç oyununu istatistik ve algoritmalar yardımıyla çözmektir.

``

Geçiş sinyalinin fiziği

Bir gezegen yıldız diskinin önünden geçtiğinde ölçülen göreli parlaklık azalmasına geçiş derinliği denir. Basitçe yıldız ve gezegen disklerini düzgün daireler kabul edersek:

Burada $R_p$ gezegenin, $R_*$ yıldızın yarıçapıdır. Örneğin yarıçapı yıldızın onda biri olan bir gezegen yaklaşık $0.01$, yani yüzde bir parlaklık düşüşü oluşturur. Dünya büyüklüğündeki gezegenlerde bu oran çok daha küçüktür; dolayısıyla hassas ölçüm gerekir.

Algoritma yalnızca düşüşün derinliğini değil, süresini ve tekrar aralığını da inceler. Ardışık geçişlerin arasındaki zaman gezegenin yörünge periyodu $P$ hakkında bilgi verir.

Ham veriden temiz ışık eğrisine

Analiz; zaman ve akı, yani parlaklık ölçümleriyle başlar. Önce eksik veya geçersiz değerler kaldırılır. Ardından akı medyana bölünerek yıldızın normal parlaklığı yaklaşık 1 yapılır. Teleskobun sıcaklık değişimi ya da yıldızın uzun dönemli etkinliği gibi yavaş eğilimler de çıkarılmalıdır. Bu adıma detrending denir.

import numpy as np
from scipy.signal import savgol_filter

# time ve flux teleskoptan alınmış NumPy dizileridir.
valid = np.isfinite(time) & np.isfinite(flux)
time_clean = time[valid]
flux_clean = flux[valid]

normalized = flux_clean / np.median(flux_clean)
trend = savgol_filter(normalized, 301, 2)
flat_flux = normalized / trend

Bu kod geçersiz ölçümleri temizler, ışık eğrisini normalize eder ve Savitzky–Golay filtresiyle yavaş değişen eğilimi tahmin eder. Pencere boyutu yanlış seçilirse gerçek geçişler de silinebileceği için beklenen geçiş süresinden belirgin biçimde büyük olmalıdır.

Periyodik düşüşleri BLS ile aramak

Geçişler sinüs dalgasına benzemez; daha çok kısa süreli kutu biçimli çukurlardır. Bu nedenle yaygın çözüm Box Least Squares (BLS) algoritmasıdır. BLS, çok sayıda aday periyodu dener, veriyi o periyoda göre katlar ve hangi kutu modelinin gözlemleri en iyi açıkladığını hesaplar.

Sinyalin güvenilirliği kabaca şu oranla değerlendirilebilir:

Burada $\sigma$ ölçüm saçılımı, $N_{in}$ ise geçiş içinde kalan veri noktalarının sayısıdır.

from astropy.timeseries import BoxLeastSquares

model = BoxLeastSquares(time_clean, flat_flux)
periods = np.linspace(0.5, 30, 10000)
durations = np.linspace(0.05, 0.3, 10)
result = model.power(periods, durations)

best = np.argmax(result.power)
print('Aday periyot:', result.period[best])
print('Geçiş derinliği:', result.depth[best])

Kod, 0,5 ile 30 gün arasındaki periyotları tarar ve en güçlü kutu biçimli sinyali seçer. Bulunan zirve doğrudan gezegen kanıtı değildir; yalnızca incelenmeye değer bir adaydır.

Yanlış pozitifleri elemek

Tutulmalı çift yıldızlar gezegen geçişlerini taklit edebilir. Bu nedenle tek ve çift numaralı geçişlerin derinlikleri karşılaştırılır. Belirgin fark varsa iki yıldızın karşılıklı tutulması söz konusu olabilir. Geçiş sırasında yıldız görüntüsünün merkezinin kayması da sinyalin yakındaki başka bir yıldızdan geldiğini gösterebilir.

Son aşamada aday periyotla katlanmış ışık eğrisi görselleştirilir, farklı gözlemlerle doğrulanır ve gerekirse tayfsal hız ölçümleri yapılır. Böylece birkaç yüz milyonda birlik parlaklık değişimleri, uzak bir dünyanın yarıçapı ve yörüngesi hakkında bilgi veren güçlü bir astronomik kanıta dönüşür.