Archive

Archive for the ‘Uncategorized’ Category

Altılı yedili çipetpet pet pet…

October 24th, 2013

Cryptic writings yazı dizisi bir kenarda bekleye dursun. Bir süredir dahil olduğum at yarışı dünyasından düzenli bir şeyler paylaşmak istedim.

Pek çok bilgisayar mühendisinin hayalidir muhtemelen program yazıp altılıyı, sayısalı vesaireyi tutturmak… Naçizane ben de bu iş için amatör bir program yaptım. 4-5 haftadır yaptığım testlerde fena sayılmayacak sıralamalar yaptığını gördüğümden program ile çıkardığım sıralamaları günlük olarak buradan paylaşmaya karar verdim.

Program şimdilik şu kriterleri baz alarak yarışlarda atları sıralıyor,

1 . Tahmin performansı : Beygir.com üzerinde yapılmış tahminlerin tahminciler değişik kriterlere göre başarı puanları ile harmanlanarak üretilmiş sıralama.

2 . Kıyas performansı : İlgili yarışı koşan atların birbirleri arasında yapmış oldukları yarışlarda oluşan sıralama. Burada atlar doğrudan birbirleri ile yarışmamış olsalar da sistem sıralama yapabiliyor. Örn. A – B – C – D diye 4 at olsun. Ve bu 4 atlar için şöyle yarışlar söz konusu olsun

1 – A B’yi 50 salise geçmiş
2 – C D’ye 100 salise geçilmiş
3 – A D’yi 50 salise geçmiş

Normalde burada her iki at arasında kıyaslama yapabilmek için 4′ün 2′li kombinasyonu kadar yani 6 adet ortak yarışa ihtiyaç var. (A B) (A C) (A D) (B C) (B D) (C D) şeklinde olacak bunlar. Ancak çoğu zaman bu mümkün değil. Çözüm yöntemim şu : Her bir at bir graph’ın düğümü, her bir yarış ta bu düğümler arasındaki kenarlar olacak şekilde bir directed graph çiziyorum. Bu graph içerisinde dependency sıralarını belirlemekte de kullanılan topological sort algoritmasından faydalanarak sıralama yapıyorum.

Pek tabii şu an oldukça basit. Yarışların tempoları, atların pist tercihleri, istatistiki olarak atın performansı dışında olan koşuların değerlendirmeye alınmaması, sadece o gün koşan atlar üzerinden değil o gün koşmayacak atlar üzerinden de karşılaştırma yapılabilmesi gibi geliştirmeye açık pek çok nokta mevcut.

3. Performans : Bu kısım şu an çok iyi çalışmamakla beraber ileride geliştirilmeye en açık bölümü programın. Burada sistem her at için bir neural network’ü geçmiş yarışları potansiyel jokey / kilo kombinasyonları ile zenginleştirerek eğitiyor. Daha sonra da mevcut yarış koşulları için sistemden bir süre tahmini yapmasını bekliyor. At geçmişte şu anki mesafedeki ve pistteki yarıştan çok sayıda koşmadı ise burada şu problem ortaya çıkıyor. Koşu mesafeleri ile koşu derecelerini doğru orantı ile kullanıp mevcut koşullarda tahmini bir derece elde etmek mümkün değil. Bunun yanı sıra atın değişen jokeyi, taşıdığı yük, yaşını da hesaba katmak gerekiyor. Misal burada elimde en basitinden şu an atların doğum tarihleri yok, TJK bu bilgiyi servislerinde dönmüyor.

Şu an için bu kriterin ağırlığı genel tahmini üretmede oldukça düşük ancak ileride programın bomba özelliği olmaya aday. Yine kullanılan neural network’ün ses tanımada da kullanılan çok katmanlı bir neural network’e çevrilmesi başarı yüzdesini arttırabilir.

4. Jokey performansı : Bu basit bir istatistik, jokeyin daha önce katıldığı yarışlarda kazandığı tabela derecelerinden elde edilen puanlar kullanılıyor.

5. Antrenör performansı : Jokeye benzer, antrenör için hesaplanıyor.

6. Baba performansı : Atın baba tarafından kardeşlerinin performansları kullanılıyor.

7. Ana performansı : Atın ana tarafından kardeşlerinin performansları kullanılıyor. İlginç bir şekilde arap atlarının yarıştığı ayaklarda oldukça iyi sonuçlar veriyor. Bunun da sebebi aslında benim kardeşlere bakarken atın kendisini ayıklamıyor olmam. Yani bir nevi bu kriter hem atın hem de ana tarafından kardeşlerinin handikaplarını yansıtıyor. Mantıken bir atın baba tarafından 100 kardeşi varsa bu sayı ana tarafından kardeşlerde çok daha düşük rakamlara iniyor. Bir aygır yüzlerce Tay’a sahip olurken, dişi bir atın doğurabileceği at sayısı aşağı yukarı belli bir rakam. Burada da geliştirmeye açık olan kısım atın handikapının kardeşlerinden ayrılması ve ayrı çarpanlara tabii tutulması.

Kriterler bunlar, programın diğer bir geliştirmeye açık kısmı ise yarışların zorluk derecesinin belirlenip buna göre ilgili ayaklara yazılacak at sayılarının belirlenmesi.

Şu an için puan farklarını dikkate alarak oynanan kupon tutarının ayaklara düşen at sayılarına göre permütasyonlarına yaklaştırma yapan bir sistem mevcut fakat çoğu zaman istenen sonucu vermiyor. Ayaklara yazılan at sayıları sistemin hesapladığı puan farklarının yanısıra ilgili koşuların tipine ve geçmişte ne oranda sürpriz sonuç ürettiğine göre de şekillenmesine rağmen burası en fazla uzmanlık gerektiren kısım.

Örn. 24/10/2013 tarihli İzmir yarışı için sistemin bana verdiği sıralama şöyleydi,

1 : 1-2-7-(8)-5-3-9-6-4
2 : 5-(9)-13-1-10-4-11-2-15-14-7-3-6-8-12
3 : 8-2-1-3-10-4-(9)-5-6-7-11
4 : (5)-1-8-2-3-4-6-7-9
5 : 3-4-2-1-9-(14)-5-13-10-7-8-12-11-6
6 : 4-13-12-6-3-(14)-2-(16)-5-10-8-9-11-1-15-17-7

Bu yarış 10.000 küsür TL ikramiye verdi, Kupona sırasıyla 4/2/7/1/6/6 adet at yazıldığında 100.8 TL’lik bir kuponla bilinebiliyor. Ancak bu kombinasyonu belirlemek o kadar da kolay değil. Benim bugün için yazdığım kupon şu şekilde idi.

1 : 1-2-7-(8)-5
2 : 5-(9)-13
3 : 8-2-1
4 : (5)
5 : 3-4-2-1-9-(14)
6 : 4

4.5 TL’lik bir kupondu. Burada tek atı belirlemek için şöyle bir sistem kullandım. Sistemin verdiği katsayılarla önce üstte de paylaştığım sıralamayı oluşturdum. Sonrasında her bir kriter için %100 çarpan etkisi ile yeni kuponlar oluşturdum ve ilk sırada olan atlardan hangileri en az değişiyorsa bunları tek yazılacak atlar olarak belirledim. Burada şöyle bir kriterim de var, anne, tahmin, kıyas ve jokey kriterleri %100 uygulandığında bunlardan en az üçünde ilk sıradaki at değişmiyorsa bu atı tek yazılacak at olarak belirliyorum. Düşük tutarlı kuponlarla yüksek ikramiyeli 6lıları kazanmak için sürpriz beklenen ayaklarda yazılacak at sayısı favorileri kupondan eleyerek azaltılabilir. Misal ben bunu üstteki 3. ve 6. ayaklar için atları 4. sıradan itibaren yazarak yapsaydım.

Neyse efendim, yazımı bitirirken design’ı şimdilik mevlam kayıra karnın doyura şeklinde oluşturulmuş programın bir ekran görüntüsünü paylaşayım.

Bunlar da yarın ya da saat itibariyle bugün koşacak olan İstanbul ve Bursa yarışları için sistemin ürettiği sıralamalar.
25 Ekim 2013 – Bursa
1.Ayak : 7-2-4-12-11-9-8-10-3-5-1-6
2.Ayak : 3-9-2-11-6-7-4-1-5-8-10
3.Ayak : 5-3-6-4-7-2-1-10-9-8
4.Ayak : 1-6-7-2-4-3-5
5.Ayak : 8-10-1-6-3-9-7-4-2-5
6.Ayak : 1-8-11-3-13-6-9-4-12-10-5-7-2

5. Ayaktaki 8 numaralı at tek, bir sonraki tek olmaya en yakın at ise 4. ayaktaki 1 numaralı at.

25 Ekim 2013 – İstanbul
1.Ayak : 4-8-3-2-5-1-9-10-6-7
2.Ayak : 7-11-10-6-13-8-2-3-5-4-12-1-9
3.Ayak : 11-4-12-5-10-6-9-3-8-2-1-7
4.Ayak : 1-10-6-4-3-5-9-2-8-7
5.Ayak : 10-3-4-1-6-12-2-11-5-9-7-13-8
6.Ayak : 4-13-9-3-7-16-10-14-11-15-12-1-6-5-8-2

Burada da tek olarak belirlediğim at 4. ayaktaki 1 numaralı at.

At yarışı, Türkçe, Uncategorized

Creating a new alphabet

October 19th, 2012

Why one needs to create a new alphabet? And how does he/she do it?

Coming soon… The history of my 24 years old alphabet…

20121020-001622.jpg

Uncategorized

Just a reminiscence

January 16th, 2011

somethin i got, got it long before…
but i fucking don’t care about her anymore.
too many things…
too many things i can say about her,
yet i don’t want to have the same dream again.
i don’t want to have the same dream again.

Uncategorized ,

3. Merhaba dünya diyene kadar (temeller)

April 2nd, 2010

Tekrar selamlar,

Daha önceki yazımda da belirttiğim gibi bu yazımda ilk programımız olan hello world / merhaba dünya programını tanıtacağım. İşe tepeden aşağıya programı tanımakla başlayalım. Önce programa dahil ettiğimiz kütüphanelerle mesela.

stdio.h ve stdlib.h’ı anlatmama gerek yok bunlar c programlarında sıklıkla kullanılan kütüphaneler zaten. Aşağıdaki iki kütüphane referansı ile başlayabiliriz.

gccore.h, bu wii/gamecube donanımına düşük seviyede erişimi sağlayan kütüphanelerin bütününü include eden bir header dosyası. Hello World programındaki video/ekran fonksiyonları örneğin buradan gelmekte.Wii/gamecube programları için olmazsa olmaz bir include. Gamecube demişken, evet wii’ye has bir şeyler kullanmadığımız zaman yazdığımız programı gamecube için de derlemek oldukça kolay bu arada.

wiiuse/wpad.h include’u ise wiimote’a erişmek için kullanılıyor.

Neyse include’ları geçelim, ekranda bir şeyler yazmak üzere yapılan başlangıç işlemlerine kısaca bir göz atalım.

	    // Initialise the video system
	    VIDEO_Init();

	    // This function initialises the attached controllers
	    WPAD_Init();

Video_Init() ekran kullanan bir uygulamada video işlemlerine başlamakta kullanılan bir fonksiyon, muhtemelen sistemin kendi iç değişkenlerini oluşturmasını sağlıyoruz böylece. WPAD_Init() fonksiyonu ise wiimote’larla iletişimi sağlayan kütüphaneyi ayağa kaldıran bir fonksiyon. Arkaplanda wiimote’larla bluetooth üzerinden sürekli haberleşmeyi başlatıyoruz böylece.

Not : Homebrew programların henüz wiimote’ları senkronize etme özelliği yok. Bu yüzden kullanıcının wiimote’larının hali hazırda senkronize edilmiş olması zorunlu. Burada bahsettiğim senkronizasyon wii üzerinde ve wiimote üzerindeki kırmızı tuşlarla yapılan senkronizasyon.

    rmode = VIDEO_GetPreferredMode(NULL);

Yaptığımız uygulama herhangi bir pencerede vesaire çalışmadığı için tüm ekran bizim. Wii 480p / 480i / 576i vesaire bir çok ekran modunu desteklemekte. Öncelikle bizim bunlardan birini seçmemiz gerekiyor. Üstteki kod parçası kullanıcının menü ayarlarından seçmiş olduğu video modunu geri dönüyor. Böylece NTSC kullanan kullanıcıda PAL, PAL kullananda NTSC kullanma gibi bir yanlışa düşmemiş oluyoruz. Tabii bu arada rmode değişkeninin global olarak aşağıdaki şekilde program içinde tanımlanmış olduğunu da atlamayalım.

static GXRModeObj *rmode = NULL;

Hemen peşinden bu video modunu tutan değişkenimizle aşağıdaki gibi ekran için cache’lenmeyen bölgeden bellek ayırıyoruz. Bu arada burada yazanların mantığını şimdiden anlamaya çalışmanıza gerek yok. Yazacağımız programlarda bunları hemen hemen aynı şekilde kullanıp belki de bir daha dönüp bakmayacağız bile bunların yüzlerine… Yine de, ileride olası double buffering kullanan bir uygulama yaptığımızda bu aşağıdaki bellek ayırma rutinini iki defa çağırmamız gerektiği bilgisi de önemli. xfb değişkenimiz void pointer olarak tanımlı bu arada. Ha bu arada işaret ettiği bellek bölgesine external framebuffer diyoruz.

xfb = MEM_K0_TO_K1(SYS_AllocateFramebuffer(rmode));

Evet geldik zurnanın zırt dediği yere, bunları kısaca geçeceğim.

console_init(xfb,20,20,rmode->fbWidth,rmode->xfbHeight,rmode->fbWidth*VI_DISPLAY_PIX_SZ);

Bu fonksiyon çağrısı konsol (text basmakta kullanacağımız alan) kullanabilmek için gerekli bir çağrı. Bilmemiz gerekenler 2. parametreden 5.’ye kadar olanlar. Konsol olayı tamamen bir aldatmacadan ibaret, aslında yine grafik modu kullanılıyor. 2. ve 3. parametrelerde konsolun başlangıç x ve y koordinatları, 4. ve 5. parametrelerde ise sırasıyla konsolun genişliği ve konsolun yüksekliği tanımlanıyor.

	VIDEO_Configure(rmode);

Seçtiğimiz video modunu ayarlıyoruz burada,

	VIDEO_SetNextFramebuffer(xfb);

Ekran için hangi bellek bölgesini kullanacağımızı bildiriyoruz,

	VIDEO_SetBlack(FALSE);

	VIDEO_Flush();

	VIDEO_WaitVSync();
	if(rmode->viTVMode&VI_NON_INTERLACE) VIDEO_WaitVSync();

Ekranı aktif hale getiriyoruz ve yaptığımız ayarların geçerli olabilmesi için 1 ya da 2 tarama yapılmasını bekliyoruz. Evet dediğim gibi buraya kadar olan kodlar aslında rutin başlangıç işlemlerini yapmakta kullanılıyorlar. Burada anlamadığınız bir yer varsa çok da kafanıza takmanıza gerek yok.

Gelelim esas programımıza

	printf("\x1b[2;0H");
	printf("Hello World!");

İlk satır pek hoşlanmadığım türden bir VT terminal kontrol karakteri dizisi… Oradaki 2 ve 0′a dikkatinizi çekmek istiyorum sadece, bu rakamlar cursor’ü 2 nolu satırın, 0 nolu sütununa yani ilk sütuna konumlandırıyor. ilk satır ve sütunun 0′dan başladığını düşünürsek mantıksal olarak 3. satır ve 1. sütundan bahsediyoruz pek tabii. İkinci satır ise gayet aşikar.

Gelelim kodun geri kalanına,

	while(1) {
		WPAD_ScanPads();

		u32 pressed = WPAD_ButtonsDown(0);

		if ( pressed & WPAD_BUTTON_HOME ) exit(0);

		VIDEO_WaitVSync();
	}

	return 0;

Ekrana yazımızı bastıktan sonra burada sonsuz bir döngümüz var. WPAD_ScanPads çağrısı wiimote’ların durumunu denetlememizi sağlıyor, hangi tuşa basıldı vesaire bilgileri tüm wiimote’lar için topluyor. Bir sonraki WPAD_ButtonsDown(0) ile de bağlı olan ilk wiimote’un hangi tuşlarına basıldığı ile ilgili bir rapor alıyoruz. Bize 32 bitlik bir değer dönüyor bu çağrı. Bize dönen bu değer içinde bizim ilgilendiğimiz HOME tuşunu ifade eden, bu tuşa basılmış ise programdan çıkıyoruz. Bir sonraki satırda VIDEO_WaitVSync çağrısı da programımızın ekran taramasının bitimine kadar duraksamasını ve boşu boşuna cpu’yu yiyip bitirmemesini sağlıyor. Kullanıcı wii’sini 50hz pal modunda kullanıyorsa bizim bu döngümüz saniyede 50 defa çalışıyor. Bu wiimote üzerinde basılan tuşları yakalamak için oldukça yeterli bir süre.

Böylece basit programımızı kabaca tanıtmış olduk. Şimdi sıra geldi programımızı derlemek için kullandığımız Makefile dosyasına. Makefile dosyaları make isimli bir program tarafından kullanılan derleme / linkleme / kurulum / çalıştırma gibi program geliştirmenin rutin süreçlerini kolaylaştırmaya yarayan dosyalar. Öncelikle ben de sıfırdan bir Makefile oluşturacak kadar bu dosyanın öğelerine hakim olmadığımı belirtmeliyim. Zaten çoğu zaman kullanacağımız Makefile içerisinde değiştireceğimiz yerler belli olduğundan öncelikle bunları bilmemiz yeterli. Bu yüzden aşağıda Makefile içerisinden belli satırları buraya alıntılayıp bu bölümlerin nasıl kullanıldığını açıklamakla yetineceğim.

SOURCES		:=	source
DATA		:=	data
INCLUDES	:=

Burada SOURCES kaynak kodlarımızın nerede bulunduğunu işaret ediyor, mevcut örneğimiz için source klasöründe.

DATA kısmı programımıza linklenecek binary dosyalara işaret etmekte kullanılıyor. Resim, müzik veya herhangi bir binary içerikten bahsediyoruz burada.

LIBS	:=	-lwiiuse -lbte -logc -lm

Burası da belki de en çok değiştireceğimiz kısım. Programımızda kullanacağımız diğer kütüphaneleri burada belirtiyoruz. Windows üzerindeki DLL, linux/unix üzerindeki SO’lar gibi shared library’ler kullanamadığımız için kullandığımız kütüphaneleri derleme sonrası programımıza linklenmek üzere yüklemiş olmalı ve Makefile içerisinde de bunlara referans vermek durumundayız. Yukarıda ismi geçen kütüphaneleri C:\devkitPro\libogc\lib\wii klasöründe görebilirsiniz. Örneğin burada -l önekinden sonra geçen wiiuse bu klasördeki libwiiuse.a kütüphanesine işaret ediyor.

Yukarıda kütüphaneler belli bir mantıkla sıralanmış durumda bu arada bunu da belirtmekte fayda var. Bu satırda diğerlerini kullanan kütüphaneler daha başa, bağımsız olanlar ise sona yazılıyor.

- libm bir matematik kütüphanesi, diğer kütüphaneleri kullanmıyor ama örneğin ogc kütüphanesi bu kütüphaneyi kullanıyor. Bu yüzden en sonda yazılmış.

- libogc gccore.h’ı include ettiğimiz anda boynumuzun borcu haline gelen bir kütüphane ama ne libwiiuse’u ne de libbte’yi kullandığı için yine sonlarda ama libm’den önce.

- libbte bir bluetooth kütüphanesi. Biz doğrudan kullanmasak ta wiimote’a erişim için kullandığımız libwiiuse kütüphanesi bunu kullanıyor dolayısıyla libwiiuse’dan sonra geçmek durumunda.

- libwiiuse ise wii’nin bluetooth ile bağlandığı hemen her aparata erişmemizi yüksek seviye bir api ile sağlayan bir kütüphane.

Şimdi bu programa müzik çalmak üzere libmad kütüphanesini kullanan kodlar eklediğimizi düşünelim. Sizce bu kütüphaneyi kullanacağımızı belirten -lmad ifadesini yazdıktan sonra Makefile içerisindeki üstte belirttiğimiz satır nasıl olur?

LIBS	:=	-lwiiuse -lbte -lmad -logc -lm

Burada biraz mantık, biraz da derleme esnasında alınan hatalar etkili oluyor. Mantığımızı kullanırsak : müzik çalabilmek için wii’nin ses için olan donanımına erişmemiz gerektiğini çıkarabiliriz. Bu yüzden wii donanımına erişmek için libogc’nin kullanıldığı bilgisiyle libmad’i libogc’den önceye alıyoruz.

Neyse şimdilik müzik falan yapmayacağız :)

Bu arada yazımız da burada sonlanırken bir sonraki yazıyla beraber gerçek bir projeyi parça parça yazarak devam etmeyi düşünüyorum. Bu bir oyun olabilir, bir uygulama olabilir, yazarken wii ile iyice aşina olacağımız sonunda da belki kullanabileceğimiz bir şeylerin ortaya çıktığı orta çapta bir projeden bahsediyorum. Henüz kafamda net bir şey yok, önerilerinize açık olduğumu bildirerek bu yazımı da burada sonlandırıyorum.

Türkçe, Uncategorized, Wii, Wii Homebrew Geliştirme Dizisi , , , ,

Crap gets an update!

April 9th, 2009

Easy to use channel creator for usb backups gets an update,

Crap screenshot

Crap screenshot

here is the changes,


09/04/2009 WiiCrazy (I.R.on)
-----------------------------------------------------------------
* Added configuration, now you can use any dol you want, check out
the crap.cfg configuration file.

Uncategorized , ,