Un algoritmo de fuerza bruta podría no ser la mejor opción. A veces ni siquiera es factible encontrar equilibrios de Nash con información perfecta. Esto se debe a que, incluso si los jugadores y los tipos son finitos, los BNE son un perfil de estrategias (posiblemente mixtas) que maximizan la ganancia esperada. Si el juego es secuencial, esta expectativa puede depender de las propias estrategias y de las estrategias de los demás jugadores. Por lo tanto, el espacio sobre el cual estás buscando las mejores respuestas es bastante grande. Además, el equilibrio es un punto fijo del cual, en general, no sabemos mucho. Por ejemplo:
¿Sabes si el equilibrio existe? ¿es único? ¿puedes definir un operador de contracción para actualizar las estrategias de los jugadores que te llevará al equilibrio?
La codificación solo funcionará si el equilibrio existe, y funcionará bien si tu juego define una contracción. En contraste, si no es único, deberás ser más cuidadoso acerca del algoritmo que utilices para encontrar/aproximar un punto fijo.
Un enfoque más útil sería hacer suposiciones (conjeturas informadas) sobre cómo se verá el equilibrio y luego verificar que dicho equilibrio existe. Algunas suposiciones comunes son: "Simetría": jugadores similares jugando estrategias similares en equilibrio, "estrategias ingenuas": las estrategias de equilibrio son relativamente simples (por ejemplo, maximizar la ganancia instantánea aunque el juego sea dinámico), etc.
Esta no es una tarea sencilla, pero a menudo se aprende más de esta manera. Ten en cuenta que a menudo tienes una multiplicidad de equilibrios y los BNE deben ser refinados a BNE perfecto, BNE secuenciales u otros refinamientos dependiendo de la aplicación.
1 votos
Parece que ya tienes tu algoritmo, y tu pregunta es sobre programación, no economía.
2 votos
Estoy votando para cerrar esta pregunta como fuera de tema porque se trata de lenguajes de programación.