Kategori arşivi: Bilimsel Programlama

Yeni blog: PythonBilim

Yaz geldi, dersleri bitirdik. Dönem sonu sınavlarını okuyup son notları da verdikten sonra eğlenceli işlerime dönebileceğim. Öncelik elimdeki araştırma probleminde. Gerekli simülasyon programı hazır; önümüzdeki aylarda simülasyonu sistematik şekilde işleyip sonuçları yazılı hale getirmekle meşgul olacağım. Bitirebilirsem buradan duyururum.

Diğer bir planım için bu hafta ilk adımı attım. Python ile bilimsel programlama konularını işleyen PythonBilim isimli bir bloga başladım. İlk yazılar temel Python programlama ile ilgili olacak, daha sonra sayısal analiz ve hesaplamalı bilimle ilgili konulara gireceğim. Aslında, birbiri üzerine eklenen bir ders notu demeti hazırlamak istiyorum.

Malum, marifet iltifata tabidir. İlgilenenlerin hatalarımı ve eksiklerimi bildirmesinden, yorum yaparak veya konuk yazar olarak katkıda bulunmasından mutluluk duyarım.

PythonBilim projesi sebebiyle muhtemelen bu bloga eskisinden daha seyrek yazmak zorunda kalacağım.

Reklamlar

Tekrarlanabilir araştırma ve Rogoff-Reinhart olayı

Tekrarlanabilir Araştırma“nın (Reproducible Research olarak da bilinir) ana fikri çok basit: Hesaplamaya dayalı bir bilimsel çalışma yaptıysanız, hazırladığınız bilgisayar programını da makaleyle beraber herkese açıkça sunacaksınız.

Bu fikri ilk duyduğumdan beri “e haliyle” diyordum. Sonuçlarınızı nasıl elde ettiğinize dair her ayrıntıyı vermezseniz, okuyanlar doğru iş yapıp yapmadığınızı nasıl kontrol edebilir? Öte yandan bu fikre pek ısınamayanlar var. Sebepler muhtelif, ama en çok “ne uğraşacağım” tavrı ağır basıyor.

Teorik bir çalışmayı anlatan makalenizde, o sonuca nasıl ulaştığınızı ayrıntıyla göstermeniz, yani ispat etmeniz beklenir, böylece gerek hakemler, gerek okuyanlar sizin düşünce zincirinizi takip edebilir ve yaptığınız hataları tespit edebilir. Oysa hesaplamalı çalışmada kullandığımız bilgisayar programını vermesek de olabiliyor nedense.

Matematikçi Randall J. LeVeque, “Top Ten Reasons To Not Share Your Code (and why you should anyway)” başlıklı eğlenceli yazısında, teoremlerin ispatsız olarak yayınlandığı alternatif bir evren hayal ediyor. Kaynak kodlarını yayınlamamak için öne sürülen bahanelerin, teorem ispatlarını yayınlamamak için de kullanılabileceğini anlatıyor ve bu bahanelerin komikliğini gösteriyor.

Kod paylaşmaya karşı isteksiz tavır yakında değişebilir, çünkü birçok bilim alanında Tekrarlanabilir Araştırma talepleri artmaya başladı. Sözgelişi, Lior Shamir ve çalışma arkadaşları, ArXiv’deki “Practices in source code sharing in astrophysics” başlıklı makalelerinde, bir çalışmanın yayına kabulü için, kaynak kodlarının da yayınlanmasının şart koşulması gerektiğini savunuyorlar.

Science, Nature gibi en üst seviye dergiler bunu uyguluyor bile. On yıla kadar bütün ciddi dergilere yayılması mümkün. Yakında makalenizi yazarken programcılık disiplinine dikkat etmeye başlamanız, hakemlik ederken de kod okumaya hazırlıklı olmanız gerekebilir. Bu konularda Software Carpentry sitesi çok faydalı bir kaynak.


Birkaç hafta önce makroekonomi alanında patlayan Rogoff-Reinhart makalesi tartışması, hesaplamalı çalışmanın açıkça sunulmamasının yaratacağı sonuçları çok çarpıcı şekilde gösterdi. Ayrıntıları Güven Sak’dan veya BBC haberinden okuyabilirsiniz. (Aykut Kibritçioğlu bu konuda çok etraflı bir okuma listesi tutuyor.) Özetle, Rogoff ve Reinhart’ın 2010’da yayınladıkları makale, devlet harcamalarının azaltılmasını isteyenlerin ekmeğine yağ sürmüş. Ancak, yazarların kullandığı Excel tablosunda bazı ülkelere dair veriler yanlışlıkla hesaba katılmamış, bu da ana çıkarsamanın yanlış olmasına yol açmış.

Rogoff-Reinhart çalışması boğazına kadar politik tartışmalara batmıştı, o yüzden bu hata çok yankı uyandırdı. Oysa çalışmayla beraber ilgili veri (Excel dosyası) yayınlanmış olsaydı ve ilgili herkes en baştan beri kolaylıkla inceleyebilseydi, bu hata daha önceden bulunabilirdi. Gereksiz siyasi tartışmalar yine olurdu belki (siyasi tartışmalar akla dayanmaz zaten; insanlar önce bir fikir benimser, sonra o fikri destekleyecek bir şeyler bulurlar), ama yazarların itibarı bu kadar zedelenmezdi.

Bilgisayar bilimci Daniel Lemire, ciddi işlerde neden Excel kullanmamamız gerektiğini güzelce yazmış. Hesap tablosu mantığı programlama disiplinine uymaz, hataları bulmak çok zordur. Bilimsel hesap yapacaksanız C, Fortran, Java, Python, R gibi ciddi bir dil kullanmalısınız.


Kişisel bir tecrübe: Bir süre önce uzay fiziği alanında bir makaleye hakemlik yaptım. Çalışma, özel bir manyetik alan modelinde yapılan simülasyonların sonuçlarını aktarıyordu. Kullanılan kaynak kodu verilmemişti, hatta daha önce yayınlanmış olan manyetik alan modelinin kaynak kodunu da internette bulamadım.

Çalışmada bazı zaaflar buldum, yazdım, raporun sonuna da kullanılan programların da paylaşılması gerektiğini, böylece ilgili kişilerin sonuçları tekrarlamasının mümkün olacağını yazdım. Cevaben, isteyen herkese programı gönderebileceklerini, ama kodda birçok zor kısım olduğunu ve diğer kullanıcıların yardımsız çalıştırmalarının zor olacağını yazdılar. “Yardımsız çalıştırılabilecek hale getirin o zaman” demenin faydasız olacağı belliydi, üstelemedim.

Metodik hata olduğunu düşündüğüm bazı noktalara üstünkörü cevap vermişlerdi. Bazı kavramsal hataların yanı sıra, simülasyonları kabul edilemeyecek kadar büyük miktarda sayısal hata içeriyordu. Anlaşıldı ki, 4. derece Runge-Kutta gibi ancak orta derecede doğruluğu olan bir yöntem kullanmışlardı. Üstelik bunlar fasulyeden adamlar da değillerdi; birinci yazar NASA’da çalışıyordu. Makaleyi reddettim, ama bir süre sonra değişikliklerle tekrar geldi. Az daha düzgün bir sayısal yöntem kullanmışlardı, hata payı daha azdı. İtiraz etmek için somut bir sebebim olmadığından, içime tam sinmese de kabul ettim.

Acaba kaynak kodunu inceleyebilseydim, veya hiç olmazsa sonuçları tekrar üretebilseydim başka neler bulurdum merak ediyorum. Kaynak kodunu paylaşma isteksizliğinin bir sebebinin, örtbas edilmiş eksikliklerin keşfedilmesi korkusu olduğundan şüpheleniyorum.

Molecular Workbench ile molekül dinamiği simülasyonları

Molecular Workbench (MW) atomlar ve moleküller arası etkileşimlerin ve mikroskopik süreçlerin simülasyonu için geliştirilmiş, epey yetenekli, açık kaynaklı bir Java programı. JDK kurulu her platformda çalışabiliyor. Linux’da çok kolay kurdum, Win ve MacOS’da da kolay olacağını tahmin ediyorum.

MW yazılımı Web üzerinden hazır simülasyon sayfalarına erişip onları çalıştırabiliyor. Yüzlerce örnek simülasyon var. Birçok fiziksel sürecin atom seviyesinde nasıl işlediğini öğretmek için özenle hazırlanmışlar. Sözgelişi, üç boyutlu bir cismin atomlarının titreşimlerini gözleyebilir, sıcaklığı artırarak katıdan sıvıya, sıvıdan gaza geçişi gözleyebilirsiniz.

kristal

MW’i üreten Concord Consortium, Google’dan aldığı bir bağışla “Next Generation Molecular Workbench” sistemini hazırlamış. Buradaki örnekler Java ile değil, HTML ve JavaScript ile hazırlanmış. Bu simülasyonların içinde kayboldum gittim. Malzemelerin mukavemeti, gazların difüzyonu, su molekülleri arasındaki hidrojen bağları, temel gaz yasaları, protein katlanması ve daha nice fiziksel sürecin işleyişini moleküler seviyede seyretmek mümkün. Yalnız, Firefox’un son versiyonlarında çok yavaş işliyorlar. Chrome’un performansı daha iyi.

“Klasik” (Java) MW’ya dönersek: MW’nin kaportasının altında güçlü bir fizik motoru var. Atomlar/moleküller arasında van der Waals, Lennard-Jones, veya elektrostatik kuvvetlerin etkisi simüle edilebiliyor. Ayrıca yerçekimi, dış elektrik alan veya dış manyetik alan kuvvetleri de tanımlanabiliyor.

MWsalt

Tuz kristalinin suda çözülmesi

Kuantum etkileri de MW motoruna dahil edilmiş. Bir duvara doğru gelen elektronun tünelleme etkisiyle kısmen diğer tarafa geçişini, veya yaklaştırılan iki atomun elektron bulutlarının kaynaşarak kovalent bağ oluşturmasını seyredebilirsiniz. Atom-foton etkileşimleri de yazılıma dahil edilmiş. Çok büyük organik moleküller ayrı bir parçacık olarak sisteme eklenip “mezoskopik” simülasyonlar da yapılabiliyor.

MWtunneling

Tek tek yazmakla bitmez. En iyisi, her biri belli bir konuyu anlatmak üzere dikkatle hazırlanmış yüzlerce simülasyona bir göz atın. Hem MW’in yapabileceklerini görürsünüz, hem de çok zevkli zaman geçirirsiniz.

MW yazılımını kullanarak sıfırdan başlayarak kendi simülasyonlarınızı geliştirebilirsiniz. Molekülleri gösteren pencerenin çevresine çeşitli ayar bileşenleri, grafik kutuları koyabilir, metin kutuları ile açıklamalar ekleyebilirsiniz. Simülasyon penceresine öntanımlı atomlar ve molekülleri tıklayarak yerleştirebilirsiniz. Bununla basit deneyler yapabilirsiniz ama daha karmaşık durumlarda düzenli bir ilk durum yaratmak, çok sayıda atoma ince ayar yapmak gibi ihtiyaçlarınız olacaktır. Bu tür işler için MW’in kendine özgü script dilini kullanabilirsiniz.

MWmagbottle

MW çok gelişkin ve gitgide daha da geliştirilen bir fizik sistemi. Yeni simülasyonlar üretmek isteyenler için kapsamlı yardım belgelerini mevcut. Harcadığınız zamanın karşılığında olağanüstü güzel ve öğretici simülasyonlar hazırlama imkânı kazanırsınız. MW’nin bilimsel araştırma için kullanılabileceğini zannetmiyorum – bu iş için daha gerçekçi ve hızlı yazılımlar var – ama konferans sunuşlarında veya bloglarda kullanılabilecek simülasyonlar hazırlamak için birebir.

Simülasyon hazırlamak istemiyorsanız bile MW kütüphanesindeki simülasyonları çalıştırıp seyredin. Derslerdeki fizik ve kimya süreçlerinin gözünüzün önünde canlanması çok heyecan verici.

MW_heatflow

Physion – fizik simülasyon yazılımı

Etkileşimli fizik simülasyonlarına ihtiyaç duyduğunuzda kullanabileceğiniz birkaç yazılım var. Bu yazılımlarda, bir grafik arayüz içinde fare kullanarak cisimler yaratabilir, bunlara ilk hızlar verebilir, dönmelerini sağlayabilir, çarpıştırabilir, çeşitli kuvvetler arasındaki hareketlerini seyredebilir, konum veya hızın zamanda nasıl değiştiğinin grafiğini gerçek zamanlı olarak çizdirebilirsiniz.

Physion bu yazılımlardan biri. Windows ve Linux’a kurulabiliyor. Linux’da kurma işlemi sıkıştırılmış bir dosyayı indirip açmaktan ibaret, çok kolay. Grafik arayüzü Qt ile hazırlanmış. Cisimlerin hareket ettirilmesi, çarpışmaların tespiti, sürtünme vs. gibi ise, oyunlarda fizik kurallarına uygunluk sağlamak için kullanılan “fizik motor”larından biri olan Box2D ile sağlanmış.

Physion sadece iki boyutlu (x-y düzleminde) simülasyonlar yapabiliyor. Şu kısa videoda Physion’un etkileşimli kullanımını görebilirsiniz.

Bu sistemle eğitici simülasyonlar hazırlanabilir. Meselâ, düz olmayan bir arazide ilerleyen basit bir (dört çeker) araba.

Burada da, merkezi (iki cisim arasındaki çizgi doğrultusunda) bir kuvvet altındaki harekete örnek olarak, bir uydunun Dünya çevresindeki hareketi simüle edilmiş.

Çeşitli karmaşıklıkta birçok örnek program Physion ile beraber geliyor. Biraz çabayla çok ilginç ve eğlenceli fizik simülasyonları üretebilirsiniz.

Physion’un şimdilik zayıf kalan tarafları da var. Sözgelişi, kopyala-yapıştır özelliği yok. Fareyle yarattığınız bir nesnenin kopyalarını hızlı bir şekilde üretemiyorsunuz. Dahası, tasarım aşamasında (yani simülasyon başlamadan) fareyle nesnelerin yerini değiştiremiyorsunuz. Etkileşimli olarak düzenli bir sistem oluşturmak bu yüzden çok zahmetli. Herhalde fiziksel sistemlerin bir betik (script) ile oluşturulması tercih edilmiş.

Program içinde bir komut arayüzü (konsol) açıp nesneleri Physion’un ECMAScript temelli diliyle tanımlayabiliyorsunuz. Yazılımın gücünü tam olarak kullanmak ancak böyle mümkün. Ancak belgelemede eksiklikler var. Konsolda arka arkaya komut yazarak nesneler yaratmak yerine komutların bir dosyadan alınması çok daha kolaylık sağlar. Ne yazık ki bu konu yardım ekranında ve wiki sayfasında belgelenmemiş.

Bütün cisimler katı. Elastik cisimleri, birçok küçük küpü aralarında yaylarla birleştirerek simüle edebiliyorsunuz.

Sadece iki çeşit kuvvet kullanmak mümkün görünüyor: Sabit kuvvet (yerçekimi gibi), ve iki cisim arasında merkezi bir kuvvet. Bu merkezi kuvvet sabit büyüklükte mi, uzaklığın karesiyle azalıyor mu, örneklerden pek anlayamadım, ama sabit olduğundan şüpheleniyorum. Yani genel fizik simülasyonları için gereken çeşitli kuvvetleri kullanmak mümkün değil. Sözgelişi bir elektrik veya manyetik alan tanımlayamıyorsunuz. Genel bir potansiyel alanındaki hareketi simüle etmeniz de mümkün görünmüyor.

Physion şimdilik sadece sabit ve düzgün yerçekimi altında çalışan sistemleri simüle etmek için uygun görünüyor. Bu kısıtlama altında, script yazmakla ilgili sorunlar da giderilirse, çok ilginç ve öğretici simülasyonlar hazırlamak mümkün.

OpenStax, Processing

Geçen hafta TÜBİTAK’ın açık ders kitapları için proje çağrısından bahsetmiştim. Güzel bir teşvik; amacına ulaşırsa sadece Türkçeye yeni teknik kitaplar kazandırmakla kalmayacak, etkileşimli eğitim malzemelerini de çoğaltacak.

Bu arada aklıma bir alternatif daha geldi. Rice Üniversitesi’nin OpenStax College projesi çeştili alanlarda açık erişimli ders kitapları hazırlıyor. Bu kitaplar ciddi bir incelemeden geçerek yüksek bir kaliteyle yazılmış. Bir üniversite dersinde rahatça ana kitap olarak kullanılabilirler. Şimdilik fizik ve sosyoloji kitapları hazır, biyoloji ve anatomi konularında üç kitap yakında çıkacak.

Daha dar kapsamlı ve küçük ölçekli, ama yine özenle hazırlanmış bilgi kaynakları yine Rice’ın Connexions projesinde bulunabilir.

Sıfırdan kitap yazmak yerine, Creative Commons lisanslı bu kitaplar tercüme edilebilir, etkileşimli malzeme eklenerek zenginleştirilebilirler. TÜBİTAK’ın şartnamesine uymaz tabii; ayrı bir çalışma olacak. Dahası, hazırlanan etkileşimli malzeme orijinal kitaba da eklenebilir. Böylece dünya çapında bir hayır işlemiş olursunuz.

Java üzerine inşa edilmiş bir görsel programlama çerçevesi olan Processing programlama diliyle yeni tanıştım. Henüz öğrenme fırsatım olmadı ama görsel olarak çok etkileyici uygulamalar hazırlanabiliyor. Hazırladığınız yazılımı JavaScript ve HTML5 canvas elementine dönüştürüp web sayfası veya EPUB belgesi içine ekleyebiliyorsunuz.

WordPress.com betik eklemeye izin vermediği için bu sayfaya bir örnek koyamıyorum ama şurada güzel bir uygulama var.

Processing ile programlamayı öğreten bir video dizisinin ilk bölümünü buradan seyredebilirsiniz.

Daniel Shiffman’ın “The Nature of Code” kitabı tam da bu yaklaşımla hazırlanmış. Kitapta biraz fizik, biraz karmaşık sistemler, biraz simülasyon var. Shiffman’ın asıl amacı programlama öğretmek; bunun yüzden kitapta Processing kodları ve animasyon/simülasyonlar yanyana. Hem etkileşimli kitaplara örnek olan, hem de Processing öğreten için harika bir e-kitap.

Processing’den ve “The Nature of Code”dan haberdar olmamı sağladığı için Emre Sevinç üstadıma teşekkürler.

Türkiye illerinin komşuluk çizgesi

Vilayetler arasındaki komşuluk bağlantılarını topladım geçen gün. İlleri bir nokta gibi düşünelim ve ortak bir sınırı olan iki ili arasına bir çizgi çizelim. Meselâ İstanbul’un iki komşusu var: Tekirdağ ve Kocaeli. Buna karşılık daha merkezi bir yerde olan Ankara’nın coğrafi komşusu daha çok: Konya, Kırşehir, Çankırı, Eskişehir, Bolu, Aksaray, Kırıkkale.

Bütün illerin komşularını bu şekilde listeleyince şöyle bir çizge (“graph”) elde ediyoruz.

İllerin komşuluk ağı

İllerin komşuluk ağı. Büyütmek için tıklayın.

Noktalar il merkezlerinin nispi konumuna göre yerleştirildi, o yüzden gerçek haritayı andıran bir biçimi var. Enlem ve boylam bilgilerini buradan aldım. Haliyle kıyı ve sınır şehirlerinin az, iç şehirlerin ise çok komşusu var. Deniz veya göl üzerinden komşulukları saymadım.

En çok komşusu olan iller dokuzar komşuyla Konya ve Erzurum. Bunların ardından gelen Bolu, Yozgat, Sivas, Erzincan ve Diyarbakır’ın sekizer komşusu var. Yalova ve Hakkâri’nin ikişer, Kilis’in ise sadece bir komşusu var.

İllerin ortalama komşu sayısı 4,86.

Bu çizge kendi başına çok önemli bilgiler vermez. Vilayet sınırları bir ölçüde tarihsel dinamiklerle belirleniyor olsa da, çoğunlukla keyfe keder şekilde, veya iktidarların oy toplama arzusuyla çizilmiş olduğundan, komşuluk analizi çok derin bir anlayış getirmeyecek. Ama eğlence için bu ağın özelliklerine bakabiliriz.

Buradaki analizleri ve görsellemeleri Python ve NetworkX modülü ile yaptım. Kaynak kodunu ve gerekli veri dosyalarını buradan indirebilirsiniz.

Öbeklenme katsayısı

Bir noktanın öbeklenme (clustering) katsayısı basitçe, o noktanın iki komşusunun ayrıca komşu olması (yani üçünün bir üçgen oluşturması) oranıdır. Bu sayı Yalova, Karaman, Hakkâri ve Iğdır için tam bir, Kilis içinse (tek komşusu olduğundan) sıfır. Diğerleri ara değerlerde. Konya ve Erzurum gibi geniş illerin çok komşusu var, ama bu komşuların çoğu birbirinin komşusu değil, o yüzden onların katsayıları sırayla 0,28 ve 0,25.

Ortalama öbeklenme katsayısı 0,48. Yani rastgele bir ilin rastgele seçilen iki komşusunun birbirlerine de komşu olmaları ihtimali yarıya yakın.

Çizgenin geçişliliği (transitivity), yine öbeklenmeyi sıfırla bir arasında ölçen başka bir katsayı. Çizgedeki toplam üçgen sayısının, toplam üçlü (iki kenarla birleştirilmiş üç nokta) sayısına oranının üç katı (çünkü bir üçgende üç üçlü var) olarak tanımlanıyor. İller çizgesinin geçişlilik katsayısı 0,395.

“Uzaklık” ölçüleri

Bu çizgedeki kenarlar yolları temsil etmiyor; sadece komşuluk ilişkisini gösteriyor. O yüzden ağdaki genel “uzaklık” kavramını coğrafi mesafeyle karıştırmamak lâzım. Bu kısımda “uzaklık” dediğimde, bir noktadan diğerine en az kaç adımda gidildiğini kastediyorum.

İller çizgesinde ortalama en kısa “uzaklık” 4,88.

Her bir il için, diğer illere olan en kısa “uzaklık”ların ortalamasını aldığımızda, sırayla Kırklareli (7,25), Edirne (7,12) ve Tekirdağ (6,92) en uzakta. Yanılmayın, bu Boğazlar’ın araya girmesinden değil (çizgede Boğaz yok, sadece komşuluk var), sınıra ve Marmara Denizi’ne dayandıkları için az komşuları olmasından.

Bu sayı Sivas (3,50), Kayseri (3,51), ve Yozgat (3,53) için en küçük.

Merkezilik

Bir noktanın çizgedeki “merkezî”liği değişik amaçlar için farklı farklı tanımlanabilir. Bunlardan biri uzaklık merkeziliği, yani bir noktanın diğer bütün noktalara “uzaklık”larının tersinin ortalaması. Buna göre sırayla Sivas, Kayseri ve Yozgat uzaklık bakımından en merkezi iller. (Çizgedeki uzaklığın coğrafi tanıma birebir uymadığını hatırlatayım — A ilinden B iline, C ili üzerinden iki adımlık komşuluk olabilir, ama bu yol kilometre olarak çok daha uzun olabilir.)

Bütün il çiftleri arasındaki en kısa “yol”lardan kaç tanesinin belli bir ilden geçtiği, o ilin aradalık merkezîliğini (betweenness centrality) verir. Bu sayı da 0 ile 1 arasındadır. Bu merkezîlik tanımında da Sivas (0,33) ve Yozgat (0,22) en üstte, ardından Erzincan (0,21) geliyor.

Bir noktanın öneminin, komşusu olduğu noktaların önemlerinin toplamına orantılı olduğunu varsayabiliriz. Bu varsayım, iki basit matematiksel adımdan sonra bizi bir özvektör denklemine götürür, o yüzden bu göstergeye özvektör merkezîliği (eigenvector centrality) adı verilir.

Özvektör merkezîliğinde ilk üç sırada Konya (0,25), Yozgat (0,23) ve Ankara (0,22) var. Son dört sıra ise İstanbul (0,007), Tekirdağ (0,004), Edirne (0,003) ve Kırklareli (0,002) tarafından işgal edilmiş.

Bu değişik merkezîlik tanımlarının hepsinde orta Anadolu şehirleri, beklenebileceği gibi, üst sırada.

Sonuç

Çıkarılacak pek bir sonuç yok burada, çünkü kullandığım ağ neredeyse mânâsız. Sadece komşuluk ilişkilerinden oluşuyor. Bazı kategorilerde Sivas, Erzurum, Konya gibi tarihsel öneme sahip şehirler üste çıksa da, İstanbul, Ankara, İzmir gibi yoğun sanayi ve ticaret faaliyeti olan büyük şehirler “taşra” gibi kalıyor. Bariz ki bu modelle ciddi jeopolitik çıkarımlar yapılamaz. Amacım zevk için biraz oynamaktı. Bu çizge bir veri olarak burada dursun, belki daha kapsamlı bir model kurarken işe yarar.

Daha iyi bir model için iller aralarındaki ana yollara göre bağlanabilir, bu bağlantılara ulaşım hacmine göre ağırlık değerleri konabilir, sınır ve kıyı illerine dış ticaretten dolayı daha fazla ağırlık verilebilir, ilçeler de hesaba katılabilir.

Metin işleme araçları bilimsel programcıya neden lâzım?

Hesaplamalı bir model için program yazıyorum. Hata yapmaya çok yatkın olduğum için de uzun uzadıya test ediyorum. En sevdiğim test aracı “printf“: Değişkenleri ekrana yazdırıp, sonuçların beklenene uyup uymadığına bakıyorum.

Programım meselâ şöyle şeyler çıkarabiliyor:

250 250 250 250
Agents: 354 471	, 3 4 --> 4 4
250 250 249 251
Agents: 371 210 , 4 3 --> 3 3
250 250 250 250
Agents: 718 551	, 3 4 --> 4 4
...

Bunların her biri bir zaman adımı. Özel olarak, 1 4 (veya 4 1) –> 2 2, 1 4 (veya 4 1) –> 3 3 durumlarını test ediyordum. Eğer program doğruysa bu durumların aşağı yukarı eşit sayıda (%50 ihtimalle) gerçekleşmesi lâzım. Önce küçük sayılarda çıktıları aldım ve bu durumları parmakla saydım. Sonra aklım başıma geldi: Parmakla saymakla ne uğraşayım, çıktıyı bir dosyaya yazdırarak grep ve wc kullandım.

$ ./program > cikti.txt
$ grep "1 4 --> 2 2" cikti.txt | wc -l
(ve benzeri)

komutları ile, aradığım durumun kaç kere gerçekleştiğini bilgisayarım bana söyledi.

Elbette bu sayma işini programın içinde de yapabilirdim, ama bunun için kodu ciddi şekilde değiştirmek gerekirdi. Oysa azıcık bash ve azıcık GNU metin işleme komutları bilgisi ile işi kotardım.

Bu tarz tecrübeler bana şunları öğretti:

  • Linux kullanın. Standart bir GNU/Linux ortamında program yazarken çok işinize yarayacak araçlar bulunduğunu keşfedeceksiniz. Evet, programın kendisi için hangi işletim sistemi kullandığınız önemli değildir, ama programı destekleyen bir “ekoloji” programcıya her zaman kolaylık sağlar.
  • Programlarınız komut satırında çalışsın. Kara ekrandan korkmayın; bash ve benzeri komut derleyiciler programınızı aklınıza gelmedik şekillerde kullanmanızı sağlar. Programınız çalışma parametrelerini interaktif olarak değil, komut satırı argümanları şeklinde alsın. Böylece basit kabuk betikleri (script) ile programınızı değişik parametrelerle otomatik çalıştırabilirsiniz. Meselâ yüz tane hesaplama deneyini yapmak için bilgisayarınız bütün gece çalışırken siz gidip uyuyabilirsiniz.
  • Biraz kabuk programlama öğrenin, meselâ bash veya zsh. Böylece işlemlerinizi otomatikleştirebiirsiniz.
  • Gerçekten gerekmedikçe programın çıktısını bir dosyaya değil ekrana yazdırın (stdout ve stderr akışlarını kullanın). Lüzumu halinde komut satırında çıkış yönlendirme operatörü (>) ile çıktıyı bir dosyaya yazdırabilirsiniz. Bu şekilde ayırmak çalışmada esneklik sağlar. Meselâ bir betikle çıktı dosya isimlerinin otomatik üretilmesini sağlayabilirsiniz. Veya programın çıktısını dosya yerine bir boru hattı (|) ile başka bir programa yönlendirebilirsiniz.
  • Programınız çıktısını dosyaya yazıyor bile olsa, ikili (binary) biçimde değil, metin (text) biçiminde yazsın. Böylece verilere bakıp okuyabilme imkânınız olur. Sadece göz gezdirmek bile hataları yakalamak için etkili bir yöntemdir. Metin dosyası ikili dosyadan daha büyük olur, ama bu devirde bunun önemi yok.
  • Programınız düz metin üretirse, GNU metin işleme araçlarını kullanarak çıktı dosyalarını çok değişik (ve yaratıcı) şekillerde manipüle edebilirsiniz. C gibi bir dille metin işleme epey zordur. İhtiyacınızı tam karşılayan bir araç hazırda yoksa, Python veya Perl gibi bir dille hazırlayıp kullanabilirsiniz.

Şu komutları özellikle faydalı buluyorum.

  • grep: Bir dosyada, verilen bir metin parçasına veya düzenli ifadeye uyan satırları ekrana basar. Birçok özelliği olan güçlü bir komut, ama en basit haliyle bile yararlı.
  • awk: Satır ve sütun şeklinde düzenlenmiş dosyaları kolayca işlemek için hazırlandı. Dosyayı satır satır alıp seçilen sütunlarda işlem yapabilir, veya belli kalıplara uyan satırları seçebilirsiniz. Başlı başına bir programlama dili olarak kullanılabilir, ama tek satırlık komutlarla bile müthiş işler yapabiliyor.
  • sed: Özellikle bir boru hattı (pipeline) üzerinde, başka programların çıktılarını süzmek veya değiştirmek için tasarlanmış. Bul-değiştir işlemlerinde özellikle güçlü.
  • wc: Bir dosyadaki (veya giriş akışındaki) harfleri, kelimeleri ve/veya satırları sayar. Meselâ yukarıda verdiğim örnek grep’in çıktısının kaç satır olduğunu veriyor.
  • cat: Bir veya birkaç dosyanın içeriğini altalta ekrana yazar. Dosyaları birleştirip boru hattıyla başka komutlara göndermek için de birebir. Kardeşi tac komutu ise dosyalardaki satırları ters sırayla basar. İkisinde de satırları numaralandırmak mümkün.
  • head: Bir dosyanın ilk on satırını ekrana yazar. Daha az veya daha çok satır da basabilir. Kardeşi tail komutu ise dosyanın son satırlarını basmak için kullanılır.
  • cut: Dosyadan belli sütunları ayırmak için kullanılır. Tersi işlem olarak, paste komutu ayrı dosyalardaki sütunları birleştirerek tek bir dosya hazırlar.
  • sort: Dosyayı istenen sütunlara göre, alfabetik veya sayısal olarak sıralar.
  • uniq: Alt alta gelen mükerrer (birbirinin aynı) satırları siler. Genellikle sort‘tan sonra, tekrarları kaldırmak için kullanılır. Ama tekrarlananların sayılarını bulmak için de kullanılabilir.
  • join: Farklı dosyalardaki kayıtları, ilişkisel veritabanlarındaki gibi, ortak bir sütunla birleştirerek tek bir dosya yaratmak için kullanılır.

Bu tariflerdeki “ekrana yazmak” ve “dosyaya yazmak” eylemleri, aslında yönlendirme işlemleri sayesinde birbiri yerine geçebiliyor. Komut satırının büyük bir gücü bu.

David Mertz’in yazdığı “Using the GNU text utilities” bu komutlar hakkında zamanın eskitemediği kısa ve öz bir kaynak.

RunMyCode: Tekrarlanabilir araştırma için bir portal

Tekrarlanabilir Araştırma” ekolü, yaptığınız araştırmada her ne şekilde olursa olsun (simülasyon, veri analizi, nümerik çözüm) bilgisayar kullanıyorsanız, yarattığınız kaynak kodunu makalenizle beraber paylaşmanız gerektiğini savunur.

RunMyCode, hesaplama ve yazılım içeren bilimsel bir çalışma yaptığınızda, yayınıza eşlik edecek bir web sitesi hazırlamanızı sağlayan yeni bir portal.

Oluşturduğunuz site yazdığınız programları barındırmakla kalmıyor, onların interaktif şekilde çalıştırılmasını da sağlıyor. Programınız için gerekli giriş parametrelerini tanımlayarak bir grafik arayüz oluşturabiliyorsunuz. Programlar RunMyCode bilgisayarlarında çalıştırılıyor ve kullanıcı için bir rapor üretiyor. Elbette kullanıcılar isterlerse kaynak kodlarını da alabiliyorlar.

Sitenizi yaratırken kaynak kodunun nasıl çalıştığını, giriş ve çıkış parametrelerinin ne olduğunu belirlemeniz bekleniyor. Ayrıca örnek (demo) giriş verisi de vermeniz tercih ediliyor; böylece yazılımı denemek isteyen ama veri olarak ne yazacağını bilemeyen kullanıcılara bir başlangıç noktası sağlıyorsunuz.

Sitenizi 15 ila 45 dakika arasında hazırlayabiliyorsunuz, ama hemen devreye girmiyor. Önce bir bilimsel denetlemeden geçiyor, sonra da yazılımın uyumluluğu için teknik denetleme yapılıyor. Siteniz ancak bu denetlemelerden sonra açılıyor.

RunMyCode daha başlangıç aşamasında, ama gerek görsellik gerek kullanılabilirlik olarak üstün kalitede bir site. Eğer tutarsa (ki birkaç bilimsel kurum tarafından desteklendiği için tutma ihtimali yüksek) bilim üretimine büyük katkısı olacak.

Dezavantajlarından biri, programları sadece Matlab, R veya SAS dillerinde kabul etmesi. C, Java, Fortran, Python vs. şimdilik yok.

Başka bir dezavantajı alan sınırlaması. Sadece iktisat, işletme, ve istatistik alanlarındaki çalışmalar mevcut. Tahminimce bilimsel denetleme aşamasındaki uzmanlık sadece bu alanda. Veya belki sistemleri fen/mühendislik alanlarındaki daha yoğun hesaplama işlerine henüz hazır değildir. Zannediyorum sistemi oturtup otomatikleştirdikten sonra başka alanlara da açılırlar.

Bilimsel çalışmalarınızda simülasyon, algoritma geliştirme, veri analizi gibi işler yapıyorsanız bir gözünüz RunMyCode üzerinde olsun.


Bu vesileyle, tekrarlanabilir araştırma hakkında Scientific American’da çıkan “Secret Computer Code Threatens Science” başlıklı yazı da ilginizi çekebilir.

Uzayda bir deney: Elektrikli çubuk etrafında su damlaları

Uluslararası Uzay İstasyonu (ISS) astronotu Don Pettit, yerçekimsiz ortamda küçük fizik deneyleri yapıyor. Bunlardan birinde, plastik bir örgü şişini bir kağıt sürerek elektrikliyor ve yakınına şırıngayla su damlacıkları fışkırtıyor. Damlacıklar şişin etrafında dönüyor ve aynı zamanda şişe paralel olarak ileri geri gidiyorlar.

Bunun (en azından benim için) hoş ve şaşırtıcı tarafı damlaların bir noktadan sonra geri dönmesi. Tabii şiş ve damla karşı yüklü oldukları için damlanın (çok hızlı değilse) geri gelmesi beklenir, ama geri gelme hareketinin damla şişten uzaklaşmadan başlaması ilginç.

Temel fizik kullanarak bunun simülasyonunu yapmak kolay. Aşağıda verdiğim Python kodu, SciPy ile bu işi yapıyor. Görselleştirmeyi matplotlib veya Visual Python ile yapabiliriz.

Damlayı, bir metre uzunluktaki bir çubuğun ortası hizasında çubuğa beş santim mesafeden, ve çubuğa paralel bir düzlemde fışkırtırsak şöyle güzel bir yörünge elde ediyoruz.

Damlanın iki ayrı hareketi var: Çubuğa dik bir dairesel hareket (başlangıç hızını bunu elde edecek şekilde ayarladık) ve çubuk boyunca ileri geri hareket. Aynı videoda gördüğümüz gibi. Görüldüğü gibi damla çubuktan uzaklaşmadan geri dönüyor, yani çubuğun kenarına doğru bir potansiyel enerji duvarı var. Eğer damlanın paralel hızı biraz daha fazla olursa (kodda vx0 = -2*vz0 yapmayı deneyin) damla çubuktan kurtulup uzaklaşır gider.

Daha uzak mesafelerden başlayınca yörünge daha karmaşıklaşıyor. Meselâ aşağıdaki yörüngede damla çubuğun orta noktasından 50 santim uzaklıkta başlıyor.

Eğer damla çok uzaktan başlarsa çubuk bir nokta gibi görüneceği için yörünge yine basitleşir, bir düzlemde elips haline gelir.

Kullandığım Python kodu aşağıda. Parametrelerle oynayarak ilginç davranışlar gözleyebilirsiniz. İsterseniz bir tane daha damlacık ekleyip, damlacıkların birbirlerini itişini de denkleme katarak kaotik bir dans seyredebilirsiniz. VPython üç boyutlu çizim yaptığı için fareyle görüntüyü döndürebilir, içeri dışarı zumlayabilirsiniz.
Bu yazının geri kalanını okuyun

İki yeni preprint

Yeni yılın ilk yazısında geçen yılki araştırma işlerimi özetleyeyim istedim. Herkese mutlu, neşeli, sağlıklı ve özgür bir 2012 dileğiyle.

Kanaat dinamiği

Geçen yıl bu zamanlar, kanaat dinamiği konusunda giriştiğim bir çalışmayı yazmıştım. O sırada makaleyi Physica A‘ya göndermiştim; iki ay sonra suratıma attılar. Hiç utanmadan aynen Advances in Complex Systems‘e gönderdim. Yaklaşık altı ay sonra epeyce etraflı hakem raporları geldi; büyük değişiklikler istiyorlardı. Eh, yeni bir konuya tek başına girip el yordamıyla çalışınca böyle şeylere hazırlıklı olmak lâzım.

Hakem raporları başta moral bozucu olsa da, sebat ettiğinizde makaleyi daha kaliteli hale getirmenize yardımcı oluyorlar. İki aylık revizyonla müsveddeyi yarı yarıya tekrar yazdım; teorik hesaplar ekledim ve literatürü bir daha tarayıp makaleye daha iyi yedirdim. Kısalsın diye önceki versiyonun son kısımlarını sildim, ama eklenen malzeme sebebiyle yine de epey uzun kaldı.

Yeni halini Kasım sonunda dergiye gönderdim, halen ikinci değerlendirmeyi bekliyorum. İlgilenenler preprinti ArXiv’de bulabilirler: http://arxiv.org/abs/1112.4624

Tekrarlanabilir araştırma” prensiplerine uyarak, araştırmada kullandığım programların kaynak kodlarını (C ve Matlab) makaleyle beraber gönderdim. ArXiv sayfasında da aynı programlar mevcut. Bu programlarla sistemin davranışının animasyonunu gözleyebilir, sistemi otomatik olarak tekrar tekrar başlatıp istatistiklerini çıkarabilir, yer darlığından anlatamadığım veya aklıma gelmeyen davranışları inceleyebilirsiniz.

Kullandığım programları vermek fazladan zahmet çıkardı ama bunun çok önemli olduğuna inanıyorum. Yazılan programlar bir hesaplamalı bilim çalışmasının ayrılmaz parçalarıdır, o yüzden okuyucuya sunulmaları gerekir. Merak eden okuyucu baştan yazma zahmetine katlanmadan programı kendi çalıştırabilmeli, varsa hataları bulabilmeli, veya isterse yeni özellikler ekleyebilmeli.

Daha da önemlisi, programlarınızı başkasının da kullanabileceği şekilde düzenlerken bazı hataları da fark edebilirsiniz. Bende öyle oldu; temel simülasyon algoritmamda bir uyumsuzluk buldum ve sonuçları daha az verimli ama doğru bir algoritmayla tekrar ürettim.

Çok kişi kapalılığı tercih eder çünkü kapalılık zor durumda paçayı kurtarmalarını sağlar. Programları makaleyle beraber vermesem, ve gayretli biri programı baştan yazıp benimkiyle çelişen sonuçlar bulsa, “programda hata yapmışsındır” deyip işin içinden çıkabilirim. Karşılaştırmak için kaynak kodunu isteyen olursa “virüs sildi” diyebilirim veya okunamayacak karmakarışık bir kod gönderebilirim. Ama bu iyi bilimcilik olmaz. Nasıl ki bir matematikçi teoremlerinin ispatlarını vermeliyse, bir deneyci deney düzeneğini tarif etmeli ve edindiği verileri tam yayınlamalıysa, bilimsel programlar da aynen yayınlanmalı ve denetlenmeli, yoksa akıl yürütme sürecinde boşluklar oluşur.

Manyetik alandaki parçacıkların hareketi

Bu makale istemeden kanaat dinamiği ile aynı zamana denk geldi. American Journal of Physics fizik eğitimine yönelik makaleler yayınlayan bir dergidir. Ağustos sayısında uzay fiziği ve astronomi araştırmalarının fizik eğitiminde kullanılması hakkında bir özel sayı için bir makale çağrısı gördüm. Şansıma, evliya sabrıyla bana katlanan Richard Wolf sayesinde elektrik yüklü parçacıkların (elektron, iyon) manyetik alandaki hareketleri hakkında üç beş bilgi kırıntısı edinmiştim. Böyle bir makale için çok uygun bir konu olduğunu düşündüm.

Uzay fiziği ve plazma fiziği kitaplarında parçacık dinamiği en ince ayrıntısına kadar anlatılır, ama standart derslerin kitaplarında rastlanmaz. Yazık, çünkü meselâ adiabatik değişmezler gibi soyut konuları somutlaştırmak için güzel bir örnek teşkil ederler. Bu konunun temel kavramlarını özetleyip biraz da hesaplamalı problemler eklersem, klasik mekanik, elektromanyetizma, ve hesaplamalı fizik derslerinde kullanılabilecek bir malzeme hazırlamış olurum diye düşündüm.

Dünyanın manyetik alanında olup bitenleri basitçe özetledikten sonra, radyasyon kuşağı tabir edilen bölgedeki parçacıkların hareketini gösterdim. Hareket bayağı enteresandır; kendi üzerine iki kat sarılmış bir sarmal gibi:

Bu dinamikte değişik büyüklükler ve hızlarda seyreden üç ayrı periyodik hareket var. Her biri için, yaklaşık sabit olan bir “adiabatik değişmez” tanımlayıp, hareketi bunlar cinsinden ifade etmek mümkün, ki harcıâlem bir yöntemdir.

Kendi öğrenciliğimde fiziksel problemleri program yazarak incelemeye heves ederdim, ama konular hiç programlamaya uygun şekilde sunulmazdı. Ders kitaplarının çoğu hâlâ bu yönden eksiktir. Bu yüzden bu konuyu hesaplama odaklı şekilde sunmaya çalıştım. Okuyucunun şekilleri kendi üretebileceği, değiştirip denemeler yapabileceği Python programları hazırladım. Makalenin sonuna, basitten karmaşığa doğru, birbirini destekleyen oniki hesaplama problemi ekledim. Makalenin tamamında, problemler dahil, aktif araştırma ile pedagojiyi dengelemeye çalıştım.

Anlaşılan doğru düşünmüşüm ki hakem raporları olumlu geldi. İstenilen birkaç küçük değişiklikten sonra hakemlerden kabul aldı, şimdi editoryal incelemede. İlgilenenler için preprint ve programlar ArXiv’de: http://arxiv.org/abs/1112.3487

Hamiş

Ikına sıkına yaptığın ıvır zıvır işleri amma da ballandırarak anlattın, görgüsüz” demek geçebilir içinizden. Ne diyeyim, haklısınız. Başkaları blogunda çocuğunu, kedisini, köpeğini anlatır, ben de bunları anlatıyorum, ne yapayım.