15 Kasım 2010 Pazartesi

dg2



[figür bir. fitness'ların teker teker denenmesi. adaptif ve non-adaptif versiyonlar için. bu imajda ne olup bittiğini anlamak için şuradaki açıklamalara bir bakılabilir.]

yaklaşık bir yıl kadar önce "design games" başlığıyla bir seri metin girmiştim. [biri, öbürü, başkası ...] bu çalışma aslında onun devamı. [>>dg2] (bende de ne sebat varmış!?) orda bir seri sorun çıkmıştı. ana fikir tarz veya beğenilerin parametrik olarak kodlanması ve bunun üzerinden bir evrimsel algoritmada kullanılacak fitness prosedürlerinin (objective function da diyeler) üretilmesi idi. ama parametreler sayıca patlamıştı, programda hatalar vardı, bi de bir kuramsal çerçeveyi programa aktarmaya çalışmaklar yüzünden gereksiz yere katman katman derinleşmişti program. ve nesne yönelimli bir program yapısı oluşturduğumdan onu alıp düzeltmek de pek pratik olmuyordu. yani acemiliğimi doyasıya yaşamıştım. neyse işte arada başka konulara daldık, okuduk ettik, daha akla yatkın yaklaşımlar geliştirince de konuyu yeniden ele aldık efendim, o da bu çalışmadır.

buradaki tasarım problemi aslında dg1 ile aynı ama daha net bir biçimde tanımlandı: bir seri damga/desen ve metni (tasarım birimleri: DU) bir kanvasa dağıtmak. sonuçta renk dağılımı renk hedefi imajına, mekansal dağılımı da mekansal düzenleme imajına benzeyen grafik düzenlemeler (ya da desenler?) elde etmek. aşağıdaki imajlarda 3 temel senaryonun bazı varyasyonları görülüyor. birkaç meseleyi denedim bu süreçte. biri arayüz meselesi. ilk çalışmada parametre sayısı çok artmıştı ya, işte burda parametrik bir arayüz yok da hedef imajlar var. o imajlar da aslında onlarca parametre 'slider'ı ile zor tanımlanacak derinlikte/bollukta bilgi içeriyor, bakıyoruz anlıyoruz, seviyoruz seçiyoruz, görsel hayvanlar için hızlı bir arayüz. iyi de çalıştı bu. zaten benzer denemeler var literatürde. aşağıda figür 2 ve 3'e bakınız, burdaki denemelerde renkler olsun aranjmanlar olsun targetları andırıyor hakattan.

ikinci konu yine parametrelerle ilgili, her ne kadar tarzlarla ilgili parametre ayarlaması ve arayüz konusu hallolmuş olsa da evrimsel algoritmanın kendisine ait süreç parametrelerinin ayarlanması meselesi yerinde duruyor ki o da fena bir mevzu. öf. baya zaman alıyor. parametreler iyi ayarlanmazsa makina çalışmıyor. yani kötü sonuç veriyor. gecelerce ayarla ha ayarla. daha bir seri sorun daha var parametrelerle ilgili, bunların bir kısmını eski entry'lerde paylaşmıştım. o yüzden işte parametre kontrolü diye bir kavram ortaya atmışlar. bundan da bahsetmiştim biraz. özetle parametrelerin süreç içinde dönüşmesi / evrilmesi ile uygun parametreleri bulmanın da aynı evrimin konusu kılınması, buna da adaptif süreç deniyor. yine bir takım başlangıç değerleri veriliyor ama bu değerler de evriliyor. akıllıca bir fikir. ama nasıl uygulanacağı o kadar açık değil. neyse biz de denedik diyorum işte. eldeki denemelerde adaptif süreçler genelde azıcık daha kötü sonuç verdi. aynı parametrelerle başlıyorlar ama sabit parametreli süreç daha iyi sonuç veriyor. tabi yılmadım, popülasyon sayısını artırarak denedim de denedim. (10, 40 ve 80lik popülasyonlarla) çünkü parametre sayısı ne kadar artarsa arama uzayını o kadar geniş tutmak gerekiyor. e adaptif süreçte evrilen parametre sayısı çılgınca artıyor. özetle 10 bireylik süreçlerde genelde adaptif olmayanlar daha yüksek bir fitness'a varabilirken (bkz figür 1'de 4 fitness ayrı süreçlerde denenmiş. tablolar her varyasyon için 10'ar denemenin ortalamaları alınarak basılmıştır.) 80 bireylik popülasyonlarda performans nerdeyse eşitleniyor. ama harcanan süre de o kadar artıyor. tabi 80'lik süreçlerin vardığı değer, adaptif ya da değil, 10'luktan daha yüksek oluyor, ama harcanan zamanı haklı çıkaracak kadar da değil.

son mesele de yine evrimsel hesaplamalara dair teknik bir konu. şimdi bir tek fitness prosedürü olduğu zaman tüm bireyler bu prosedür üzerinden değerlendiriliyorlar. ama birden çok fitness olduğu zaman ne yapılacağı çok açık değil. benim burda denediğim bir seri mikro evrimi arka arkaya dizmek oldu. yani 4 ayrı fitness'a ait 4 farklı prosedür aynı popülasyon üzerine işliyor. biri o anki eşiğini geçerse sonrakine devrediyor, popülasyonun kaldığı noktadan diğer evrim alıyor. şimdi sorun şurda, bu prosedürlerin birbiriyle çakışan-çelişen hedefleri olabiliyor. o zaman bir prosedür diğerinin yaptığını bozuyor (yani hedefler bağımsız değiller). işte bunun için de baştan bir öncelik sırası belirleniyor. öncelikli bir fitness kendi güncel eşiğinin altına düşerse de bu sefer o fitness'a geçiliyor. karışık gibi oldu. ve karışık da biraz. çok karışık değil ama. detayına şimdi giremeyeceğim ama işledi bu yaklaşım. en azından bu problemde işledi. bir seri deneme yaptım ve genel olarak yaklaşımın çalıştığını görüyoruz, figür 2 ve 3'ten bakılsın.



[figür iki. adaptif ve non-adaptif süreçlerin 4 fitness'lı "consecutive" versiyonda karşılaştırılması. non-adaptif olan gayet güzel çalışıyor. adaptif olan s.çmış. çünkü out + overlap adaptifte çalışmıyor niyeyse. üzerine düşünmek lazım.]

çok fazla detay varmış, şimdi şuraya yazarken nasıl kısaltacağımı şaşırdım, bildiride bunun 3 katı malumat var, nasıl bir terbiyedir bu akademik yazı faaliyeti, bravo doğrusu insanın kafasına vura vura benimsetiyorlar. en önemli bir iki konuyu daha aktarıp keseyim: 1. "inisiasyon haritası": bu haritalar da hedef kompozisyon imajından çıkıyor ve aday imajlar üretilirken buna göre üretilebiliyor. figür 1'de haritasız inisiasyon örnekleri var, figür 2 ve 3'te haritalılar. 2 ve son olarak da "bolluk" meselesi: şimdi böyle bir yaklaşımla ne yapılabilir denirse, bir kere elde keyfi bir renk hedefi var, ondan sonra bizim ürettiğimiz de bir aranjman imajı var, fakat kaç dane damga, hangi damgalar, hangi metinler kullanılacak onu bizim senaryomuz belirliyor. ben tek bir damganın 3 ayrı boyunu kullandım, ama böyle olmak durumunda değildi, farklı damgalar, ebatlar, yazılar kullanılabilirdi. ve mesela aynı hedef imajlarla farklı sayıda damga kullanılabilirdi. ben de iki varyasyon denedim bunla ilgili: normal durum hedef aranjmanındakiyle aynı sayıda tasarım biriminin (DU) bulunduğu versiyon iken bolluk durumu tam iki katı kadar DU'nun olduğu durum. işte bu bolluk durumunda da sonuçlar hedeflere benzeyecekler miydi? prosedürleri oluştururken buna elverecek şekilde toleranslı prosedürler yazmayı hedefledim. sonuçlar da bizce olumlu oldu efendim. onun örneği de aşağıda, figür 3.



[figür üç.]

eksiğiyle fazlasıyla çalışma böyle bir yere vardı. en azından hipotezleri net, sonuçları net, yöntemi açık, hesap veriyor, sonuçları doğru (sabunlama yok) vd vd. plan evrimi denemelerinde bu yaklaşımla ('micro-processes' mi desem 'consecutive approach' mı desem bilemedim) 7 fitness'a kadar çıkıp belirli bir başarı da tutturmuştum. ama daha üzerinde çalışmam lazım. işte adım adım geliştiriliyor ancak. o kadar çok mesele oluyor ki.. önce en bariz ortada olanlardan başlıyorsun, sonra onlar bir yere vardıkça detaya giriyorsun, sonra daha da detaya derken başta hiç düşünülmeyen bir düzeye doğru gelişiyor çalışma ve program...

[bildiriyi kabul ettiler, sunacağım, basacaklar, konferansın parasını bile yatırdım. geriye kaldı bir yığın prosedürü izni pasaportu kağıt işi şusu busu. bildirinin tam metnini buraya, ilk denemelerde ortaya çıkan 'düzenleme'leri de 'kenarlar'a koyuyorum. uçak biletimi ayırtayım önce :) ]

[edit: paket 1: desktop senaryoları sonuçlarından seçmeler.]

[vektör grafiklerde >inkscape, bitmap grafiklerde >gimp, işletim sisteminde >ubuntu (laptopta da windows kullandım gerçi. lisanslı ama), heryerde, herşeyde >python, ve de: scipy, numpy, matplotlib, pycairo, polygon, shapely, psyco, kullanınız, kullandırınız.]

Hiç yorum yok: