Яку парадигму використовувати для написання шахового двигуна?

Якщо ви збиралися написати двигун шахових ігор, яку парадигму програмування ви б використовували (OOP, процедурні тощо) і чому б ви її вибрали? Під шаховим двигуном я маю на увазі частину програми, яка оцінює поточну дошку та вирішує наступний крок комп’ютера.

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

Наскільки я знаю, оцінка не є паралельною проблемою, але оцінка різних ланцюгів є, тому я б остаточно написав її для використання декількох ядер і багатопотокових.

Незалежно від того, чи будете ви функціональними чи напівфункціональними - це питання смаку. Особисто я б зайшов у OOP і скористався підтримкою функціонального програмування та паралелізації, яка існує, наприклад, C #

З іншого боку, якби я писав шаховий двигун, я б спробував зробити той, який справді може "думати" про шахи. Використовуючи дошку оцінювання для грубої сили, всі можливі комбінації були зроблені на смерть і надзвичайно добре, але не було великого прогресу afaik у створенні більш мислячого / нечіткого шахового двигуна. Це було б викликом! :)

Знайдіть кілька ігор із дійсно хитрою позицією та сильними рухами (вони позначені! Або !!) та використовуйте їх для тренування та тестування свого двигуна.

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

Я обрав парадигму OOP у моєму шаховому двигуні на ім’я «Турк» . Перша версія мого шахового двигуна була написана більш процедурно, а не OOP. Тоді мені було важко вдосконалити шаховий двигун через довгі кодові блоки та поганий дизайн.

Це залежить від того, чого ви хочете досягти під час написання шахового двигуна. Якщо ви хочете створити шахматний двигун, який є надто сильним, щоб навіть неможливо зробити це на мовах OOP через повільні пізні прив’язки. Якщо ви просто хочете вивчити програмування, а також отримаєте задоволення, написавши шаховий движок, так керовані мови та OOP стануть вашим другом. Я можу запропонувати вам вибрати C #, тому що також можна писати шаховий механізм більш процедурним способом.

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

Можна подумати, що функціональне програмування буде чудовим для шахових програм, оскільки основні алгоритми (пошук альфа-бета-первинного пошуку, оцінка) є рекурсивними та функціонально суворими. Однак шахова програма живе і вмирає на ефективності, і жодна з нинішніх урожаїв функціональних мов не має цієї мети. Всі сто найсучасніших двигунів використовують усі необхідні мови (переважно C / C ++, потім Delphi), щоб мати максимальний контроль над використанням пам'яті, багатопотоковою роботою, глобальним станом та генерацією коду. Усі функціональні мови використовують динамічне розподілення пам'яті для основних структур даних, що є смертю для шахової програми.

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