Saya sedang mempertimbangkan membangun aplikasi, yang, pada intinya, akan terdiri dari ribuan jika ... maka ... pernyataan lain. Tujuan dari aplikasi ini adalah untuk dapat memprediksi bagaimana sapi bergerak di setiap lanskap. Mereka dipengaruhi oleh hal-hal seperti matahari, angin, sumber makanan, peristiwa tiba-tiba dll.

Bagaimana aplikasi semacam itu dapat dikelola? Saya membayangkan bahwa setelah beberapa ratus pernyataan IF, akan sama baiknya dengan tak terduga bagaimana program akan bereaksi dan men-debug apa yang menyebabkan reaksi tertentu akan berarti bahwa seseorang harus melintasi seluruh pohon pernyataan IF setiap kali.

Saya telah membaca sedikit tentang mesin aturan, tetapi saya tidak melihat bagaimana mereka bisa mengatasi kompleksitas ini.

Bahasa pemrograman logika Prolog mungkin apa yang Anda cari. Pernyataan masalah Anda tidak cukup spesifik bagi saya untuk menilai apakah itu cocok tetapi agak mirip dengan apa yang Anda katakan.

Program Prolog terdiri dari fakta dan aturan yang diterapkan. Berikut ini contoh aturan sederhana yang menyatakan "Sapi pindah ke lokasi jika sapi lapar dan ada lebih banyak makanan di lokasi baru daripada di lokasi lama":

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

Semua hal dalam huruf kapital adalah variabel, hal-hal yang Anda tidak tahu nilainya. Prolog berupaya menemukan nilai untuk variabel-variabel ini yang memenuhi semua persyaratan. Proses ini dilakukan dengan algoritma yang kuat yang disebut penyatuan yang merupakan jantung dari Prolog dan lingkungan pemrograman logika yang serupa.

Selain aturan, database fakta disediakan. Contoh sederhana yang berfungsi dengan aturan di atas bisa berupa:

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).

Perhatikan bahwa white_cow dan padang rumput, dll. Tidak ditulis dalam huruf kapital. Mereka bukan variabel, mereka adalah atom.

Akhirnya Anda membuat kueri dan bertanya apa yang akan terjadi.

?- 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

Kueri pertama menanyakan ke mana sapi putih akan bergerak. Berdasarkan aturan dan fakta di atas, jawabannya adalah TIDAK. Ini dapat diartikan sebagai "Saya tidak tahu" atau "Tidak bergerak" tergantung pada apa yang Anda inginkan.

Permintaan kedua menanyakan ke mana sapi hitam itu bergerak. Bergerak ke padang rumput untuk makan.

Kueri terakhir menanyakan ke mana semua sapi bergerak. Akibatnya Anda mendapatkan semua yang mungkin (Sapi, Tujuan) yang masuk akal. Dalam hal ini banteng hitam bergerak ke padang rumput seperti yang diharapkan. Namun, banteng yang marah memiliki dua pilihan yang memenuhi aturan, baik itu bisa pindah ke padang rumput atau gudang.

Catatan: Sudah bertahun-tahun sejak saya terakhir menulis Prolog, semua contoh mungkin tidak valid secara sintaksis tetapi idenya harus benar.

Menangani masalah web jika Anda dapat membuat mesin aturan di mana setiap aturan spesifik dikodekan secara independen. Penyempurnaan lebih lanjut untuk ini adalah membuat bahasa khusus domain (DSL) untuk membuat aturan, namun DSL sendiri hanya memindahkan masalah dari satu basis kode (utama) ke yang lain (DSL). Tanpa struktur, DSL tidak akan berjalan lebih baik daripada bahasa asli (Java, C # dll), jadi kami akan kembali ke sana setelah kami menemukan pendekatan struktural yang ditingkatkan.

Masalah mendasar adalah bahwa Anda mengalami masalah pemodelan. Setiap kali Anda menghadapi situasi kombinatorial seperti ini, itu adalah tanda yang jelas bahwa model abstraksi Anda yang menggambarkan situasinya terlalu kasar. Anda kemungkinan besar menggabungkan elemen yang seharusnya dimiliki oleh model yang berbeda dalam satu entitas.

Jika Anda terus mendobrak model Anda, pada akhirnya Anda akan sepenuhnya melarutkan efek kombinatorial ini. Namun ketika mengambil jalan ini mudah tersesat dalam desain Anda menciptakan kekacauan yang lebih besar, perfeksionisme di sini belum tentu teman Anda.

Mesin negara terbatas dan mesin aturan hanyalah contoh bagaimana masalah ini dapat dipecah dan dibuat lebih mudah dikelola. Gagasan utama di sini adalah bahwa cara yang baik untuk menghilangkan masalah kombinatorial seperti ini adalah sering membuat desain dan mengulanginya ad-mual di tingkat abstraksi bersarang sampai sistem Anda berkinerja memuaskan. Sejalan dengan bagaimana fraktal digunakan untuk membuat pola yang rumit. Aturannya tetap sama tidak masalah jika Anda melihat sistem Anda dengan mikroskop atau dari pandangan mata burung yang tinggi.

Contoh penerapan ini ke domain Anda.

Anda mencoba memodelkan bagaimana sapi bergerak melalui medan. Meskipun pertanyaan Anda tidak memiliki rincian, saya akan menebak bahwa jumlah besar Anda jika termasuk fragmen keputusan seperti if cow.isStanding then cow.canRun = truetetapi Anda terjebak ketika Anda menambahkan rincian daerah misalnya. Jadi untuk setiap tindakan yang ingin Anda ambil, Anda harus memeriksa setiap aspek yang dapat Anda pikirkan dan ulangi verifikasi ini untuk tindakan selanjutnya yang mungkin.

Pertama kita perlu desain berulang kami, yang dalam hal ini akan menjadi FSM untuk memodelkan keadaan yang berubah dari simulasi. Jadi hal pertama yang akan saya lakukan adalah menerapkan referensi FSM, mendefinisikan antarmuka negara , antarmuka transisi , dan mungkin konteks transisiyang dapat berisi informasi yang dibagikan agar tersedia bagi dua lainnya. Implementasi FSM dasar akan beralih dari satu transisi ke yang lain terlepas dari konteksnya, di sinilah mesin aturan masuk. Mesin aturan bersih merangkum kondisi yang harus dipenuhi jika transisi akan berlangsung. Mesin aturan di sini bisa sesederhana daftar aturan yang masing-masing memiliki fungsi evaluasi mengembalikan boolean. Untuk memeriksa apakah suatu transisi harus kita lakukan, lakukan iterasi pada daftar aturan dan jika ada yang salah, transisi tersebut tidak terjadi. Transisi itu sendiri akan berisi kode perilaku untuk mengubah keadaan FSM saat ini (dan tugas-tugas lain yang mungkin).

Sekarang, jika saya mulai mengimplementasikan simulasi sebagai FSM besar tunggal pada level ALLAH saya berakhir dengan BANYAK keadaan yang mungkin, transisi dll. Jika-selain kekacauan terlihat seperti sudah diperbaiki tetapi sebenarnya hanya tersebar, masing-masing JIKA adalah sekarang aturan yang melakukan pengujian terhadap informasi spesifik konteks (yang pada titik ini cukup banyak mengandung segalanya) dan setiap badan IF berada di suatu tempat dalam kode transisi.

Masukkan rincian fraktal: langkah pertama adalah membuat FSM untuk setiap sapi di mana negara bagian adalah keadaan internal sapi itu sendiri (berdiri, berlari, berjalan, merumput dll) dan transisi di antara mereka akan dipengaruhi oleh lingkungan. Ada kemungkinan bahwa grafik tidak lengkap, misalnya penggembalaan hanya dapat diakses dari status tegakan, setiap transisi lain tidak disetujui karena hanya tidak ada dalam model. Di sini Anda secara efektif memisahkan data dalam dua model berbeda, sapi dan medan. Masing-masing dengan properti itu sendiri diatur. Rincian ini memungkinkan Anda menyederhanakan desain mesin secara keseluruhan. Sekarang alih-alih memiliki mesin aturan tunggal yang memutuskan semua yang Anda miliki, mesin aturan lebih sederhana (satu untuk setiap transisi) yang memutuskan detail yang sangat spesifik.

Karena saya menggunakan kembali kode yang sama untuk FSM, ini pada dasarnya adalah konfigurasi FSM. Ingat ketika kami menyebutkan DSL sebelumnya? Di sinilah DSL dapat melakukan banyak hal baik jika Anda memiliki banyak aturan & transisi untuk ditulis.

Lebih dalam

Sekarang ALLAH tidak lagi harus berurusan dengan semua kerumitan dalam mengelola kondisi internal sapi, tetapi kita bisa mendorongnya lebih jauh. Sebagai contoh, masih ada banyak kerumitan dalam mengelola medan. Di sinilah Anda memutuskan di mana kerusakan cukup. Jika misalnya dalam ALLAH Anda, Anda akhirnya mengelola dinamika medan (rumput panjang, lumpur, lumpur kering, rumput pendek dll) kami dapat mengulangi pola yang sama. Tidak ada yang mencegah Anda menanamkan logika seperti itu di medan itu sendiri dengan mengekstraksi semua keadaan medan (rumput panjang, rumput pendek, berlumpur, kering, dll.) Ke FSM medan baru dengan transisi antara negara dan mungkin aturan sederhana. Misalnya untuk mencapai kondisi berlumpur, mesin aturan harus memeriksa konteks untuk menemukan cairan, jika tidak, itu tidak mungkin. Sekarang ALLAH masih lebih sederhana.

Anda dapat melengkapi sistem FSM dengan membuat mereka otonom dan memberi mereka masing-masing utas. Langkah terakhir ini tidak perlu tetapi memungkinkan Anda untuk mengubah interaksi sistem secara dinamis dengan menyesuaikan bagaimana Anda mendelegasikan pengambilan keputusan Anda (meluncurkan FSM khusus atau hanya mengembalikan negara yang ditentukan sebelumnya).

Ingat bagaimana kami menyebutkan bahwa transisi juga dapat melakukan "tugas lain yang mungkin"? Mari kita telusuri dengan menambahkan kemungkinan model yang berbeda (FSM) untuk berkomunikasi satu sama lain. Anda dapat menetapkan serangkaian acara dan memungkinkan setiap FSM untuk mendaftarkan pendengar acara ini. Jadi, jika, misalnya seekor sapi memasuki hex medan, hex dapat mendaftarkan pendengar untuk perubahan transisi. Di sini menjadi sedikit rumit karena setiap FSM diimplementasikan pada tingkat yang sangat tinggi tanpa sepengetahuan domain spesifik yang disimpannya. Namun Anda dapat mencapai ini dengan meminta sapi itu menerbitkan daftar peristiwa dan sel dapat mendaftar jika ia melihat peristiwa yang dapat bereaksi. Hirarki acara keluarga yang baik di sini adalah investasi yang bagus.

Anda dapat mendorong lebih dalam lagi dengan memodelkan tingkat nutrisi dan siklus pertumbuhan rumput, dengan ... Anda dapat menebaknya ... rumput FSM yang tertanam dalam model patch medan sendiri.

Jika Anda mendorong gagasan itu cukup jauh, ALLAH hanya memiliki sedikit hal untuk dilakukan karena semua aspeknya cukup banyak dikelola sendiri, membebaskan waktu untuk dihabiskan untuk hal-hal yang lebih saleh.

Rekap

Seperti yang dinyatakan di atas FSM di sini bukan solusi, hanya sarana untuk menggambarkan bahwa solusi untuk masalah seperti itu tidak ditemukan dalam kode per katakan tetapi bagaimana Anda memodelkan masalah Anda. Kemungkinan besar ada solusi lain yang mungkin dan kemungkinan besar jauh lebih baik daripada proposisi FSM saya. Namun pendekatan "fraktal" tetap merupakan cara yang baik untuk mengelola kesulitan ini. Jika dilakukan dengan benar, Anda dapat secara dinamis mengalokasikan tingkat yang lebih dalam di mana itu penting sambil memberikan model yang lebih sederhana di mana itu kurang penting. Anda dapat mengantri perubahan dan menerapkannya saat sumber daya tersedia. Dalam urutan tindakan mungkin tidak terlalu penting untuk menghitung transfer nutrisi dari sapi ke tambalan rumput. Namun Anda dapat merekam transisi ini dan menerapkan perubahan di lain waktu atau hanya perkiraan dengan tebakan yang berpendidikan hanya dengan mengganti mesin aturan atau mungkin mengganti implementasi FSM sama sekali dengan versi naif yang lebih sederhana untuk elemen yang tidak berada dalam bidang langsung dari bunga (bahwa sapi di ujung lain lapangan) untuk memungkinkan interaksi yang lebih rinci untuk mendapatkan fokus dan sumber daya yang lebih besar. Semua ini tanpa pernah meninjau kembali sistem secara keseluruhan; karena setiap bagian terisolasi dengan baik, menjadi lebih mudah untuk membuat penggantian drop-in yang membatasi atau memperluas kedalaman model Anda. Dengan menggunakan desain standar, Anda dapat mengembangkannya dan memaksimalkan investasi yang dibuat dalam alat ad-hoc seperti DSL untuk menetapkan aturan atau kosa kata standar untuk acara, sekali lagi mulai dari tingkat yang sangat tinggi dan menambahkan penyempurnaan yang diperlukan. karena setiap bagian terisolasi dengan baik, menjadi lebih mudah untuk membuat penggantian drop-in yang membatasi atau memperluas kedalaman model Anda. Dengan menggunakan desain standar, Anda dapat mengembangkannya dan memaksimalkan investasi yang dibuat dalam alat ad-hoc seperti DSL untuk menetapkan aturan atau kosa kata standar untuk acara, sekali lagi mulai dari tingkat yang sangat tinggi dan menambahkan penyempurnaan yang diperlukan. karena setiap bagian terisolasi dengan baik, menjadi lebih mudah untuk membuat penggantian drop-in yang membatasi atau memperluas kedalaman model Anda. Dengan menggunakan desain standar, Anda dapat mengembangkannya dan memaksimalkan investasi yang dibuat dalam alat ad-hoc seperti DSL untuk menetapkan aturan atau kosa kata standar untuk acara, sekali lagi mulai dari tingkat yang sangat tinggi dan menambahkan penyempurnaan yang diperlukan.

Saya akan memberikan contoh kode tetapi ini yang bisa saya lakukan saat ini.

Kedengarannya seperti semua pernyataan kondisional yang Anda bicarakan ini harus benar-benar data yang mengonfigurasi program Anda dan bukan bagian dari program Anda sendiri. Jika Anda dapat memperlakukannya seperti itu, maka Anda akan bebas untuk mengubah cara kerja program Anda dengan hanya mengubah konfigurasinya alih-alih harus memodifikasi kode Anda dan mengkompilasi ulang setiap kali Anda ingin meningkatkan model Anda.

Ada banyak cara berbeda untuk memodelkan dunia nyata, tergantung pada sifat masalah Anda. Berbagai kondisi Anda mungkin menjadi aturan atau kendala yang diterapkan pada simulasi. Alih-alih memiliki kode yang terlihat seperti:

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

Anda malah dapat memiliki kode yang terlihat seperti:

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

Atau, jika Anda dapat mengembangkan program linier yang memodelkan perilaku sapi yang diberi sejumlah input, setiap kendala mungkin menjadi garis dalam sistem persamaan. Anda kemudian dapat mengubahnya menjadi model Markov yang dapat Anda ulangi.

Sulit untuk mengatakan apa pendekatan yang tepat untuk situasi Anda, tetapi saya pikir Anda akan memiliki waktu yang jauh lebih mudah jika Anda menganggap kendala Anda sebagai input untuk program Anda dan bukan kode.

Tidak ada yang menyebutkan ini, jadi saya pikir saya akan mengatakannya secara eksplisit:

Ribuan aturan "Jika .. Lalu .. Lain" adalah tanda aplikasi yang dirancang dengan buruk.

Sementara representasi data spesifik domain mungkin terlihat seperti aturan ini, apakah Anda benar-benar yakin bahwa implementasi Anda harus menyerupai representasi spesifik domain?

Silakan, gunakan perangkat lunak / bahasa komputer yang sesuai untuk tugas tersebut. Matlab sangat sering digunakan untuk memodelkan sistem yang kompleks, di mana Anda dapat memiliki ribuan kondisi. Tidak menggunakan if / then / else klausa, tetapi dengan analisis numerik. R adalah bahasa komputer sumber terbuka yang diisi dengan alat dan paket untuk melakukan hal yang sama. Tetapi ini berarti Anda juga harus menyatakan kembali model Anda dalam istilah yang lebih matematis, sehingga Anda dapat memasukkan kedua pengaruh utama dan interaksi antara pengaruh dalam model.

Jika Anda belum melakukannya, silakan ikuti kursus tentang pemodelan dan simulasi. Hal terakhir yang harus Anda lakukan, adalah mempertimbangkan menulis model seperti itu dalam hal if - then - else. Kami memiliki rantai montov carlo markov, mesin dukungan vektor, jaringan saraf, analisis variabel laten, ... Tolong jangan melemparkan diri Anda 100 tahun yang lalu dengan mengabaikan kekayaan pada alat pemodelan yang Anda miliki.

Mesin aturan mungkin membantu karena jika ada begitu banyak jika / maka aturan mungkin akan membantu untuk menempatkan semuanya di satu tempat di luar program di mana pengguna dapat mengeditnya tanpa perlu tahu bahasa pemrograman. Juga, alat visualisasi mungkin tersedia.

Anda juga bisa melihat solusi pemrograman logika (seperti Prolog). Anda dapat dengan cepat mengubah daftar pernyataan if / then dan melakukan hal-hal seperti melihat apakah kombinasi input akan menghasilkan hasil tertentu, dll. Hal ini juga dapat terjadi menjadi lebih bersih dalam logika predikat urutan pertama daripada sebagai kode prosedural (atau sebagai kode berorientasi objek).

Tiba-tiba saya sadar:

Anda perlu menggunakan Decision Learning Tree (Algoritma ID3).

Sangat mungkin seseorang telah menerapkannya dalam bahasa Anda. Jika tidak, Anda bisa port perpustakaan yang ada

Ini lebih merupakan jawaban wiki komunitas, menggabungkan berbagai alat pemodelan yang disarankan oleh jawaban lain, saya baru saja menambahkan tautan tambahan ke sumber daya.

Saya tidak berpikir ada kebutuhan untuk menyatakan kembali bahwa Anda harus menggunakan pendekatan yang berbeda untuk ribuan pernyataan hard-code if / else.

• Pemrograman DSL (Bahasa Spesifik Domain)
• Markov Model / proses pengambilan keputusan Markov
• Algoritme rete / Rete
• Sistem ahli
• Matlab , (Wikipedia)
• R

Setiap aplikasi besar berisi ribuan if-then-elsepernyataan, tidak termasuk kontrol aliran lainnya, dan aplikasi tersebut masih didebug dan dipelihara, meskipun kompleksitasnya.

Juga, jumlah pernyataan tidak membuat aliran tidak dapat diprediksi . Pemrograman asinkron tidak. Jika Anda menggunakan algoritma deterministik secara sinkron, Anda akan memiliki perilaku yang dapat diprediksi 100%, setiap saat.

Anda mungkin harus menjelaskan dengan lebih baik apa yang Anda coba lakukan pada Stack Overflow atau Code Review sehingga orang dapat menyarankan Anda teknik refactoring yang tepat untuk digunakan. Anda mungkin juga ingin mengajukan pertanyaan yang lebih tepat, seperti "Bagaimana cara saya menghindari terlalu banyak ifpernyataan yang bersarang <diberi sepotong kode>".

Buat aplikasi Anda dapat dikelola dengan mendesainnya dengan baik. Rancang aplikasi Anda dengan memecah berbagai logika bisnis ke dalam kelas / modul terpisah. Tulis tes unit yang menguji masing-masing kelas / modul ini secara terpisah. Ini penting dan akan membantu Anda memastikan bahwa logika bisnis diimplementasikan seperti yang diharapkan.

Mungkin tidak akan ada satu cara untuk merancang jalan keluar dari masalah Anda, tetapi Anda dapat mengelola kerumitannya sepotong demi sepotong jika Anda mencoba untuk memisahkan area yang berbeda di mana Anda menemukan diri Anda menulis blok besar jika pernyataan dan menerapkan solusi untuk masing-masing masalah yang lebih kecil.

Lihatlah teknik-teknik seperti aturan yang dibicarakan dalam Refactoring untuk cara-cara untuk memecah kondisional besar ke dalam potongan yang dapat dikelola - beberapa kelas dengan antarmuka umum dapat menggantikan pernyataan kasus, misalnya.

Keluar lebih awal juga sangat membantu. Jika Anda memiliki kondisi kesalahan, singkirkan semuanya di awal fungsi dengan melempar pengecualian atau kembali alih-alih membiarkannya bersarang.

Jika Anda memecah kondisi Anda menjadi fungsi predikat, mungkin lebih mudah untuk melacaknya. Selain itu, jika Anda bisa membuatnya menjadi bentuk standar, Anda dapat membuatnya dalam struktur data yang dibangun secara dinamis, alih-alih yang dibuat dengan hardcode.

Saya sarankan Anda menggunakan mesin aturan. Dalam kasus Java, jBPM atau Oracle BPM dapat bermanfaat. Mesin aturan pada dasarnya memungkinkan Anda untuk mengkonfigurasi aplikasi melalui XML.

Masalahnya bukan salah satu diselesaikan dengan baik oleh "aturan", apakah dijelaskan oleh "jika-maka" kode prosedural atau solusi berbagai aturan yang dirancang untuk aplikasi bisnis. Pembelajaran mesin menyediakan sejumlah mekanisme untuk pemodelan skenario seperti itu.

Pada dasarnya, kita harus merumuskan beberapa skema untuk menggambarkan faktor-faktor (misalnya, matahari, angin, sumber makanan, kejadian mendadak, dll) yang mempengaruhi "sistem" (yaitu, sapi di padang rumput). Sekalipun ada kepercayaan yang salah arah bahwa seseorang dapat membuat representasi fungsional yang bernilai nyata, berbeda dengan diskrit, tidak ada komputer di dunia nyata (termasuk sistem saraf manusia) yang berbasis nilai nyata atau dihitung berdasarkan nilai-nilai nyata.

Setelah Anda memiliki representasi numerik Anda untuk faktor-faktor yang relevan, Anda dapat membangun salah satu dari beberapa model matematika. Saya akan menyarankan grafik bipartit di mana satu set node mewakili sapi dan yang lainnya beberapa unit area padang rumput. Seekor sapi bagaimanapun menempati beberapa unit unit padang rumput. Untuk setiap sapi ada nilai utilitas yang terkait dengan saat ini dan semua unit padang rumput lainnya. Jika model mengandaikan sapi berusaha untuk mengoptimalkan (apa pun artinya bagi sapi) nilai utilitas unit padang rumputnya, maka sapi akan pindah dari satu unit ke unit dalam upaya untuk mengoptimalkan.

Otomasi seluler berfungsi dengan baik untuk menjalankan model. Matematika yang mendasari di dunia matematika bernilai nyata memotivasi pemerintah sapi adalah model gradien lapangan. Sapi berpindah dari posisi yang dianggap memiliki nilai utilitas lebih rendah ke posisi yang dianggap memiliki nilai utilitas lebih tinggi.

Jika seseorang menyuntikkan perubahan lingkungan ke dalam sistem, maka itu tidak akan bergerak ke solusi kondisi mantap posisi sapi. Ini juga akan menjadi model di mana aspek-aspek teori permainan bisa diterapkan; bukan berarti hal itu akan menambah banyak kasus ini.

Keuntungan di sini adalah menyembelih sapi atau mendapatkan sapi baru dapat dengan mudah dikelola dengan mengurangi dan menambahkan sel "sapi" ke grafik bipartit, saat model sedang berjalan.

Saya tidak berpikir Anda harus mendefinisikan begitu banyak pernyataan if-else. Dari sudut pandang saya masalah Anda memiliki beberapa komponen:

• Itu harus async atau multithreaded, karena Anda memiliki banyak sapi dengan kepribadian yang berbeda, konfigurasi yang berbeda. Setiap sapi bertanya pada dirinya sendiri ke arah mana harus pergi sebelum bergerak berikutnya. Menurut pendapat saya, kode sinkronisasi adalah alat yang buruk untuk masalah ini.

• Konfigurasi pohon keputusan terus berubah. Itu tergantung pada posisi sapi yang sebenarnya, cuaca, waktu, medan, dll ... Alih-alih membangun pohon if-else yang kompleks, saya pikir kita harus mengurangi masalah menjadi naik angin atau arah - fungsi berat : gambar 1 - fungsi arah - berat untuk beberapa aturan

  Sapi harus selalu pergi ke arah yang memiliki jumlah berat terbesar. Jadi, alih-alih membangun pohon keputusan besar, Anda dapat menambahkan seperangkat aturan (dengan fungsi arah-berat berbeda) untuk setiap sapi, dan cukup memproses hasilnya dengan setiap kali Anda bertanya arah. Anda dapat mengkonfigurasi ulang aturan-aturan itu dengan setiap perubahan posisi, atau dengan melewati waktu, atau Anda dapat menambahkan detail ini sebagai parameter, setiap aturan harus dapatkan. Ini adalah keputusan implementasi. Cara termudah untuk mendapatkan arah, untuk menambahkan lingkaran sederhana dari 0 ° hingga 360 ° dengan langkah 1 °. Setelah itu, Anda dapat menghitung jumlah bobot masing-masing 360 arah dan menjalankan fungsi max () untuk mendapatkan arah yang tepat.

• Anda tidak perlu memerlukan jaringan saraf untuk melakukan ini, hanya satu kelas untuk setiap aturan, satu kelas untuk sapi, mungkin untuk medan, dll ... dan satu kelas untuk skenario (misalnya 3 sapi dengan aturan berbeda & 1 medan khusus). gambar 2 - simpul dan koneksi keputusan aplikasi async sapi

  • merah untuk arah olahpesan - peta berat melalui aturan
  • biru untuk pembaruan orientasi dan posisi setelah pengambilan keputusan
  • hijau untuk pembaruan input setelah pembaruan orientasi dan posisi
  • hitam untuk mendapatkan input

  Catatan: Anda mungkin perlu kerangka kerja pengiriman pesan untuk mengimplementasikan sesuatu seperti ini

  Jadi jika membuat sapi pembelajaran bukan bagian dari masalah Anda, Anda tidak perlu jaringan saraf atau algoritma genetika. Saya bukan ahli AI, tapi saya kira jika Anda ingin mengadaptasi sapi Anda dengan yang asli, maka Anda dapat melakukannya hanya dengan algoritma genetika dan seperangkat aturan yang tepat. Jika saya mengerti dengan baik, Anda membutuhkan populasi sapi dengan pengaturan aturan acak. Setelah itu Anda dapat membandingkan perilaku sapi sungguhan dengan perilaku populasi model Anda dan menjaga 10% yang berjalan di jalur terdekat dengan yang asli. Setelah itu Anda dapat menambahkan batasan konfigurasi aturan baru ke pabrik sapi Anda berdasarkan 10% yang Anda pertahankan, dan menambahkan sapi acak baru ke populasi, dan seterusnya, hingga Anda mendapatkan sapi model yang berperilaku seperti yang asli ...

Saya akan menambahkan bahwa mungkin jika Anda benar-benar memiliki ribuan JIKA ... KEMUDIAN aturan Anda mungkin terlalu berlebihan. Untuk apa nilainya, pembicaraan pemodelan jaringan saraf yang saya hadiri sering mulai dengan menyatakan bagaimana dengan "seperangkat aturan sederhana" mereka dapat menghasilkan perilaku yang cukup kompleks dan pencocokan realitas (dari, dalam kasus tersebut, neuron nyata dalam aksi). Jadi, apakah Anda yakinAnda butuh ribuan syarat? Maksud saya, selain 4-5 aspek cuaca, lokasi sumber makanan, kejadian mendadak, penggembalaan, dan medan, apakah Anda benar-benar akan memiliki lebih banyak variabel? Tentu, jika Anda mencoba melakukan semua permutasi yang memungkinkan untuk menggabungkan kondisi tersebut, maka Anda dapat dengan mudah memiliki ribuan aturan, tetapi itu bukan pendekatan yang tepat. Mungkin pendekatan gaya logika fuzzy di mana berbagai faktor memperkenalkan bias pada setiap lokasi sapi yang digabungkan dengan keputusan keseluruhan akan memungkinkan Anda melakukan ini dalam aturan yang jauh lebih sedikit.

Saya juga setuju dengan semua orang bahwa aturan yang ditetapkan harus terpisah dari aliran kode umum, sehingga Anda dapat dengan mudah mengubah tanpa mengubah program. Anda bahkan bisa membuat set aturan yang bersaing dan melihat bagaimana mereka melawan data pergerakan sapi nyata. Terdengar menyenangkan.

Sistem Pakar telah disebutkan, yang merupakan area AI. Untuk sedikit memperluas ini, membaca tentang Inference Engine dapat membantu Anda dengan ini. Pencarian Google mungkin lebih bermanfaat - menulis DSL adalah bagian yang mudah, Anda bisa melakukan ini secara sepele dengan pengurai seperti Gold Parser. Bagian yang sulit datang dari membangun pohon keputusan Anda dan menjalankannya secara efisien.

Banyak sistem medis sudah menggunakan mesin ini, misalnya situs web NHS Direct di Inggris .

Jika Anda seorang .NET'er maka Infer.NET mungkin berguna bagi Anda.

Karena Anda melihat pergerakan sapi, mereka terjebak dalam arah 360 derajat (sapi tidak bisa terbang.) Anda juga memiliki tingkat perjalanan Anda. Ini dapat didefinisikan sebagai vektor.

Sekarang bagaimana Anda menangani hal-hal seperti posisi matahari, kemiringan bukit, suara keras?

Masing-masing derajat akan menjadi variabel yang menandakan keinginan untuk pergi ke arah itu. Katakanlah ranting patah di sebelah kanan sapi di 90 derajat (dengan asumsi sapi menghadap 0 derajat). Keinginan untuk pergi ke kanan akan turun dan keinginan untuk pergi 270 (kiri) akan naik. Telusuri semua rangsangan dengan menambahkan atau mengurangi pengaruhnya pada keinginan sapi untuk menuju ke suatu arah. Setelah semua rangsangan diterapkan, sapi akan pergi ke arah keinginan tertinggi.

Anda juga dapat menerapkan gradien sehingga rangsangan tidak harus biner. Misalnya bukit tidak lurus ke satu arah. Mungkin sapi itu berada di lembah atau di jalan di atas bukit yang datar di depan, di 45 * sedikit di atas bukit di 90 * di bawah bukit. Di 180 * bukit curam.

Anda kemudian dapat menyesuaikan bobot suatu acara, dan itu arah pengaruhnya. Daripada daftar jika thens, Anda memiliki satu tes mencari maks. Juga ketika Anda ingin menambahkan rangsangan, Anda bisa menerapkannya sebelum ujian dan Anda tidak harus berurusan dengan menambahkan semakin banyak kompleksitas.

Alih-alih mengatakan sapi akan pergi ke arah 360 mana saja mari kita memecahnya menjadi 36 arah. Masing-masing 10 derajat

Alih-alih mengatakan sapi akan pergi ke arah 360 mana saja mari kita memecahnya menjadi 36 arah. Masing-masing 10 derajat. Tergantung pada seberapa spesifik Anda perlu.

Gunakan OOP. Bagaimana kalau membuat banyak kelas yang menangani kondisi dasar dan menjalankan metode acak untuk mensimulasikan apa yang Anda lakukan.

Dapatkan seorang programmer untuk membantu.

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.  */
}