Thực hành tốt nhất để mô tả các mô hình dựa trên đại lý

Tôi làm việc khá nhiều về sinh học toán học / dịch tễ học, trong đó hầu hết các công việc khoa học mô hình hóa / tính toán vẫn bị chi phối bởi các bộ ODE, đôi khi phải thừa nhận các bộ khá phức tạp của chúng. Một trong những kìm của các mô hình này là chúng khá dễ mô tả và nhân rộng. Một bảng các giá trị tham số, và chính các phương trình và bạn đã cho ai đó mọi thứ họ cần để sao chép nghiên cứu của bạn theo bất cứ cách nào họ cảm thấy muốn thực hiện nó.

Nhưng một số mô hình phức tạp hơn đã bắt đầu trở nên phổ biến hơn. Các mô hình dựa trên tác nhân, đặc biệt, dường như vừa khó mô tả hơn trong một ấn phẩm, vừa khó nhân rộng hơn, bởi vì chúng không nhất thiết phải được mô tả hoàn hảo bởi một bộ ODE. Có bất kỳ hướng dẫn nào - hoặc chỉ là kinh nghiệm thực tế - đằng sau việc mô tả các mô hình này theo cách mà người đọc hiểu những gì đã xảy ra và làm cho chúng tương đối đơn giản để nhân rộng?

Tôi không làm việc trong doanh nghiệp đó nhưng ngây thơ tôi nghĩ có ba phần để mô tả đầy đủ

1. Một mô tả về cảnh quan dữ liệu mà họ sống. Mô tả điều này theo cấu trúc dữ liệu (biểu đồ (được định hướng hoặc không bị chặn, có trọng số hoặc không có trọng số); cây; mảng; ...) và dữ liệu được liên kết với mỗi nút. Lưu ý xử lý trường hợp đặc biệt như điều kiện biên định kỳ hoặc trạng thái giả định cho hàng xóm bên ngoài khu vực thử nghiệm. Có lẽ điều này có một kết nối khá rõ ràng với miền vấn đề của bạn.

2. Một mô tả về trạng thái nội bộ của tác nhân và cách nó đưa ra quyết định. Một lần nữa, hy vọng điều này có một giải thích hợp lý rõ ràng.

3. Một mô tả về thời gian tương đối và / hoặc đồng bộ hóa hành động và cập nhật giữa các tác nhân và cảnh quan; và giữa cặp hoặc nhóm đại lý.

Mã giả (hoặc thậm chí mã thực nếu nó không quá ô nhiễm với các chi tiết triển khai) sẽ giúp ích.

Có một thứ gọi là giao thức ODD (Tổng quan, Thiết kế và Chi tiết), được đề xuất bởi Volker Grimm và những người khác để mô tả một mô hình dựa trên tác nhân. Nó bao gồm một danh sách các yếu tố cần thiết để hiểu chức năng của ABM và nhằm mục đích làm cho các mô tả về các mô hình như vậy được chuẩn hóa hơn.

Danh sách kiểm tra những gì phải được mô tả bao gồm:

Tổng quat

1. Mục đích
2. Các thực thể, biến trạng thái và thang đo
3. Tổng quan về quy trình và lập kế hoạch

Thiết kế

1. Nguyên tắc cơ bản
2. Sự xuất hiện
3. Thích ứng
4. Mục tiêu
5. Học tập
6. Sự dự đoán
7. Cảm biến
8. Sự tương tác
9. Sự ngẫu nhiên
10. Tập thể
11. Quan sát

Chi tiết

1. Khởi tạo
2. Dữ liệu đầu vào
3. Mô hình con

Thông tin chi tiết có thể được tìm thấy trong

Grimm, V., Berger, U., DeAngelis, DL, Polhill, JG, Giske, J., & Railsback, SR (2010). Giao thức ODD: Đánh giá và Cập nhật Đầu tiên. Mô hình sinh thái, 221, 2760 Từ2768.

Cách tốt nhất cho đến nay là bao gồm tất cả các mã của bạn làm tài liệu bổ sung. Nếu có thể, cũng bao gồm các tệp có các hạt ngẫu nhiên có liên quan cần thiết để tạo lại kết quả của bạn. Điều này không chỉ cho phép mọi người tạo lại kết quả của bạn (mà bạn có thể không quan tâm), nó còn cho phép họ dễ dàng tiếp tục hơn nơi bạn rời đi. Điều này cho phép hợp tác và trích dẫn mới cho công việc của bạn. Thật không may, điều này đi kèm với khó khăn trong việc buộc bạn phải dọn sạch mã của mình và đảm bảo rằng nó không có lỗi. Do đó, nó là một lý tưởng hơn những gì thông thường trong thực tế. Nhưng ít nhất, bạn nên lưu trữ một phiên bản mã được sử dụng để tạo ra kết quả của mình, theo cách đó nếu một nhà nghiên cứu khác yêu cầu mã, bạn có thể tạo mã.

Về phần mô tả trong bài viết của bạn, sau đó tôi sẽ tập trung vào một mô tả độc lập ở mức độ cao, thực hiện các tính năng mới lạ của mô hình (đây là phần thực tế mà bài báo tốt nhất đạt được). Tập trung vào các tính năng sẽ thay đổi kết quả một cách định tính nếu chúng được điều chỉnh. Hầu hết các mô hình tôi làm việc đều tạo ra kết quả định lượng, nhưng số lượng cụ thể thường không được quan tâm, chỉ có hành vi định tính (vì các tham số thường khác xa với các kết quả có thể quan sát được trong tự nhiên). Vì vậy, tôi tập trung vào việc mô tả các phần của mô hình, rằng nếu thay đổi sẽ thay đổi hành vi định tính của hệ thống. Nếu lối suy nghĩ này buộc tôi phải mô tả từng chi tiết cuối cùng của mô hình của mình cho đến khi thực hiện, thì tôi biết rằng mô hình của tôi không mạnh mẽ lắm, và do đó nên bị loại bỏ.

Một cách tốt để kiểm tra xem mô tả trong giấy của bạn có đủ hay không, là yêu cầu một người bạn (hoặc sinh viên) không làm việc với dự án này với bạn để mô tả cách họ có thể triển khai mô hình của bạn là mã giả. Nếu họ không bị mắc kẹt trong khi thử điều này (như họ đã đến bản phác thảo của một mô hình sẽ tạo ra kết quả định tính tương tự), thì bạn biết rằng bạn đã thực hiện tốt công việc mô tả.