Özünde binlerce, eğer ... sonra ... başka ifadelerden oluşan bir uygulama inşa etmeyi düşünüyorum. Uygulamanın amacı, ineklerin herhangi bir ortamda nasıl hareket ettiklerini tahmin edebilmektir. Güneş, rüzgar, besin kaynağı, ani olaylar vb. Durumlardan etkilenirler.

Böyle bir uygulama nasıl yönetilebilir? Birkaç IF ifadesinden sonra, programın nasıl tepki vereceği ve belirli bir tepkiye neden olanın hata ayıklamasının, bir kişinin her zaman tüm İF tablo ağacını geçmesi gerektiği anlamına geleceği tahmin edilemez kadar iyi olacağını hayal ediyorum.

Kural motorları hakkında biraz okudum, ancak bu karmaşıklığı nasıl çözeceklerini anlamıyorum.

Mantık programlama dili Prolog, aradığınız şey olabilir. Sorun beyanınız benim için uygun olup olmadığını değerlendirmek için yeterli değil, söylediklerinize oldukça benzer.

Prolog programı uygulanan gerçeklerden ve kurallardan oluşur. İşte "İnek açsa bir ineğin bir yere hareket ettiğini ve yeni bölgede eskiden daha fazla yiyecek bulunduğunu" belirten basit bir örnek kural:

moves_to(Cow, Location) :-
  hungry(Cow),
  current_location(Cow, OldLoc),
  food_in(OldLoc, OldFood), food_in(Location, NewFood),
  NewFood > OldFood.

Büyük harflerle yazılmış her şey değişkendir, değerini bilmediğiniz şeylerdir. Prolog, tüm koşulları sağlayan bu değişkenler için değer bulmaya çalışır. Bu işlem, Prolog ve benzeri mantık programlama ortamlarının kalbi olan birleştirme adı verilen güçlü bir algoritma ile gerçekleştirilir.

Kurallara ek olarak, bir veri tabanı sağlanmıştır. Yukarıdaki kurallarla çalışan basit bir örnek şöyle olabilir:

current_location(white_cow, pasture).

current_location(black_cow, barn).
hungry(black_cow).

current_location(angry_bull, forest).
hungry(angry_bull).

food_in(barn, 3).
food_in(pasture, 5).
food_in(forest, 1).

White_cow ve mera vs.'nin büyük harflerle yazılmadığına dikkat edin. Değişken değil, atom.

Sonunda bir sorgu yap ve ne olacağını sor.

?- moves_to(white_cow, Destination).
No.
?- moves_to(black_cow, Destination).
Destination = pasture
?- moves_to(Cow, Destination).
Cow = black_cow, Destination = pasture
Cow = angry_bull, Destination = barn
Cow = angry_bull, Destination = pasture

İlk sorgu, beyaz ineğin nerede hareket edeceğini soruyor. Yukarıdaki kurallar ve gerçekler göz önüne alındığında, cevabınız Hayır. Bu istediğinizi bağlı olarak "Bilmiyorum" veya "Hareket etmiyor" olarak yorumlanabilir.

İkinci sorgu, siyah ineğin nerede hareket ettiğini soruyor. Yemek için mera hareket eder.

Son sorgu, tüm ineklerin nereye hareket ettiğini soruyor. Sonuç olarak, mantıklı olan tüm olası (İnek, Hedef) olsun. Bu durumda kara boğa beklendiği gibi meralara hareket eder. Bununla birlikte, kızgın boğanın kuralları yerine getiren iki seçeneği vardır, ya meraya ya da ahıra gidebilir.

Not: Prolog'u son yazdığımdan bu yana yıllar geçti, tüm örnekler sözdizimsel olarak geçerli olmayabilir, ancak fikir doğru olmalı.

İf web problemini ele alarak , her bir kuralın bağımsız olarak kodlandığı bir kural motoru oluşturabilirsiniz. Bunun için bir başka ayrıntı da, kuralları oluşturmak için alana özgü bir dil (DSL) oluşturmak olacaktır, ancak yalnızca DSL yalnızca sorunu bir kod tabanından (ana) diğerine (DSL) alır. Yapı olmadan DSL, anadilden (Java, C # vb.) Daha iyi sonuç almayacaktır, bu yüzden gelişmiş bir yapısal yaklaşım bulduktan sonra geri döneceğiz.

Temel sorun, bir modelleme probleminiz olması. Bu gibi birleşimsel durumlarla karşılaştığınızda, durumu tanımlayan model soyutlamanızın çok kaba olduğunun açık bir işaretidir. Büyük olasılıkla farklı modellere ait olması gereken unsurları tek bir varlıkta birleştiriyor olabilirsiniz.

Modelinizi parçalamaya devam ederseniz, sonuçta bu kombinasyon etkisini tamamen çözeceksiniz. Ancak bu yolu seçerken tasarımınızda daha da büyük bir karmaşa yaratarak kaybolmak kolaydır, burada mükemmeliyetçilik mutlaka arkadaşınız değildir.

Sonlu durum makineleri ve kural motorları, bu problemin nasıl çözülebileceğine ve yönetilebilir hale getirildiğinin sadece bir örneğidir. Buradaki ana fikir, bunun gibi bir birleşim probleminden kurtulmanın iyi bir yolunun, genellikle bir tasarım oluşturmak ve sisteminizi tatmin edici bir şekilde yerine getirene kadar iç içe geçmiş soyutlama seviyelerinde tekrarlamaktır . Fraktalların karmaşık desenler oluşturmak için nasıl kullanıldığına benzer. Sisteminize mikroskopla veya yüksek kuş bakışı bir bakışla bakarsanız, kurallar aynı kalır.

Bunu etki alanınıza uygulama örneği.

İneklerin bir arazide nasıl hareket ettiğini modellemeye çalışıyorsunuz. Sorunuzda ayrıntı bulunmasa da, büyük miktarda ifs'in if cow.isStanding then cow.canRun = trueörneğin arazi detaylarını ekledikçe tıkanıp kalmış gibi karar parçasını içerdiğini tahmin ediyorum . Bu nedenle, almak istediğiniz her eylem için, düşünebileceğiniz her yönü kontrol etmeniz ve bir sonraki olası eylem için bu doğrulamaları tekrar etmeniz gerekir.

İlk önce, bu durumda simülasyonun değişen durumlarını modellemek için bir FSM olacak olan tekrarlanabilir tasarımımıza ihtiyacımız var. Bu yüzden yapacağım ilk şey referans FSM uygulamak, durum arayüzü, geçiş arayüzü ve belki de geçiş bağlamını tanımlamak.diğer ikisine sunulacak paylaşılan bilgiler içerebilir. Temel bir FSM uygulaması, içeriğe bakılmaksızın bir geçişten diğerine geçecektir, bu bir kural motorunun girdiği yerdir. Kural motoru, geçiş gerçekleşmesi durumunda yerine getirilmesi gereken şartları temiz bir şekilde kapsar. Buradaki bir kural motoru, her biri bir boole döndüren bir değerlendirme işlevine sahip olan bir kural listesi kadar basit olabilir. Bir geçişin gerçekleşmesi gerekip gerekmediğini kontrol etmek için, kuralların listesini yineleyin ve herhangi biri yanlış olarak değerlendirilirse, geçiş gerçekleşmez. Geçişin kendisi , FSM'nin (ve diğer olası görevlerin) mevcut durumunu değiştirmek için davranış kodunu içerecektir .

Şimdi, simülasyonu GOD seviyesinde tek bir büyük FSM olarak uygulamaya başlarsam, bir sürü muhtemel durum, geçiş vb. İle sonuçlanır. If-else karmaşası sabit gibi görünür, ancak aslında sadece yayılır: her bir IF Şimdi bağlamın belirli bir bilgisine karşı test yapan bir kural (bu noktada hemen hemen her şeyi içerir) ve her IF kuruluşu geçiş kodunda bir yerdedir.

Fraktallar dağılımına girin: ilk adım, devletlerin ineğin kendi iç durumları olduğu (ayakta durma, koşma, yürüme, otlatma vb.) Ve aralarındaki geçişlerin çevreden etkileneceği her inek için bir FSM oluşturmak olacaktır. Grafiğin tamamlanmamış olması mümkündür, örneğin otlatma sadece durgun durumdan erişilebilir, başka herhangi bir geçiş engellenmiştir, çünkü basitçe modelden yoktur. Burada, verileri inek ve arazi olmak üzere iki farklı modelde etkili bir şekilde ayırıyorsunuz. Her biri kendi özelliklerine sahip. Bu arıza, genel motor tasarımınızı basitleştirmenizi sağlayacaktır. Şimdi, hepsine karar veren tek bir kural motoruna sahip olmak yerine, çok özel detaylara karar veren birden fazla, daha basit kural motorlarına (her geçiş için bir tane) sahip olduğunuza karar verin.

Çünkü FSM için aynı kodu kullanıyorum, bu temel olarak FSM'nin bir yapılandırması. DSL'den daha önce bahsettiğimizi hatırlıyor musun? Yazmak için çok fazla kural ve geçişiniz varsa DSL çok iyi şeyler yapabilir.

Daha derine gitmek

Artık ALLAH, ineğin iç durumlarını yönetme konusundaki tüm karmaşıklıkla uğraşmak zorunda değil, ancak daha da ileri götürebiliriz. Örneğin, araziyi yönetmede hala çok fazla karmaşıklık var. Yıkımın nerede olduğuna karar verdiğin yer Örneğin, TANRI'nızda, arazi dinamiklerini (uzun ot, çamur, kuru çamur, kısa ot vb.) Yönetiyorsanız, aynı modeli tekrarlayabiliriz. Tüm arazi durumlarını (uzun ot, kısa ot, çamurlu, kuru, vb.) Devletler arasındaki geçişler ve basit kurallar ile yeni bir arazi FSM'sine çıkararak bu tür bir mantığı araziye yerleştirmenizi engelleyen hiçbir şey yoktur. Örneğin çamurlu duruma gelmek için kural motoru sıvıları bulmak için bağlamı kontrol etmelidir, aksi takdirde mümkün değildir. Şimdi ALLAH daha da kolaylaştı.

FSM sistemini özerk hale getirerek tamamlayabilir ve her birine bir iş parçacığı verebilirsiniz. Bu son adım gerekli değildir ancak karar verme kararınızı nasıl delege edeceğinizi ayarlayarak (özel bir FSM başlatmak veya önceden belirlenmiş bir durumu geri getirmek için) sistemin etkileşimini dinamik olarak değiştirmenize olanak sağlar.

Geçişlerin "diğer olası işler" de yapabileceğinden nasıl bahsettiğimizi hatırlıyor musunuz? Farklı modellerin (FSM) birbirleriyle iletişim kurma olasılığını ekleyerek bunu keşfedelim. Bir olay kümesi tanımlayabilir ve her FSM'nin bu olaylara dinleyici kaydetmesine izin verebilirsiniz. Bu nedenle, örneğin bir ineğin altıgen arazisine girmesi durumunda, altıgen geçiş değişiklikleri için dinleyicileri kaydedebilir. Burada biraz zorlaşıyor çünkü her FSM, barındırdığı belirli alan hakkında herhangi bir bilgi olmadan çok yüksek bir seviyede uygulanıyor. Bununla birlikte, ineğe bir olaylar listesi yayınlamasını sağlayarak başarabilir ve tepki gösterebileceği olayları görürse hücre kayıt olabilir. Burada olay ailesi iyi bir hiyerarşi iyi bir yatırımdır.

Çimenin besin düzeylerini ve büyüme döngüsünü modelleyerek daha da derinlere itebilirsiniz, tahmin ettiğiniz ... arazi yamasının kendi modeline gömülü bir çim FSM'si.

Fikri yeterince zorlarsanız, ALLAH'ın yapması gereken çok şey yoktur, çünkü tüm yönler kendi kendine yönetilir ve daha tanrısal şeyler için vakit ayırır.

tekrarlamak

Yukarıda FSM'de belirtildiği gibi, çözüm değildir, sadece böyle bir sorunun çözümünün söylenen kodda bulunmadığını, ancak sorununuzu nasıl modellediğinizi göstermenin bir yolu. FSM önerimden daha muhtemel ve en büyük olasılıkla daha iyi olan başka çözümler de var. Bununla birlikte, "fraktallar" yaklaşımı bu zorluğun üstesinden gelmek için iyi bir yol olmaya devam etmektedir. Doğru şekilde yapılırsa, daha az önemli olduğu yerlerde daha basit modeller verirken, önemli olduğu yerlerde daha derindeki seviyeleri dinamik olarak tahsis edebilirsiniz. Değişiklikleri sıraya koyabilir ve kaynaklar daha uygun hale geldiğinde uygulayabilirsiniz. Bir eylem dizisinde inekden ot yamaya kadar besin transferini hesaplamak o kadar da önemli olmayabilir. Bununla birlikte, bu geçişleri kaydedebilir ve değişiklikleri daha sonra uygulayabilirsiniz veya sadece kural motorlarını değiştirerek veya doğrudan FSM uygulamasını doğrudan alanda olmayan elemanlar için daha basit bir saf sürümle değiştirerek, eğitimli bir tahminle yaklaşık olarak uygulayabilirsiniz. ilginin (alanın diğer ucundaki inek) odaklanmasını ve kaynakların daha büyük bir bölümünü elde etmesini sağlamak için daha ayrıntılı etkileşimlere izin vermesidir. Bütün bunlar sistemi bir bütün olarak tekrar ziyaret etmeden; Her parça iyi bir şekilde izole edildiğinden, modelinizin derinliğini sınırlayan veya genişleten bir drop-in değiştirme oluşturmak daha kolay hale gelir. Standart bir tasarım kullanarak, bunun üzerine kurabilir ve DSL gibi geçici araçlara yapılan yatırımları en üst düzeye çıkarmak ve gerektiğinde iyileştirmeleri eklemek için kurallar veya etkinlikler için standart bir kelime haznesi oluşturabilirsiniz. Her parça iyi bir şekilde izole edildiğinden, modelinizin derinliğini sınırlayan veya genişleten bir drop-in değiştirme oluşturmak daha kolay hale gelir. Standart bir tasarım kullanarak, bunun üzerine kurabilir ve DSL gibi geçici araçlara yapılan yatırımları en üst düzeye çıkarmak ve gerektiğinde iyileştirmeleri eklemek için kurallar veya etkinlikler için standart bir kelime haznesi oluşturabilirsiniz. Her parça iyi bir şekilde izole edildiğinden, modelinizin derinliğini sınırlayan veya genişleten bir drop-in değiştirme oluşturmak daha kolay hale gelir. Standart bir tasarım kullanarak, bunun üzerine kurabilir ve DSL gibi geçici araçlara yapılan yatırımları en üst düzeye çıkarmak ve gerektiğinde iyileştirmeleri eklemek için kurallar veya etkinlikler için standart bir kelime haznesi oluşturabilirsiniz.

Bir kod örneği verirdim ama şu anda yapabileceğim tek şey bu.

Bahsettiğiniz tüm bu şartlı ifadelere benziyor, programınızın bir parçası yerine programınızı yapılandıran veriler olmalıdır. Onlara bu şekilde davranırsanız, kodunuzu değiştirmek yerine, modelinizi geliştirmek istediğiniz her seferde yeniden derlemek yerine, programınızın çalışma biçimini değiştirerek özgürleştirebilirsiniz.

Sorununuzun doğasına bağlı olarak, gerçek dünyayı modellemenin birçok farklı yolu vardır. Çeşitli koşullarınız simülasyona uygulanan kurallar veya kısıtlamalar olabilir. Gibi görünen kodu olması yerine:

if (sunLevel > 0.75) {
   foreach(cow in cows) {
       cow.desireForShade += 0.5;
   }
}
if (precipitation > 0.2) {
   foreach(cow in cows) {
       cow.desireForShelter += 0.8;
   }
}

Bunun yerine benzeyen bir kod olabilir:

foreach(rule in rules) {
   foreach (cow in cows) {
      cow.apply(rule);
   }
}

Veya, bir dizi girdi verilen inek davranışını modelleyen doğrusal bir program geliştirebilirseniz, her kısıt, bir denklem sisteminde bir çizgi haline gelebilir. Daha sonra bunu yineleyebileceğiniz bir Markov modeline dönüştürebilirsiniz.

Durumunuz için doğru yaklaşımın ne olduğunu söylemek zordur, ancak kısıtlamalarınızın programınıza giriş yapmak ve kodlamak için giriş yapmadığını düşünüyorsanız, bunun çok daha kolay bir zamanına sahip olacağını düşünüyorum.

Kimse bundan bahsetmedi, ben de açıkça söyleyeceğimi düşündüm:

Binlerce "Eğer .. O zaman .. Başka" kuralları kötü tasarlanmış bir uygulamanın işaretidir.

Alana özgü veri gösterimi bu kurallara benzese de, uygulamanızın alana özgü gösterime benzemesi gerektiğinden kesinlikle emin misiniz?

Lütfen göreve uygun yazılım / bilgisayar dillerini kullanın. Matlab , gerçekten de binlerce koşula sahip olabileceğiniz karmaşık sistemleri modellemek için çok sık kullanılır. İf / then / else cümleciklerini kullanmamak, sayısal analizlerle kullanmak. R , aynısını yapacak araçlar ve paketlerle dolu açık kaynaklı bir bilgisayar dilidir. Ancak bu aynı zamanda modelinizi daha matematiksel terimlerle yeniden yapılandırmanız gerektiği anlamına gelir, böylece hem ana etkileri hem de modeller arasındaki etkiler arasındaki etkileşimleri ekleyebilirsiniz.

Henüz yapmadıysanız, lütfen modelleme ve simülasyon hakkında bir kurs izleyin. Yapmanız gereken en son şey, eğer öyleyse şöyle bir model yazmayı düşünmektir. Carlo markov zincirlerini monte ettik, vektör makinelerini destekledik, sinir ağlarını, gizli değişken analizini, ... Elinizde bulunan modelleme araçlarındaki zenginliği görmezden alarak kendinizi 100 yıl geriye atmayın.

Kural motorları yardımcı olabilir, çünkü çok sayıda / eğer kural varsa, kullanıcıların bir programlama dilini bilmeye gerek kalmadan onları düzenleyebilecekleri programın dışında bir yerde bulmaları yararlı olabilir. Ayrıca, görselleştirme araçları mevcut olabilir.

Ayrıca mantık programlama çözümlerine de bakabilirsiniz (Prolog gibi). İf / then ifadelerinin listesini hızlı bir şekilde değiştirebilir ve girdilerin herhangi bir kombinasyonunun belirli sonuçlara neden olup olmayacağına bakmak gibi şeyler yapmasını sağlayabilirsiniz. Ayrıca, işlem kodu (veya nesneye yönelik kod).

Aniden üzerime doğdu:

Bir Karar Öğrenme Ağacı (ID3 Algoritması) kullanmanız gerekir .

Birisinin sizin dilinizde uygulamış olması muhtemeldir. Değilse mevcut bir kütüphaneyi taşıyamazsanız

Bu, bir topluluk wiki cevabından daha fazlasıdır, diğer cevapların önerdiği çeşitli modelleme araçlarını bir araya getirir, sadece kaynaklara ek bağlantılar ekledim.

Binlerce sabit kodlanmış if / else ifadelerine farklı bir yaklaşım kullanmanız gerektiğini söylemenize gerek olmadığını sanmıyorum.

• DSL Programlama (Etki Alanına Özel Dil)
• Markov Model / Markov Karar süreci
• Rete ağı / Rete algoritması
• Uzman sistem
• Matlab , (Wikipedia)
• R,

Her büyük uygulama, if-then-elsediğer akış kontrollerini saymayan binlerce ifade içerir ve karmaşıklıklarına rağmen bu uygulamalar hala hata ayıklanır ve korunur.

Ayrıca, ifadelerin sayısı akışı tahmin edilemez yapmaz . Asenkron programlama yapar. Deterministik algoritmaları eşzamanlı olarak kullanırsanız, her seferinde% 100 öngörülebilir bir davranışınız olur.

Yığın Taşması ya da Kod İnceleme konusunda ne yapmaya çalıştığınızı daha iyi açıklamanız gerekir , böylece insanlar size tam bir yeniden yapılandırma tekniğini kullanmanız için önerebilir . Ayrıca, " <bir kod parçası verilen> çok fazla ifadeyi yerleştirmekten nasıl kaçınırım?" Gibi daha kesin sorular sormak isteyebilirsiniz . if

Uygulamanızı iyi tasarlayarak yönetilebilir hale getirin. Uygulamanızı, çeşitli iş mantığını ayrı sınıflara / modüllere ayırarak tasarlayın. Bu sınıfların / modüllerin her birini ayrı ayrı test eden ünite testleri yazın. Bu çok önemlidir ve iş mantığının beklendiği gibi uygulanmasını sağlamanıza yardımcı olacaktır.

Büyük olasılıkla sorununuzu çözmenin tek bir yolu olmayacaktır, ancak kendinizi if ifadelerinin büyük bloklarını yazdığınız ve çözümlerini uyguladığınız farklı alanları ayırmaya çalışırsanız, bunun parça karmaşıklığını parça parça yönetebilirsiniz. bu küçük sorunların her birine.

Büyük şartlandırmaları yönetilebilir parçalara bölmenin yolları için Refactoring'de bahsi geçen kurallar gibi tekniklere bakın - örneğin ortak bir arayüze sahip olan birden fazla sınıf, bir vaka ifadesinin yerine geçebilir.

Erken çıkmak da büyük bir yardımdır. Hata durumlarınız varsa, bir istisna atarak veya iç içe geçmelerine izin vererek geri getirerek bunları fonksiyonun başlangıcında durdurun.

Koşullarınızı belirleyici işlevlere bölerseniz, izlerini sürmek daha kolay olabilir. Ayrıca, onları standart bir forma sokabilirseniz, bunları kodlanmış bir kod yerine dinamik olarak oluşturulmuş bir veri yapısına sokmak mümkün olabilir.

Bir kural motoru kullanmanı öneririm. Java durumunda, jBPM veya Oracle BPM faydalı olabilir. Kural motorları temelde uygulamayı XML aracılığıyla yapılandırmanıza izin verir.

Sorun, "if" sonra "prosedür kodu" veya işletme uygulamaları için tasarlanan sayısız kural çözümü ile tanımlanmış olsun, "kurallar" ile iyi çözülmez. Makine öğrenimi bu tür senaryoları modellemek için çeşitli mekanizmalar sağlar.

Temel olarak, “sistemi” (örneğin bir meradaki inekler) etkileyen faktörlerin (örneğin güneş, rüzgar, besin kaynağı, ani olaylar vb.) Belirli bir şekilde gösterilmesi için bazı şemalar formüle edilmelidir. Ayrık bir ifadeye karşın, gerçek bir değerli işlevsel temsil yaratamayacağına dair yanlış yönlendirilmiş inanca rağmen, gerçek dünyadaki hiçbir bilgisayar (insan sinir sistemi dahil) gerçek değere dayalı veya gerçek değerlere dayanan hesaplamalar değildir.

İlgili faktörler için sayısal gösterime sahip olduğunuzda, birkaç matematik modelden herhangi birini oluşturabilirsiniz. Bir düğüm grubunun inekleri ve diğer bazı mera alanını temsil ettiği iki taraflı bir grafik öneririm. Her halükarda bir inek mera alanını işgal eder. Her inek için, mevcut ve diğer tüm mera birimleriyle ilişkili bir fayda değeri vardır. Model, ineğin optimize etmek istediğini varsayar (ineğe ne şekilde gelirse), mera ünitesinin fayda değerini, o zaman inekler optimize etmek için birimlerden birime geçer.

Hücresel bir otomat, modeli uygulamak için iyi çalışıyor. Gerçek değerli matematik dünyasında altta yatan matematik inek hareketini motive eden bir alan gradyan modelidir. İnekler algılanan daha düşük fayda değer konumlarından algılanan daha yüksek fayda değer konumlarına hareket eder.

Biri sisteme çevresel bir değişiklik enjekte ederse, o zaman sabit bir inek konumlandırma çözümüne geçmeyecektir. Ayrıca oyun teorisinin hangi yönleriyle uygulanabileceği bir model haline gelecektir; Bunun böyle bir olaya ille de ekleyeceği bir şey değil.

Buradaki avantaj, katliam inekleri veya yeni inekler edinmek, model çalışırken, "çift" hücrelerin çıkarılması ve iki taraflı grafiğe eklenmesiyle kolayca yönetilebilir.

Çok fazla if-if ifadesi tanımlamanız gerektiğini sanmıyorum. Benim bakış açıma göre, probleminizin birden fazla bileşeni var:

• Farklı kişilikleri, farklı konfigürasyonları olan birden fazla ineğiniz olduğundan, zaman uyumsuz veya okuyuculu olmalıdır. Her inek, bir sonraki hamlesinden önce hangi yöne gideceğini kendine sorar. Bence bir senkronizasyon kodu bu problem için zayıf bir araçtır.

• Karar ağacının yapılandırması sürekli değişiyor. Bu yerine else if ağacı, bir biz sorunu azaltmak gerektiğini düşünüyorum bir kompleks inşa ... vb fiili ineğin pozisyonunda, hava durumu, saat, arazi bağlıdır rüzgâr gül veya yön - ağırlık fonksiyonu : şekil 1 - kuralların bazıları için yön - ağırlık işlevleri

  İnek daima en fazla toplam ağırlığı olan yöne gitmelidir. Bu nedenle, büyük bir karar ağacı oluşturmak yerine, her ineğe bir dizi kural (farklı yön - ağırlık işlevleri ile) ekleyebilir ve sonucu her yön sorduğunuzda işleyebilirsiniz. Bu kuralları her pozisyon değişikliğinde veya zaman geçirerek yeniden yapılandırabilir veya bu ayrıntıları her kuralın alması gereken parametreler olarak ekleyebilirsiniz. Bu bir uygulama kararıdır. Yön bulmanın en kolay yolu, 0 ° 'den 360 °' ye basit bir döngü ekleyerek 1 ° 'lik adım. Bundan sonra, her 360 yönün toplam ağırlığını sayabilir ve doğru yönü elde etmek için bir max () işlevinden geçirebilirsiniz.

• Bunu yapmak için bir sinir ağına ihtiyacınız yoktur, her kural için sadece bir sınıf, inekler için bir sınıf, belki arazi için vb. Ve senaryo için bir sınıf (örneğin, farklı kurallara sahip 3 inek) 1 belirli arazi). Şekil 2 - İnek uygulaması eşzamansız karar düğümleri ve bağlantıları

  • mesajlaşma yönü için kırmızı - kurallara göre ağırlık haritası
  • karar verdikten sonra oryantasyon ve pozisyon güncellemeleri için mavi
  • oryantasyon ve pozisyon güncellemesinden sonra giriş güncellemeleri için yeşil
  • girişleri almak için siyah

  Not: Muhtemelen böyle bir şey uygulamak için bir mesajlaşma çerçevesine ihtiyacınız olacak

  Öyleyse öğrenme inekleri yapmak probleminizin bir parçası değilse, sinir ağına veya genetik algoritmalara ihtiyacınız yoktur. Ben bir AI uzmanı değilim, ama ineklerinizi gerçek olanlara uyarlamak istiyorsanız, o zaman bunu basit bir genetik algoritma ve uygun kurallar dizisiyle yapabilirsiniz. İyi anlarsam, rasgele kural ayarlarına sahip bir inek popülasyonuna ihtiyacınız var. Bundan sonra, gerçek ineklerin davranışını model popülasyonunuzun davranışlarıyla karşılaştırabilir ve% 10'unu gerçek olanlara en yakın olan yolda tutabilirsiniz. Bundan sonra, inek fabrikaya tuttuğun% 10 oranına bağlı olarak yeni kural yapılandırma kısıtlamaları ekleyebilir ve popülasyona yeni rastgele inekler ekleyebilirsin.

Ben gerçekten binlerce IF varsa ... O zamandan beri kurallar olabilir olabileceğini olabilir. Buna değer olarak, katıldığım sinir ağı modelleme görüşmelerinde genellikle "basit bir kurallar dizisi" ile oldukça karmaşık ve makul derecede gerçeğe uygun davranış sergileme davranışını (bu durumlarda, gerçek nöronlar) nasıl oluşturabileceklerini belirtmekle başlar. Yani emin misinbinlerce şartlara mı ihtiyacınız var? Demek istediğim, hava koşullarının 4-5 yönü, besin kaynaklarının konumu, ani olaylar, sürü ve arazi özellikleri dışında, gerçekten daha fazla değişkeniniz olacak mı? Elbette, bu koşulları birleştirmek için mümkün olan tüm izinleri yapmaya çalıştıysanız, binlerce kurala kolayca sahip olabilirsiniz, ancak bu doğru bir yaklaşım değildir. Belki de çeşitli faktörlerin her ineğin bulunduğu yere genel bir karara bağlanan bir önyargı getirdiği bulanık bir mantık tarzı yaklaşımı bunu daha az kuralla yapmanıza izin verir.

Ayrıca herkesin kural setinin genel kod akışından ayrı olması gerektiğine katılıyorum, böylece programı değiştirmeden kolayca düzenleyebilirsiniz. Rakip kural kümeleri bile bulabilir ve gerçek inek hareketi verilerine karşı nasıl yaptıklarını görebilirsiniz. Kulağa eğlenceli geliyor.

AI alanı olan Uzman Sistemlerden bahsedilmiştir. Bunları biraz genişletmek için, Çıkarım Motorları hakkında okumak size bu konuda yardımcı olabilir. Bir Google araması daha yararlı olabilir - DSL'in yazılması kolay olanıdır, bunu önemsiz bir şekilde Altın Ayrıştırıcı gibi bir çözümleyici ile yapabilirsiniz. Zor kısım karar ağacınızı oluşturmaktan ve verimli bir şekilde almaktan kaynaklanıyor.

Pek çok tıbbi sistem zaten bu motorları kullanıyor, örneğin İngiltere'nin NHS Direct web sitesi .

Eğer bir .NET’erseniz, Infer.NET sizin için yararlı olabilir.

İneğin hareketine baktığınızdan beri, 360 dereceye kadar sıkışmışlar (inekler uçamaz.) Ayrıca seyahat etme hızınız var. Bu bir vektör olarak tanımlanabilir.

Şimdi güneşin konumu, tepenin eğimi, yüksek ses gibi durumlarla nasıl başa çıkıyorsunuz?

Derecelerin her biri, o yöne gitme arzusunu gösteren bir değişken olacaktır. İnek sağının 90 derece döndüğünü söyleyin (ineğin 0 derece olduğu varsayılarak). Sağa gitme arzusu aşağı inecek ve gitme arzusu 270 (solda) artacaktır. İnekler üzerindeki etkilerini ekleyen veya çıkartan tüm uyaranlara bakın, bir yöne gitmek isterler. Tüm uyaranlar uygulandıktan sonra, inek en yüksek arzu yönünde gider.

Ayrıca gradyanlar da uygulayabilirsiniz, böylece uyaranların ikili olması gerekmez. Örneğin bir tepe tek yönde dik değildir. Belki inek bir vadidedir ya da tepedeki bir yolda dümdüz ileride, 45 * hafif tepede, 90 * hafif tepede. 180 * 'de dik yokuşta.

Daha sonra bir etkinliğin ağırlığını ayarlayabilir ve etki yönünü değiştirebilirsiniz. Aksine o zaman bir liste varsa, maks. Ayrıca bir uyaran eklemek istediğinizde testten önce uygulayabilirsiniz ve daha fazla karmaşıklık eklemek zorunda kalmazsınız.

Aksine daha sonra ineğin herhangi bir 360 yöne gideceğini söylemek, onu sadece 36 yöne bölmesini sağlar. Her biri 10 derece olmak

Aksine daha sonra ineğin herhangi bir 360 yöne gideceğini söylemek, onu sadece 36 yöne bölmesini sağlar. Her biri 10 derecedir. Ne kadar spesifik olmanız gerektiğine bağlı olarak.

OOP kullanın. Temel koşulları ele alan ve yaptığınız şeyi simüle etmek için rastgele yöntemler kullanan bir grup sınıf oluşturmaya ne dersiniz.

Yardım etmek için bir programcı alın.

class COW_METHODS {

    Function = array('Action1','Action2',....'ActionX');

    function doAction() {
       execute(Function[random(1,5000]);
    }

    function execute(DynamicFunction) {
        exec(DynamicFunction());
    }

    Function Action1() {
        turnRight();
        eatGrass();
    }
    /*  keep adding functions for COW Methods ...  etc  */
    /*  and add classes for conditions inherit them as needed  */
    /*  keep an object to define conditions =  Singleton etc.  */
}