Otomatik Alım Satım Sistemleri Oluşturmada Yeni Bir Yaklaşım Olarak Otomat Tabanlı Programlama
253
0
ἓν οἶδα ὅτι οὐδὲν οἶδα ( ο φιλόσοφος Σωκράτης )
Bildiğim tek şey hiçbir şey bilmediğimdir (filozof Sokrates)
Giriş
Başlangıç olarak, bu konu MetaQuotes Language 4/5 (MQL4/5) kullanarak EA geliştiren yatırımcılar için tamamen yenidir. MetaQuotes web sitesinde ilgili bir arama yapmaya çalıştığımda kendim görebildim. Bu konuyla ilgili bir şey yok.
Her yatırımcı, programlama ve çok karmaşık program mantığı ile ilgili her türlü sorunun üstesinden gelmek için ciddi bir yaklaşım gerektiren kendi Uzman Danışmanını yaratır. Günün sonunda, programın herhangi bir standart ve mücbir sebep durumunda saat gibi KENDİ KENDİNE çalışması beklenir.
Ama tek başına nasıl her şeyin üstesinden gelebilir? Bu son derece zordur, bu nedenle otomatik kontrol sistemleri, Otomat Tabanlı Programlamanın tek uygun programlama teknolojisi kullanılarak en iyi şekilde elde edilebilecek tüm kontrol sistemlerinin uygun şekilde programlanmasını gerektirir. Son yıllarda, yazılım kalitesi için yüksek gereksinimler belirleyen gömülü ve gerçek zamanlı sistemler için programlama teknolojilerinin geliştirilmesine büyük ilgi duyulmaktadır.
1991 yılında Rus yazar A.A. Shalyto (Öğretim Görevlisi, Profesör, Mühendislik Yüksek Lisansı, "Programlama Teknolojileri" Bölüm Başkanı SPbSU ITMO) "otomat tabanlı programlama" adını verdiği bir programlama teknolojisi geliştirdi. Okuyucuların otomat tabanlı programlamanın veya SWITCH teknolojisinin ne kadar basit olabileceğini gördüklerinde şaşıracaklarına inanıyorum. MetaQuotes Dilini kullanarak MTS'nin geliştirilmesini o kadar kolay hale getirir ki, bundan daha iyisi olamaz. Ve karmaşık karar verme sistemine mükemmel uyum sağlar.
1. Problem İçin Çalışmak
Tüm problem yaratıcılarının ve yazılım geliştiricilerinin uzun zamandır hayalini kurdukları şey, problem (algoritma) için planlı bir çözüme sahip olmak ve bu algoritmanın onunla tamamen uyumlu bir şekilde uygulanmasıdır. Ancak, yaratıcılar ve geliştiriciler için işler bu şekilde yürümüyor gibi görünüyor. Algoritmalar, geliştiricilerin uygulamada neye önem verdiğini görmezden gelme eğilimindeyken, program metni kendi başına algoritmaya çok az benzerlik gösterir.
Bu nedenle, iki algoritma vardır - biri kağıt üzerinde (tasarım çözümlerini kaydetmek ve belgelemek için), belirli bir sonucu elde etmek için kullanılan yöntemler yerine genellikle belirli bir tasarım sonucunu temsil ederken, ikinci algoritma geliştiricinin zihnindedir (ancak , ayrıca metin olarak kaydedilir).
Program metninin son halini, çoğu zaman, yine pek çok şeyin hesaba katılmadığı, belgeleri değiştirme girişimleri izler. Bu durumda, program mantığı büyük olasılıkla algoritmanın mantığından farklı olabilir, bu da bir eşleşme eksikliğini gösterir. Hiç kimse birinin program metnini kontrol etmeyeceği için kasıtlı olarak 'büyük olasılıkla' diyorum.
Program büyükse, algoritmaya karşılık gelip gelmediğini sadece metinle kontrol etmek imkansızdır. Uygulamanın doğruluğu, 'test' adı verilen bir prosedür kullanılarak kontrol edilebilir. Temel olarak geliştiricinin algoritmayı (kağıt üzerine yerleştirilmiş) nasıl kavradığını, zihninde başka bir algoritmaya nasıl dönüştürdüğünü ve nasıl bir program olarak çıkarttığını kontrol eder. Sonunda, geliştirici, mantıkla ilgili değerli bilgilerin tek sahibidir ve uygulamadan önce oluşturulan her şey kesinlikle alakasız hale gelir.
Geliştiricinin hastalanması (veya... istifa etmesi) bile söz konusu değildir. Mesele şu ki, temel program mantığı, zekalarına ve bir programlama dili bilgisine bağlı olarak her geliştiricide farklı olacaktır. Her durumda, geliştirici uygun gördüğü birçok ara değişkeni tanıtır ve kullanır. Ve program büyük ve mantıksal olarak karmaşıksa, aksaklıkları bulmak için (ve burada işletim sistemi hatalarını veya dil fonksiyonlarının yanlış kullanımını kastetmiyorum, daha ziyade mantık açısından yanlış bir uygulama) ve bunu program metninin kendisi aracılığıyla çözmek için daha kalifiye bir uzman gerekecektir.
Geliştiricilerin çoğu, en azından söylemek gerekirse, programlamadan önce algoritmaları yazmaya (hatta kağıda çizmeye) hevesli değiller, bu da muhtemelen yol boyunca kendi başlarına bir şeyler düşünmeye ihtiyaç duyacakları gerçeğinden kaynaklanıyor. Gerçekten de, hemen programlamaya geçmek ve daha sonra dokümantasyonda biraz benzer veya çok genel bir algoritma düzenlemek daha iyiyken, neden bazı dikdörtgenler, elmaslar ve oklar çizmek için zaman harcansın ki?
Herkes buna alıştı - geliştiriciler bunu böyle daha kolay olduğu için yapıyor, ancak problem yaratıcılar her zaman gereken ölçüde programlama becerilerine sahip değiller ve öyle olsalar bile, geliştiricilerin yaptıklarında zamanında bir değişiklik gerçekleştiremiyorlar. Uygun programlama ortamları da belirtilen geliştirme sırasının geçerliliğine katkıda bulunuyor. Değişkenlerin hatalarını ayıklamak ve değerlerini izlemek için gelişmiş araçlar, mantıktaki herhangi bir hatayı algılamak için bize umut veriyor.
Zaman akıp giderken ve proje son teslim tarihi yaklaşırken, geliştirici oturuyor ve bu arada hala uygulanması gereken belirli bir mantıksal soruna "peçete" çözümlerini çiziyor ve test için test sırasında gözden kaçan hataların yanı sıra, hemen hemen aynı (kaotik) senaryo... Mevcut durum bu. Bir çözüm var mı veya en azından geliştirilebilir mi? Standart bir şekilde düzenlenmiş bir algoritmadan program koduna geçişte önemli bir şey eksik gibi.
2. Programın Mantıksal Bölümü
"Otomat tabanlı programlama"nın yazarı, aşağıdaki programın ideal mantıksal parçası kavramını önerdi. Programın tüm mantığı seçim üzerine kuruludur. Basitçe söylemek gerekirse, herhangi bir kontrol algoritması (otomat) aşağıda gösterildiği gibi uygulanabilir (bu noktada yorumların anlamı hakkında fazla düşünmeyin, yapıya bir göz atın).
switch(int STATUS ) // Мulti-valued global state variable of the automaton. { case 0: // start // Checking arc and loop conditions (in order of priority), // transition (change of the value of the variable STATUS) // and execution of arc and loop actions (output function execution); // logging transitions and actions if the condition is met. 0 // Calling nested automata. // Execution of output functions in the state. break ; case 1: // Checking arc and loop conditions (in order of priority), // transition (change of the value of the variable STATUS) // and execution of arc and loop actions (output function execution); // logging transitions and actions if the condition is met. // Calling nested automata. // Execution of output functions in the state. break ; ********* ********* ********* case N-1: // Checking arc and loop conditions (in order of priority), // transition (change of the value of the variable STATUS) // and execution of arc and loop actions (output function execution); // logging transitions and actions if the condition is met. // Calling nested automata. // Execution of output functions in the state. break ; case N: // Checking arc and loop conditions (in order of priority), // transition (change of the value of the variable STATUS) // and execution of arc and loop actions (output function execution); // logging transitions and actions if the condition is met. // Calling nested automata. // Execution of output functions in the state. break ; }
3. Yazar A.A. Shalyto’nun Açıkladığı Gibi Otomat Tabanlı Programlama
Geliştirme teknikleri ne olursa olsun, herhangi bir programın belirli bir zamanda tüm veri değerleri tarafından belirlenen durumları vardır. Büyük bir uygulama programında yüzlerce hatta binlerce değişken ve birkaç kontrol akışı olabilir. Bu değişkenlerin tam bir seti, herhangi bir belirli zamanda uygulama programının durumunu tanımlar.
Program durumu, tüm geçiş koşullarında yer alan tüm kontrol değişkenlerinin değerlerinin bir toplamı olarak daha basit bir şekilde ele alınabilir. Kontrol değişkenlerinden birinin değerindeki bir değişiklik, daha sonra program durumunda bir değişiklik anlamına gelecektir ve program durumlarının sayısı, program çalışması sırasında ortaya çıkan kontrol değişkeni değerlerinin mümkün olan maksimum kombinasyon sayısı tarafından belirlenecektir. Bir programda yalnızca ikili kontrol değişkenlerinin (bayrakların) kullanıldığını varsayalım. n ikili kontrol değişkeni içeren programın durum sayısı bu durumda n ile 2n aralığında olacaktır.
Geliştirici, kontrol değişkeni değerlerinin tüm kombinasyonlarına (bizim durumumuzda 2n kombinasyon) tepkiler vermiş olabilir. Ancak, kontrol değişkeni değerlerinin (2n-n'ye kadar) bazı kombinasyonlarının belirtilmemiş olması daha olasıdır. Bu durumda, beklenmedik girdi eylemleri kombinasyonu ortaya çıkarsa, program belirtilmemiş bir duruma geçebilir.
Aşağıdaki olaylarda bir yatırımcı için bir EA'nın eylemsizliği ile aynı etkiye sahiptir:
- boşluk,
- mevduat kaybı,
- sonraki Marj Çağrısı ile negatif bakiye durumuna düşme,
- kırmızıda sıfıra ve daha ileriye giderek iyi kar almamak,
- uzunlarla kısaların yanlış açılıp kapanması,
- diğer bariz olumsuz durumlar.
Bu tür durumlara "öngörülmemiş" denir. Karmaşıklık, programın tüm olası durumlarını sıralamada ve anlamada güçlüğe neden olur, bu da güvenilmezliğine yol açar... Yapının karmaşıklığı, güvenlik kapılarını oluşturan öngörülmemiş durumların kaynağıdır. Belirtilmemiş bir durumdaki program davranışı, bellek koruma hatalarından programı yeni fonksiyonlara genişletmeye ve çeşitli nitelikte yan etkiler oluşturmaya kadar değişebilir.
Pek çok PC kullanıcısı ve muhtemelen tüm yazılım geliştiriciler, kullanımda olan veya geliştirilmekte olan bir programın belirsiz bir duruma geldiği durumlarla çok kez karşılaşmıştır.
Programda belirtilmemiş durumların olasılığını ortadan kaldırmak için, gerekli tüm durumlar tasarım aşaması gibi erken bir aşamada açıkça belirtilmeli ve aralarında ayrım yapmak için yalnızca bir çok değerli kontrol değişkeni kullanılmalıdır. O zaman, durumlar arasındaki tüm olası geçişleri belirlemek ve 'sapmaması' için bir program geliştirmek gerekir.
Program davranışının geliştirilmesinde titiz olmak için üç bileşen gereklidir:
- Program durumlarını ve bunlar arasındaki olası geçişleri açık bir şekilde tanımlamaya izin veren matematiksel model;
- Bu model için grafiksel gösterim;
- Bu gösterimde ifade edilen algoritmaların uygulanması için evrensel yöntem.
Matematiksel bir model olarak kullanılmak üzere "durum" kavramına dayalı sonlu bir otomat önerilmiştir. Otomat tabanlı programlama, tasarım, uygulama, hata ayıklama ve dokümantasyon gibi yazılım geliştirme aşamalarını destekler.
'Olay' terimi son yıllarda programlamada daha yaygın olarak kullanılırken, önerilen yaklaşım 'durum' kavramına dayanmaktadır. Bunu, bir girdi değişkeni veya bir olay olabilen 'giriş eylemi' terimiyle birleştirdikten sonra, 'çıktısız otomat' terimi tanıtılabilir. Çıktısız otomattan sonra 'çıktı eylemi' terimi gelir ve daha sonra (deterministik sonlu) otomat kavramı gelir. Bu konsepte dayalı programlama alanı bu nedenle otomat tabanlı programlama olarak adlandırılır ve ilgili geliştirme süreci otomat tabanlı program tasarımı olarak adlandırılır.
Belirtilen yaklaşım, uygulandığında otomatların geçiş grafikleri ile temsil edilmesi bakımından özeldir. Düğümleri arasında ayrım yapmak için 'durum ataması' terimi tanıtılmıştır. Bir 'çok değerli durum ataması' seçildiğinde, sayısı seçilen değişkenin alabileceği değerlerin sayısıyla çakışan durumlar, yalnızca bir değişken kullanılarak türevlenebilir. Bu gerçek, programlamaya 'program gözlemlenebilirliği' teriminin eklenmesine izin vermiştir.
Önerilen yaklaşım kapsamındaki programlama, sorunu ve bileşenlerini daha iyi anlamaya ve belirlemeye yardımcı olan 'değişkenler' (bayraklar) yerine 'durumlar' aracılığıyla gerçekleştirilir. Bu durumda hata ayıklama, otomatlar açısından günlük kaydı ile yapılır.
Yukarıdaki yaklaşım, formal ve izomorfik bir yöntem kullanarak geçiş grafiğinden program koduna geçmeyi önerdiğinden, yüksek seviyeli programlama dilleri kullanıldığında bunu switch (seçim) yapıları uygulayarak yapmak daha mantıklı görünmektedir. Bu nedenle, otomat tabanlı programlama paradigmasından bahsederken 'SWITCH teknolojisi' teriminin kullanılmasına karar verildi.
4. Açık Durum Tabanlı Programlama
Otomat tabanlı yaklaşımın uygulaması, 'reaktif' olarak da adlandırılan olaya dayalı sistemlere daha da genişletildi. Reaktif sistemler, çevre tarafından belirlenen oranda mesajları kullanarak çevre ile etkileşime girer (aynı sınıfa bir EA dahil edilebilir).
Otomat kullanan olaya dayalı sistemlerin geliştirilmesi, açık durum tabanlı programlama adının türetildiği prosedürel yaklaşım kullanılarak mümkün olmuştur. Çıktı eylemleri bu yöntemde geçiş grafiklerinin yaylarına, döngülerine veya düğümlerine atanır (karma otomatlar - Moore ve Mealy otomatları - kullanılır). Bu, ilgili girdi eylemlerine verilen tepkiler olan eylem dizisinin kompakt bir temsilini elde etmeyi sağlar.
Verilen sistem sınıfını programlamak için önerilen yaklaşım, olay işleyicilerden elimine edilmesi ve işleyicilerden çağrılan birbirine bağlı otomatlardan oluşan bir sistemin oluşturulması nedeniyle mantığın daha fazla merkezileştirilmesini içerir. Böyle bir sistemdeki otomatlar arasındaki etkileşim, durum sayılarının iç içe geçirilmesi, çağrılması ve değiştirilmesiyle sağlanabilir.
Birbirine bağlı otomatlar sistemi, sistemden bağımsız bir program parçası oluştururken, sisteme bağlı bir kısım, giriş ve çıkış eylem fonksiyonları, işleyiciler, vb. tarafından oluşturulur.
Bu yaklaşımın bir diğer önemli özelliği, uygulandığında otomatların üçlü bir şekilde kullanılmasıdır:
- spesifikasyon için;
- uygulama için (program kodunda kalırlar);
- otomatlar açısından günlük kaydı için (yukarıda belirtildiği gibi).
Sonuncusu, otomat sistem çalışmasının doğruluğunu kontrol etmeye izin verir. Günlük kaydı, geliştirilen program temelinde otomatik olarak gerçekleştirilir ve karmaşık program mantığına sahip büyük ölçekli problemler için kullanılabilir. Bu durumda her günlük, ilgili bir komut dosyası olarak kabul edilebilir.
Günlükler, programın çalışırken izlenmesine izin verir ve otomatların 'resim' değil, gerçek aktif varlıklar olduğu gerçeğini gösterir. Otomat tabanlı yaklaşımın sadece bir kontrol sistemi oluşturulurken değil, aynı zamanda kontrol nesnelerinin modellenmesinde de kullanılması önerilmektedir.
5. Otomat Tabanlı Programlamanın Temel Kavramları
Otomat tabanlı programlamanın temel konsepti DURUM’dur. Herhangi bir belirli zamanda t0 sistem durumunun ana özelliği, geleceği (t > t0) geçmişten (t < t0) 'ayırmaktır', çünkü mevcut durum sistemin geçmişi hakkında herhangi bir belirli zamanda t0 üretilen herhangi bir giriş eylemine tepkilerini belirlemede gerekli olan tüm bilgileri içerir.
DURUM terimini kullanırken tarihsel verilerin bilinmesi gerekli değildir. Durum, varlığın şu andaki tepkisini etkileyen geçmişin tüm giriş eylemlerini örtük olarak birleştiren özel bir özellik olarak kabul edilebilir. Tepki şimdi yalnızca giriş eylemine ve mevcut duruma bağlıdır.
'Giriş eylemi' kavramı aynı zamanda otomat tabanlı programlamadaki anahtar kavramlardan biridir. Bir girdi eylemi en yaygın olarak bir vektördür. Bileşenleri, anlam ve üretim mekanizmasına bağlı olarak olaylara ve girdi değişkenlerine ayrılır.
Sonlu durumlar kümesinin ve sonlu giriş eylemleri kümesinin birleşimi, çıktısı olmayan (sonlu) bir otomat oluşturur. Bu tür bir otomat, mevcut durumunu belirli bir şekilde değiştirerek giriş eylemlerine tepki verir. Durumların değiştirilebileceği kurallara otomat geçiş fonksiyonu denir.
Otomat tabanlı programlamada (sonlu) otomat olarak adlandırılan şey, temelde "çıktısız otomat" ve "giriş eylemi"nin birleşimidir. Bu tür bir otomat, giriş eylemine yalnızca durumunu değiştirerek değil, aynı zamanda çıkışlarda belirli değerler üreterek tepki verir. Çıktı eylemleri oluşturma kurallarına, otomat çıktı fonksiyonu denir.
Karmaşık davranışa sahip bir sistem tasarlarken, belirli bir dizi işlemle mevcut kontrol nesnelerini ve dış (market) ortamda ortaya çıkabilecek belirli bir dizi olayı hareket noktası olarak almak gerekir.
Uygulamada, tasarım daha yaygın olarak kontrol nesneleri ve olaylar üzerine kuruludur:
-
Problemin ilk verileri sadece sistemin hedef davranışının sözlü bir tanımı değil, aynı zamanda sisteme dış ortamdan gelen olaylar dizisinin ve tüm kontrol nesnelerinin çok sayıda istek ve komutunun (az ya da çok) doğru bir şekilde belirtilmesidir.
-
Bir dizi kontrol durumu oluşturulur.
-
Kontrol nesnelerinin her isteğine, otomatın karşılık gelen bir giriş değişkeni atanırken, her komuta karşılık gelen bir çıkış değişkeni atanır. Kontrol durumları, olaylar, giriş ve çıkış değişkenleri bazında gerekli sistem davranışını sağlayacak olan otomat inşa edilmiştir.
6. Program Özellikleri ve Avantajları
Otomat tabanlı bir programın ilk özelliği, bir dış döngünün varlığının gerekli olmasıdır. Temelde yeni bir şey yok gibi görünüyor; buradaki en önemli şey, bu döngünün tüm programın mantıksal bölümündeki tek döngü olacağıdır! (yani gelen tik.)
İkinci özellik, ilkinden sonra gelir. Herhangi bir otomat, tüm mantıksal işlemleri içeren bir geçiş yapısı (aslında sanal olarak ondan yapılmıştır) içerir. Bir otomat çağrıldığında kontrol 'case' etiketlerinden birine aktarılır ve ilgili işlemlerden sonra bir sonraki başlatmaya kadar otomat (alt program) işlemi tamamlanır. Bu eylemler, geçiş koşullarının kontrol edilmesinden oluşur ve belirli bir koşulun karşılanması durumunda ilgili çıkış fonksiyonları çağrılır ve otomat durumu değiştirilir.
Yukarıda belirtilenlerin ana sonucu, bir otomatın uygulanmasının sadece basit olması değil, en önemlisi programın, her otomattaki işlevselliği çok değerli bir durum değişkeni tarafından sağlanan birçok ara mantıksal değişken (bayrak) olmadan da çalışabilmesidir.
Çok fazla düşünmeden çok fazla global ve yerel değişken (bayrak) kullanmaya alıştığımız için son ifadeye inanmak zor. Onlarsız nasıl yapabiliriz?! Bunlar genellikle bir koşulun karşılandığını programa bildiren bayraklardır. Bayrak, geliştirici gerekli gördüğünde (TRUE olarak) ayarlanır, ancak daha sonra (genellikle yalnızca bayrak her zaman TRUE olarak istenen etkilere yol açmaya başladıktan sonra), programın başka bir yerinde FALSE’a sıfırlanmaya zorlanır.
Tanıdık geliyor değil mi? Şimdi örneğe bir göz atın ve bakın: Burada ek değişkenler kullanılmaz; değişiklik yalnızca durum numarasının değeriyle ilgilidir ve yalnızca mantıksal bir koşul karşılandığında söz konusudur. Bayraklar için değerli bir yedek değil mi?!
Algoritma, bir programın mantıksal bir bölümünü oluşturmada önemli bir rol oynar. Burada hatırlanması gereken anahtar kelime 'mantıksal kısım'dır. Bu durumda her şeyin temelinde durum vardır. Eklenmesi gereken bir diğer kelime ise 'beklemek'tir. Ve bence, oldukça yeterli bir 'bekleme durumu' tanımına sahibiz. Durumdayken, girdi eylemlerinin (nitelikler, değerler veya olaylar) ortaya çıkmasını bekleriz. Bekleme kısa veya uzun olabilir. Veya başka bir deyişle, istikrarsız ve istikrarlı olabilen durumlar vardır.
Durumun ilk özelliği, durumda sınırlı sayıda bir giriş eylemi kümesinin beklenmesidir. Herhangi bir algoritma (ve tabii ki herhangi bir program) girdi ve çıktı bilgilerine sahiptir. Çıktı eylemleri iki türe ayrılabilir: değişkenler (örn. nesne özelliği işlemleri) ve fonksiyonlar (örn. uygulama başlatma fonksiyonu çağrısı, rapor fonksiyonu vb.).
Durumun ikinci özelliği, çıktı değişkenlerinin bir dizi doğru değerinin sağlanmasıdır. Bu, çok basit ama son derece önemli bir durumu ortaya koymaktadır - algoritma (program) her zaman belirli bir durumda olduğu için tüm çıktı değişkeni değerleri herhangi bir zamanda belirlenebilir.
Durum sayısı, çıktı değişken değerlerinin sayısı gibi sınırlıdır. Geçişleri kaydetme fonksiyonu, otomat fonksiyonuna sorunsuz bir şekilde entegre edilmiştir ve durumlar arasındaki geçişlerin sırası ve ayrıca çıktı eylemlerinin teslimi sonuç olarak her zaman belirlenebilir.
Özelliklerin tam listesi 2 bölümünde verilmiştir. Önerilen Teknolojinin özellikleri ve avantajların tam listesi 3 bölümünde bulunabilir. Önerilen Teknolojinin Avantajları. Bu makale, konuyla ilgili çok geniş miktardaki bilgiyi kapsayamaz! Anatoly Shalyto tarafından yazılan tüm araştırma literatürünün kapsamlı bir incelemesinden sonra, tüm teorik sorular doğrudan kendisinin shalyto@mail.ifmo.ru adresine yöneltilmelidir.
Hedeflerimizi ve sorunlarımızı göz önünde bulundururken onun bilimsel fikirlerini kullanarak, aşağıda, otomat tabanlı programlama teknolojisini uygulamamın üç örneğini vereceğim.
7. Otomat Tabanlı Programlama Örnekleri
7.1. Anlamaya Yönelik Örnek
Durum sadece sistemin içinde var olduğu bir moddur. Örneğin su 3 halde bulunur: katı, sıvı veya gaz. Bir değişkenden - sıcaklık (sabit basınçta) - etkilendiğinde bir halden diğerine geçer.
Zamana dayalı bir Sıcaklık (t) grafiğimiz olduğunu varsayalım (bizim durumumuzda fiyat değeri):
int STATUS=0; // a global integer is by all means always a variable !!! STATUS is a multi-valued flag //----------------------------------------------------------------------------------------------// int start() // outer loop is a must { switch(STATUS) { case 0: //--- start state of the program if(T>0 && T<100) STATUS=1; if(T>=100) STATUS=2; if(T<=0) STATUS=3; break; case 1: //--- liquid // set of calculations or actions in this situation (repeating the 1st status -- a loop in automata-based programming) // // and calls of other nested automata A4, A5; if(T>=100 ) { STATUS=2; /* set of actions when transitioning, calls of other nested automata A2, A3;*/} if(T<0) { STATUS=3; /* set of actions when transitioning, calls of other nested automata A2, A3;*/} // logging transitions and actions when the condition is met. break; case 2: //--- gas // set of calculations or actions in this situation (repeating the 2nd status -- a loop in automata-based programming) // // and calls of other nested automata A4, A5; if(T>0 && T<100) { STATUS=1; /* set of actions when transitioning, calls of other nested automata A2, A3;*/} if(T<=0) { STATUS=3; /* set of actions when transitioning, calls of other nested automata A2, A3;*/} // logging transitions and actions when the condition is met. break; case 3: //--- solid // set of calculations or actions in this situation (repeating the 3rd status -- a loop in automata-based programming) // // and calls of other nested automata A4, A5; if(T>0 && T<100) {STATUS=1; /* set of actions when transitioning, calls of other nested automata A2, A3;*/} if(T>=100) {STATUS=2; /* set of actions when transitioning, calls of other nested automata A2, A3;*/} // logging transitions and actions when the condition is met. break; } return(0); }
Program, basınç parametresi P ve yeni durumlar eklenerek ve şemada gösterilen karmaşık bir bağımlılık eklenerek daha karmaşık hale getirilebilir:
Bu otomat 32 = 9 geçiş koşuluna sahiptir, bu nedenle hiçbir şey atlanamaz veya gözden kaçırılamaz. Bu tarz, talimat ve kanun yazarken de çok kullanışlı olabilir! Burada boşluklara ve yasaların atlanmasına izin verilmez - olayların ardışık varyantlarının tüm kombinasyonları kapsanmalı ve tüm durumlar açıklanmalıdır.
Otomat tabanlı programlama, olayların bazı ardışık varyantları aksi halde düşünülmese bile her şeyi hesaba katmamızı gerektirir; bu nedenle, tutarlılık ve bütünlük için yasaları, talimatları ve kontrol sistemlerini kontrol ederken ana araçtır. Matematiksel bir yasa da vardır:
Geçiş diyagramı: N = 3 durum, geçiş ve döngü sayısı N2 = 9'dur (ok sayısına eşittir).
Örnekteki değişken sayısı farklıysa, o zaman:
Tabloda hesaplanan tüm değerlerin katlanarak arttığını göstermektedir, yani tasarım, ana sistemik değişkenlerin seçiminde titizlik gerektiren karmaşık bir işlemdir.
Sadece iki parametre olsa bile her şeyi anlatmak çok zor! Ancak pratikte her şey çok daha kolay! Mantığa ve anlama bağlı olarak %50-95 geçişler fiziksel olamaz ve durum sayısı da %60-95 daha azdır. Bu mantık ve anlam analizi, tüm geçişleri ve durumları tanımlamanın zorluğunu büyük ölçüde azaltır.
Daha karmaşık durumlarda, bir EA'daki bilinen tüm girdi ve çıktı verileri için maksimum durum sayısının hesaplanması gerekir. Bu sorunun çözümü, kombinatorikler vekombinasyon, permütasyon, düzenleme ve numaralandırmalı kombinatorik formülleri uygulanarak bulunabilir.
7.2. Histerezisli Geçiş
Bir EA'da geçişlerin, tetikleyicilerin, kayıtların, sayaçların, kod çözücülerin, karşılaştırıcıların ve diğer doğrusal olmayan dijital ve analog kontrol sistemi öğelerinin programlanması çok uygun olabilir.
- xmax = 100 - maksimum alma değeri;
- xmin = -100 - minimum alma değeri;
- x = x(t) - girişteki sinyal;
- Y = Y(t) - çıkıştaki sinyal.
int status=0; // at the beginning of the program we globally assign //------------------------------------------------------------------// switch(status) { case 0: // start Y=x; if(x>xmax) {status=1;} if(x<xmin) {status=2;} break; case 1: //++++++++++++++++++++ if(x>xmax) Y=x; if(x<xmax) Y=xmin; if(x<=xmin) {status=2; Y=xmin;} break; case 2: //-------------------- if(x<xmin) Y=x; if(x>xmin) Y=xmax; if(x>=xmax) {status=1; Y=xmax;} break; }
Geçiş özelliği:
7.3. 9 Durum ve Olayların Ardışık 81 Varyantı için Şablon
Y, 1'den 9'a kadar otomatın mevcut giriş durumudur. Y değeri, verilen alt programın dışında EA'da üretilir. MEGASTATUS, Y'nin geçmiş halidir.
int MEGASTATUS=0; // at the beginning of the program we globally assign //---------------------------------------------------------------------// void A0(int Y) // automaton template { switch(MEGASTATUS) { case 0: // start MEGASTATUS=Y; break; case 1: // it was the past // it became current, repeating if(Y=1) { /*set of actions in this situation, calls of other nested automata A2, A3, ... */ } // Loop// // new current if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } if(Y=6) { /* set of actions in this situation */ } if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 2: // it was the past // it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } //Loop// if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } // e.g. if the transition from 2 to 6 is in essence impossible or does not exist, do not write anything if(Y=6) { /* set of actions in this situation */ } // the automaton will then be reduced but the automaton template shall be complete to count in everything if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 3: // it was the past // it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } //Loop// if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } if(Y=6) { /* set of actions in this situation */ } if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 4: // it was the past // it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } //Loop// if(Y=5) { /* set of actions in this situation */ } if(Y=6) { /* set of actions in this situation */ } if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 5: // it was the past // it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } //Loop// if(Y=6) { /* set of actions in this situation */ } if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 6: // it was the past // it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } if(Y=6) { /* set of actions in this situation */ } //Loop// if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 7: // it was the past //it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } if(Y=6) { /* set of actions in this situation */ } if(Y=7) { /* set of actions in this situation */ } //Loop// if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 8: // it was the past // it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } if(Y=6) { /* set of actions in this situation */ } if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } //Loop// if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 9: // it was the past // it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } if(Y=6) { /* set of actions in this situation */ } if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } //Loop// // logging transitions and actions when the condition is met. break; } MEGASTATUS=Y; }
7.4. Ses Çalar Otomat
Bir Simple Audio Player'ı inceleyelim.
Bu cihaz 6 durumda olabilir:
- Hazır;
- Parça Yok;
- Oynatıyor;
- İleri Sarma;
- Geri sarma;
- Duraklat.
Müzik çalar kontrol sistemi bir otomat ile temsil edilir. Basılan düğmeler, otomat üzerinde etkili olan olaylar olarak kabul edilir. Parçalar arasındaki geçişler, oynatma, ekran kontrolü vb. çıktı işlemleridir.
switch(STATUS) { case 0: //--- "Ready" if(Event == 3) { STATUS = 3; } //«>>» button pressed if(Event == 6) { STATUS = 1; } //Audio file not found if(Event == 1) { STATUS = 2; } //«PLAY» button pressed z1(); // Set the indicator to the initial state break; case 1: //--- "No Track" z6(); // Give the «No Track» message break; case 2: //--- "Playing" if(Event == 4) { STATUS = 4; } //«<<» button pressed if(Event == 5) { STATUS = 5; } //«PAUSE»( | | ) button pressed if(Event == 3) { STATUS = 3; } //«>>» button pressed if(Event == 2) { STATUS = 0; } //«STOP» button pressed z2(); // Playing break; case 3: //--- "Fast-Forward" z3(); // Next track { STATUS=2; } break; case 4: //--- "Rewind" z4(); // Previous track { STATUS=2; } break; case 5: //--- "Pause" if(Event == 5) { STATUS = 2; } //«PAUSE» button pressed if(Event == 1) { STATUS = 2; } //«PLAY» button pressed if(Event == 2) { STATUS = 0; } //«STOP» button pressed if(Event == 3) { STATUS = 3; } //«>>» button pressed if(Event == 4) { STATUS = 4; } //«<<» button pressed z5(); //Pause break; }
Teorik olarak, bu otomat 36 geçiş varyantı içerebilir, ancak yalnızca 15'i gerçekten mevcuttur ve tüm ayrıntılar yazar tarafından sağlanan açıklamada bulunabilir.
8. А.А. Shalyto'nun Proje Yürütmeye İlişkin Önerileri
Proje belgelerinin nasıl hazırlanacağı ve yazılacağı ile ilgili tüm bilgileri burada bulabilirsiniz hhttp://project.ifmo.ru/books/3, bu makalede ise sizle sadece kısa bir alıntıyı paylaşacağım:
- A.A. Shalyto'nun kitabı "Logic Control. Methods of Hardware and Software Implementation of Algorithms. SPb.: Nauka, 2000", belirtilen web sitesinde bulunan "Kitaplar" bölümünde prototip olarak alınabilir". Rusya'daki en eski ve en itibarlı yayıncılık şirketi tarafından yayınlandığı için doğru bir bilgi sunumu içerir.
- Giriş, seçilen konunun uygunluğu için gerekçeler vermeli, incelenen sorunu kısaca belirtmeli ve projede kullanılan programlama dilini ve işletim sistemini belirtmelidir.
- Eldeki sorunun ayrıntılı bir sözlü açıklaması, ele alınan sorunu açıklayan şekiller, diyagramlar ve ekran görüntüleri ile birlikte "Problem Açıklaması" bölümünde sağlanmalıdır.
- Nesne yönelimli programlamayı kullanırken, "Tasarım" bölümü bir sınıf diyagramı içermelidir. Ana sınıflar dikkatlice tanımlanmalıdır. Her biri için kendi arayüzünü ve kullanılan yöntemleri ve otomat tabanlı yöntemlerin gösterimini sunmayı amaçlayan bir "sınıf blok diyagramının" hazırlanması tavsiye edilir.
- "Otomatlar" bölümünde her otomat için üç belge sağlanmalıdır: sözlü açıklama, otomat bağlantı şeması ve geçiş grafiği.
- Sözlü bir açıklama oldukça ayrıntılı olmalıdır, ancak karmaşık bir otomatın davranışının açık bir şekilde tanımlanmasının zor olduğu gerçeği göz önüne alındığında, genellikle bir "niyet bildirisi" sunar.
- Otomat bağlantı şeması, arayüzünün ayrıntılı bir açıklamasını sağlar. Diyagramın sol kısmı şunları içermelidir:
- veri kaynakları;
- her girdi değişkeninin tam adı;
- her olayın tam adı;
- verilen otomatta giriş eylemleri olarak kullanılan diğer otomatların durum numaralarıyla birlikte tahminler. Örneğin, sekizinci otomat altıncı duruma geçtiğinde bire eşit değeri alan Y8 == 6 tahmini kullanılabilir);
- ilgili endekslerle x olarak gösterilen girdi değişkenleri;
- ilgili endekslerle e olarak gösterilen olaylar;
- Otomatın durumlarını saklamak için değişkenler, YN olarak gösterilen N sayısı ile.
Diyagramın sağ kısmı şunları içermelidir:- ilgili endekslerle z olarak gösterilen çıktı değişkenleri;
- her çıktı değişkeninin tam adı;
- verilen otomat tarafından oluşturulan olaylar (varsa);
- oluşturulan her olayın tam adı;
- veri alıcıları.
- Düğümlerde veya geçişlerde karmaşık hesaplama algoritmaları kullanılıyorsa, "Hesaba Dayalı Algoritmalar" bölümü algoritma seçimini açıklar ve açıklamalarını sağlar (matematiksel açıklama dahil). Bu algoritmalar, hesaplamaların girişte mi yoksa çıkışta mı yapıldığına bağlı olarak x ve z değişkenleriyle belirlenir.
- Program uygulamasının özellikleri "Uygulama" bölümünde belirtilmelidir. Özellikle otomatların resmi ve izomorfik uygulaması için bir şablon sunmalıdır. Otomat uygulamaları burada da sağlanmalıdır.
- "Sonuç", tamamlanan projenin yararlarını ve olumsuz yanlarını kapsar. Ayrıca projeyi iyileştirmenin yollarını da sunabilir.
9. Sonuç
Hepinizi şunları yapmaya teşvik ediyorum:
- programlamaya yönelik bu yeni yaklaşımı keşfedin.
- fikirlerinizi ve alım satım stratejilerinizi programlamak için bu tamamen yeni ve son derece ilginç yaklaşımı uygulayın.
Otomat tabanlı programlamanın şunları yapacağını umuyorum:
- zamanla tüm yatırımcılar ve hatta MetaQuotes Dil geliştiricileri için programlama ve tasarımda standart haline gelmesi.
- bir EA tasarlarken karmaşık karar vermenin temeli olması.
- gelecekte otomat tabanlı programlama yaklaşımını ve yeni bir platformu - MetaTrader 6 - destekleyen yeni bir dile - MetaQuotes Language 6 - geliştirilmesi.
Tüm alım satım geliştiricileri bu programlama yaklaşımını takip ederse, kayıpsız bir EA oluşturma hedefine ulaşılabilir. Bu ilk makale, size yeni icatlar ve keşifler için bir motivasyon olması amacıyla otomat tabanlı tasarım ve programlama alanında yaratıcılık ve araştırma için yepyeni bir çıkış noktası gösterme girişimidir.
Ve bir şey daha - yazarın makalesine tamamen katılıyorum ve onu size kısa bir biçimde sunmanın önemli olduğunu hissediyorum (tam metin burada http://is.ifmo.ru/works/open_doc/):
Kaynak Kodları Neden Programları Anlamak İçin Bir Çözüm Değildir?
Pratik programlamadaki temel sorun, program kodlarını anlama sorunudur. Kaynak kodlarının elinizin altında olması her zaman faydalıdır, ancak sorun şu ki bu genellikle yeterli değildir. Ve çözülmesi zor bir programı anlamak için genellikle ek belgelere ihtiyaç vardır. Kod miktarı arttıkça bu ihtiyaç katlanarak artar.
Geliştiriciler tarafından verilen özgün tasarım kararlarını geri yüklemeyi ve programları anlamayı amaçlayan program kodu analizi, programları anlamak için kaynak kodlarının yetersizliği ile yakından ilişkili olan programlama teknolojisinin iki önemli dalıdır.
Büyük bir yazılım yeniden yapılandırma projesinde yer almış olan herkes, bir grup kötü belgelenmiş (her zaman kötü yazılmış olmasa da) kaynak kodunu ilk gördüğünüzde gelen çaresizlik ve şaşkınlık hissini daima hatırlayacaktır. Anahtar geliştiricilere erişim olmadığında kaynak kodlarının varlığı pek yardımcı olmaz. Program nispeten düşük seviyeli bir dilde yazılmışsa ve ayrıca kötü belgelenmişse, tüm ana tasarım kararları genellikle programlama ayrıntılarında dağılır ve yeniden yapılandırmayı gerektirir. Bu gibi durumlarda, arayüz belirtimi ve mimari tanımı gibi daha üst düzey belgelerin değeri, kaynak kodun kendi değerinden daha ağır basabilir.
Kaynak kodların programları anlamak için yetersiz olduğunun farkına varılması, kod ile daha üst düzey bir belgelemeyi birleştirme girişimlerini gündeme getirmiştir.
Projenin ilk aşamalarını kaçırırsanız, işin karmaşıklığı ve miktarı, herhangi bir üst düzey belge olmaması koşuluyla, kaynak kodlarını sizden sanal olarak 'kilitleyecektir'. Projenin başında çalışan geliştiriciler olmadığı zaman "tarih öncesi" kodu veya ilgili mimari kararları sıralamaya izin veren yeterli dokümantasyonu anlamak, muhtemelen programcıların karşılaştığı en zor güçlüklerden biridir».
Programlar Neden Tasarımdan Yoksundur?
Bu nedenle, kaynak kodlarının olmaması kötü olabilirken, kullanılabilirliği de aynı derecede faydalı olabilir. "Sonsuza dek mutlu" bir yaşam için hala eksik olan nedir? Cevap basit - bileşenlerinden biri olarak program belgelerini içeren ayrıntılı ve doğru bir tasarım belgeleri.
Köprüler, yollar ve gökdelenler normalde eldeki belgeler olmadan inşa edilemez, ki bu programlar için geçerli değildir.
Programlamada ortaya çıkan durum şu şekilde tanımlanabilir: "İnşaatçılar binaları programcıların programları yazdığı gibi inşa etseydi, ortaya çıkan ilk ağaçkakan uygarlığı yok ederdi."
Donanım için çok sayıda ayrıntılı ve anlaşılır tasarım belgesi yayınlanıyor ve yayınlandıktan yıllar sonra bile ortalama bir uzman tarafından nispeten kolayca anlaşılabiliyor ve değiştirilebiliyorken, neden bu tür belgeler ya yazılım için mevcut değil ya da bunları değiştirmek için tamamen resmi bir yol ve (geliştirici yoksa) çok yetenekli bir uzman gerekiyor?
Görünüşe göre bu durum şu şekilde açıklanabilir. Birincisi, donanım geliştirme ve üretimi, farklı kuruluşlar tarafından yürütülen iki farklı süreçtir. Bu nedenle, dokümantasyon kalitesi düşükse, geliştirme mühendisi hayatının geri kalanını 'tesiste' çalışarak geçirecektir ki bu açıkça onun istediği şey değildir. Yazılım geliştirme söz konusu olduğunda, bu durumda hem yazılım geliştiricisi hem de üretici genellikle bir ve aynı şirket olduğu için durum değişir ve bu nedenle, belge listesi ne olursa olsun, içerikleri kural olarak oldukça yüzeysel olacaktır.
İkincisi, donanım 'somut' iken yazılım 'soyuttur'. Programları değiştirmeyi kolaylaştırır, ancak tasarım belgelerini birlikte yayınlamamak için zemin oluşturmaz. Çoğu programcının patolojik olarak belgeleri okumaya ve daha da önemlisi yazmaya isteksiz olduğu bilinmektedir.
Deneyim, neredeyse hiçbir yeni kalifiye programcının, hatta en zeki olanların bile tasarım dokümantasyonu hazırlayamadığını gösterir. Ve birçoğunun matematikte uzun ve karmaşık dersler almasına ve geçmesine rağmen, mantıkları ve belge yazma titizliği üzerinde neredeyse hiçbir etkisi yoktur. Tüm dokümantasyon boyunca (boyutundan bağımsız olarak) tek bir şey için farklı gösterimler kullanabilirler, dolayısıyla onu örneğin ampul, ışık, lamba veya Lamba olarak adlandırabilir, istedikleri zaman küçük veya büyük harfle yazabilirler. Hayal güçlerine tam kapsam verdiklerinde ne olduğunu hayal edin!
Görünüşe göre, bunun nedeni, tasarım belgeleri herhangi bir istem olmadan yazılırken derleyici programlandığı sırada tutarsızlıkları işaretlemesidir.
Yazılım dokümantasyonunun kalitesi konusu, artan sosyal öneme sahip bir konu haline geliyor. Yazılım geliştirme, güçlü kar amacı ile giderek gösteri dünyasına benzer hale geliyor. Her şey, ürüne gelecekte ne olacağını düşünmeden, delice bir aceleyle yapılıyor. Gösteri dünyası gibi, programlama da her şeyi "iyi ve kötü" yerine "kâr ve zarar" açısından ölçer. Çoğu durumda, iyi bir teknoloji aslında iyi olan değil, karşılığını verendir.
Tasarım dokümantasyonu yazma isteksizliği, muhtemelen proje ne kadar kısıtlı (belgesiz) olursa, yazarın o kadar vazgeçilmez olduğu gerçeğiyle de ilişkilidir.
Bu tür çalışma davranışı ne yazık ki son derece kritik sistemler için yazılımların geliştirilmesine kadar yayılıyor. Bunun nedeni büyük ölçüde programların çoğu durumda yazılı olması ve tasarlanmamasıdır. "Tasarım yaparken, CRC kartlarından veya kullanım durumu diyagramlarından daha karmaşık herhangi bir tekniğin çok karmaşık olduğu kabul edilir ve bu nedenle kullanılmaz. Bir programcı, son teslim tarihine yetişemeyebileceğini patrona bildirerek herhangi bir teknolojiyi uygulamayı her zaman reddedebilir".
Bu, "kullanıcıların yazılımdaki hataları olağan dışı bir şey olarak görmedikleri" durumlara yol açar.
Şu anda, büyük binalar söz konusu olduğunda, yazılım değil, tasarım ve uygun dokümantasyonun geçerli olacağı yaygın olarak düşünülmektedir.
Sonuç olarak, geçmişte böyle bir durumun programlamada mevcut olmadığını belirtmek gerekir - erken büyük ölçekli bilgisayarlar kullanılırken, programlar ya çok dikkatli bir şekilde tasarlanır ya da geliştirilir, çünkü bir hata olması durumunda bir sonraki girişim normalde bir gün gibi erken bir sürede gerçekleştirilir. Böylece teknik ilerleme bizi daha az dikkatli bir programlamaya yöneltti.
Referanslar
Maalesef sorunlarımız ve endişelerimiz AA Shalyto’nun çalıştığı enstitü bölümünün web sitesinde görülememektedir. Kendi sorunları ve hedefleri var ve kavramlarımıza ve tanımlarımıza tamamen yabancılar ve habersizler, dolayısıyla konumuzla ilgili hiçbir örnek yok.
AA Shalyto’nun ana kitapları/ders kitapları :
- Automata-Based Programming. http://is.ifmo.ru/books/_book.pdf
- Using Flow Graphs and Transition Graphs in Implementation of Logic Control Algorithms. http://is.ifmo.ru/download/gsgp.pdf
- Automata-Based Programming. http://is.ifmo.ru/works/_2010_09_08_automata_progr.pdf
- Transformation of Iterative Algorithms into Automata-Based Algorithms. http://is.ifmo.ru/download/iter.pdf
- Switch-Technology: Automata-Based Approach to Developing Software for Reactive Systems. http://is.ifmo.ru/download/switch.pdf
- Automata-Based Program Design. Algorithmization and Programming of Logic Control Problems. http://is.ifmo.ru/download/app-aplu.pdf
- Using Genetic Algorithm to Design Autopilot for a Simplified Helicopter Model. http://is.ifmo.ru/works/2008/Vestnik/53/05-genetic-helicopter.pdf
- Explicit State-Based Programming. http://is.ifmo.ru/download/mirpk1.pdf
- Algorithmization and Programming for Logic Control and Reactive Systems. http://is.ifmo.ru/download/arew.pdf
- Object-Oriented Approach to Automata-Based Programming. http://is.ifmo.ru/works/ooaut.pdf
- Graphical Notation for Inheritance of Automata-Based Classes. http://is.ifmo.ru/works/_12_12_2007_shopyrin.pdf
- Programming in... 1 (One) Minute. http://is.ifmo.ru/progeny/1minute/?i0=progeny&i1=1minute
Projeler
- ATM'lerin Modellenmesi Çalışması. http://is.ifmo.ru/unimod-projects/bankomat/
- Nükleer Reaktör Kontrol Sürecinin Modellenmesi. http://is.ifmo.ru/projects/reactor/
- Asansör Kontrol Sistemi. http://is.ifmo.ru/projects/elevator/
- Kahve Makinesi Kontrol Sisteminin Otomat Tabanlı Geliştirilmesi. http://is.ifmo.ru/projects/coffee2/
- Sürüş için Otomatların Tasarımı ve Araştırması. http://is.ifmo.ru/projects/novohatko/
- Otomat Tabanlı Programlama Kullanarak Dijital Kamera Modelleme. http://project.ifmo.ru/shared/files/200906/5_80.pdf
- İnsansız Araçlar için Çok Etmenli Bir Sistemi Modellemek için Otomat Tabanlı Programlamanın Kullanılması. http://project.ifmo.ru/shared/files/200906/5_41.pdf
- Visual Rubik Küp Çözüm Sistemi. http://is.ifmo.ru/projects/rubik/
ve diğer ilginç makaleler ve projeler: http://project.ifmo.ru/projects/, http://is.ifmo.ru/projects_en/ ve http://is.ifmo.ru/articles_en/.
NOT
Bir Rubik Küpünün olası farklı olaylarının sayısı (8! × 38−1) × (12! × 212−1)/2 = 43 252 003 274 489 856 000’dır. Ancak bu sayı, merkez karelerin farklı yönlere sahip olabileceğini hesaba katmaz.
Böylece merkez yüzlerin yönelimleri dikkate alındığında olay sayısı 2048 kat daha fazla yani 88 580 102 706 155 225 088 000 olur.
Forex piyasası ve borsada çok fazla ardışık olay varyantı yoktur, ancak bunlarla ilgili problemler bu programlama paradigması kullanılarak 100-200 adımda kolayca çözülebilir. Bu doğru! Market ve EA'lar sürekli rekabet halindedir. satranç oynamak gibidir, (tıpkı bizim gibi) rakibin yaklaşan hamlelerini kimse bilmez. Ancak, alfa-beta ayıklama algoritmalarına dayalı olarak tasarlanmış Rybka (çok güçlü satranç motoru) gibi etkileyici bilgisayar programları vardır.
Başkalarının programlamanın diğer alanlarındaki bu başarıları size enerji versin ve kendimizi işimize adayalım! Yine de, kesinlikle hepimiz hiçbir şey bilmediğimizi biliyoruz.
MetaQuotes Ltd tarafından Rusçadan çevrilmiştir.
Orijinal makale: https://www.mql5.com/ru/articles/446
OpenCL: Sade Programlamadan Daha Öngörülü Programlamaya Doğru
En Aktif MQL5.community Üyelerine iPhone Ödülü Verildi!
MQL5 Kodu için Otomatik Oluşturulan Belgeler
OpenCL: Paralel dünyalara köprü
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz