Кращі практики опису моделей на основі агентів


14

Я досить багато працюю в математичній біології / епідеміології, де більшість робіт з моделювання / обчислювальної науки досі переважають набори ОДЕ, правда, іноді досить складні набори з них. Одним із плюсів цих моделей є те, що їх досить легко описати та повторити. Таблиця значень параметрів та самих рівнянь, і ви дали комусь все, що потрібно, щоб повторити ваше дослідження будь-яким способом, яким він захоче його здійснити.

Але дещо складніші моделі стали популярнішими. Зокрема, моделі, що базуються на агентах, здаються важче описати у публікації, і важче їх копіювати, оскільки вони не обов'язково ідеально описуються набором ОР. Чи є якісь вказівки - чи просто практичний досвід - описуючи ці моделі таким чином, щоб читачі розуміли, що трапилося, і робили їх відносно простими для копіювання?


1
Я розумію, що формально описана модель на основі агентів така ж детермінована і проста для відтворення, як і добре звичне диференціальне рівняння. Чи могли б ви вказати на якісь конкретні приклади в літературі?
Арон Ахмадія

@AronAhmadia Багато моделей на основі агентів покладаються на недетерміновані компоненти. Наприклад, творці бібліотеки моделювання MASON вважали, що випадковість є досить важливою, щоб включити їх власну реалізацію генератора випадкових чисел ...
Майкл МакГоуен

@MichaelMcGowan - я хвилювався з цього приводу. Моделювання, засновані на генераторах випадкових чисел, повинні бути використані як частина стратегії відтворення, але тепер вчені повинні спиратися на статистику, щоб зробити висновки.
Арон Ахмадія

@AronAhmadia Частина питання полягає в тому, що я ніколи не бачив багато того, що є формальним описом ABM. І це залишає осторонь питання стохастичності.
Фоміт

Відповіді:


4

Я не працюю в цьому бізнесі, але наївно думаю, що до повного опису є три частини

  1. Опис ландшафту даних, в якому вони живуть. Охарактеризуйте це з точки зору структури даних (графік (спрямований чи непрямий, зважений чи не зважений); дерево; масив; ...) та дані, пов’язані з кожним вузлом. Зверніть увагу на особливі випадки обробки, такі як періодичні граничні умови або передбачуваний стан для сусідів за межами тестової області. Імовірно, це має досить чіткий зв’язок із вашим проблемним доменом.

  2. Опис внутрішнього стану агента та способів прийняття рішень. Знову, сподіваємось, це має досить чітке тлумачення.

  3. Опис відносного часу та / або синхронізації дії та оновлень між агентами та пейзажем; і між парою або групами агентів.

Псевдо-код (або навіть реальний код, якщо він не надто забруднений деталями реалізації) допоможе.


2

Існує щось, що називається протокол ODD (Огляд, дизайн та деталі), запропонований Волкером Гріммом та іншими для опису моделі на основі агентів. Він складається зі списку елементів, необхідних для розуміння функціонування АВМ і спрямований на те, щоб зробити описи таких моделей більш стандартизованими.

Контрольний список того, що має бути описано, складається з:

Огляд

  1. Призначення
  2. Суб'єкти, змінні стану та масштаби
  3. Огляд процесу та планування

Дизайн

  1. Основні принципи
  2. Поява
  3. Адаптація
  4. Цілі
  5. Навчання
  6. Прогнозування
  7. Зондування
  8. Взаємодія
  9. Стохастичність
  10. Колективи
  11. Спостереження

Деталі

  1. Ініціалізація
  2. Вхідні дані
  3. Підмоделі

Більш детальну інформацію можна знайти в

Grimm, V., Berger, U., DeAngelis, DL, Polhill, JG, Giske, J., & Railsback, SR (2010). Протокол ODD: огляд та перше оновлення. Екологічне моделювання, 221, 2760–2768.


1

Найкращий на сьогоднішній день спосіб - включити весь код у якості додаткового матеріалу. Якщо можливо, також додайте файли з відповідними випадковими насінням, необхідними для відновлення результатів. Це не тільки дозволяє людям відтворити ваші результати (які можуть вас не хвилювати), але також дозволяє їм легше продовжувати там, де ви зупинилися. Це дозволяє отримати нові співпраці та цитати до вашої роботи. На жаль, це спричиняє труднощі змусити вас очистити код і переконатися, що його помилка безкоштовна. Отже, це більше ідеал, ніж звичайний на практиці. Але принаймні, ви повинні архівувати версію свого коду, яка використовується для отримання результатів, таким чином, якщо інший дослідник попросить код, ви можете створити його.

Що стосується опису у вашому документі, то я б зосередився на високому рівні, незалежному від реалізації опису ключових нових особливостей моделі (це практична частина найбільш гарного документу досягнення). Сконцентруйтеся на особливостях, які якісно змінять результат, якщо вони підправлені. Більшість моделей, з якими я працюю, дають кількісні результати, але конкретні кількості, як правило, не цікавлять, а лише якісна поведінка (оскільки параметри, як правило, далекі від тих, які можна спостерігати за своєю природою). Таким чином, я зосереджуюсь на описі частин моделі, що при зміні змінить якісну поведінку системи. Якщо такий спосіб мислення змушує мене описати кожну останню деталь моєї моделі до впровадження, то я знаю, що моя модель не дуже надійна, і тому її слід брати до уваги.

Хороший спосіб перевірити, чи достатньо вашого опису в папері, - попросити друга (або студента), який не працював над цим проектом, з вами описати, як вони могли б реалізувати вашу модель, - псевдокод. Якщо вони не зациклюються під час спроби цього (як, наприклад, вони приходять до ескізу моделі, яка повинна дати ті ж якісні результати), то ви знаєте, що ви зробили хорошу роботу з описом.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.