Salut,
Négociation
L'optimum des deux fonctions d'utilité va trop rarement exister: les deux équations sont sans lien, et le fait que l'optimum soit atteint dans les deux équations pour une situation donnée est très très peu probable.
Ou alors, tu considère qu'il faudrait faire la "moyenne" (pondérée ou pas) des utilité des deux agents? Mais en ce cas, on viole le principe agent: chaque agent n'est pas censé connaitre la fonction d'utilité de l'autre agent. De plus, cela implique que les fonctions d'utilité des deux agents doivent être équitables (aka, normalisées, entre 0% et 100% par exemple).
Donc, chaque agent devrait:
Attention: S et S' sont des situations basées sur N variables! On est donc face à un "hyper-segment", dans un espace de dimension N, et non pas face à un segment du plan (2D) ou de l'espace (3D). Le comportement et le principe seront le même, mais se représenter mentalement le segment est très difficile
Optimum local
La négociation peut être réorientée par l'agent si sa contre-proposition issue du segment [S S'] est inférieure à un optimum local (en) de sa fonction d'utilité. En d'autres mots, si il existe une autre situation S" qui est un optimum local de la fonction d'utilité, alors la contre-proposition sera S", puisque l'utilité associée sera la plus élevée.
Un optimum local est une situation S" pour laquelle l'utilité U" est maximale dans un domaine autour de S". Autrement dit, S" est un optimum local si les valeurs d'utilités "autour" de S" sont plus faibles.
Par exemple:
![[Image: forum_218244_1.gif]](http://www.ilemaths.net/img/forum_img/0218/forum_218244_1.gif)
Admet un optimum local (maximum local) en 1.7 (à vue de nez) qui vaut 0.15. Pourtant, la fonction n'admet pas de maximum (elle part vers l'infini).
Négociation associée:
Fonction d'utilité
Ne fait pas un "salaire(état) = "x" et salaire(société) = "3*x"" pour représenter le fait que l'état accorde moins d'importance au salaire. Reportes ce "3" dans la fonction qui fait la moyenne des utilités partielles:
Où "situation" est un ensemble de variables décrivant la situation proposée, FonctionSatisfaction* donne la satisfaction de l'agent * à partir d'une situation donnée, Fonction_$ est une fonction de moyenne quelconque, qui dépend de l'agent, et Fonction#* est la fonction donnant une satisfaction pour l'agent * dans le domaine # suivant la situation.
En effet, il vaut mieux faire porter le poids que chaque agent attribue à chaque domaine non pas sur la fonction d'valuation sante() mais sur la fonction de moyenne. La lisibilité en sera accrue.
Chaque fonction de satisfaction dans un domaine doit alors être normalisée, par exemple entre 0 et 1 ou entre 0 et 100. Ensuite, dans la fonction de moyenne tu attribues différents poids aux différents domaines, car chaque fonction pour domaine aura utilisé la même unité (additionner des carottes et des salaires même dans une fonction va devenir trop délicat à gérer).
Exemple:
Où salaire_* et sante_* peuvent être des fonctions basées sur tanh.
Exemple d'implémentation
Revenons à la question:
Je n'ai pas d'exemple de négociation bilatérale: les calculs de simulation dans ECLERD (comme les flux migratoires) sont basés sur un méthode unilatérale, et exécutés par les deux agents, qui génère donc deux flux parfois opposés:
Enfin, je ne vois pas l'intérêt de l'implémentation de la fonction d'utilité elle-même: ce n'est qu'une fonction mathématique, qui une fois exprimée se code directement quel que soit le langage (pour peu que les fonctions mathématiques utilisées soient implémentées dans le langage, ce qui exclus d'ailleurs les fonctions transcendantes, raison pour laquelle d'ailleurs il n'était pas possible de faire autrement que du tour-par-tour dans la régénération des ressources végétales de Sephi
).
Le plus difficile est de définir cette fonction d'utilité, et non de l'implémenter.
Adapt or Perish
N'oublies pas que les fonctions d'utilité peuvent varier au fil de la vie de l'agent:
Donc, les pondérations des fonctions d'utilité, incarnées par les prix, vont automatiquement s'ajuster dans le réseau des agents. Ainsi, si tu laisses les prix (les fonctions d'utilité) s'ajuster indépendamment pour chaque agent, alors quelque soit ton choix pour les pondérations de départ, le réseau va s'adapter, s'ajuster et les prix vont s'auto-optimiser
Mais attention, car cela pourra aussi laisser émerger de sacrés comportements de spéculateurs Tu verras peut-être apparaitre dans ton réseau, des agents qui ne produiront rien, et qui ne feront qu'acheter et vendre aux bons moment :p
Négociation
L'optimum des deux fonctions d'utilité va trop rarement exister: les deux équations sont sans lien, et le fait que l'optimum soit atteint dans les deux équations pour une situation donnée est très très peu probable.
Ou alors, tu considère qu'il faudrait faire la "moyenne" (pondérée ou pas) des utilité des deux agents? Mais en ce cas, on viole le principe agent: chaque agent n'est pas censé connaitre la fonction d'utilité de l'autre agent. De plus, cela implique que les fonctions d'utilité des deux agents doivent être équitables (aka, normalisées, entre 0% et 100% par exemple).
Donc, chaque agent devrait:
- Trouver la situation S dans laquelle sa fonction d'utilité est maximale, de valeur U
- Proposer à l'autre agent cette situation S, et recevoir la proposition S' de l'autre agent
- Calculer l'utilité U' pour S'
- Evaluer l'écart entre U et U'
- Faire une contre-proposition, en prenant un point du segment [S S'] pour lequel l'utilité U est alors moins bonne que le maximum, mais acceptable pour l'agent
- Recommencer jusqu'à trouver un accord ou jusqu'à abandonner la négociation
Attention: S et S' sont des situations basées sur N variables! On est donc face à un "hyper-segment", dans un espace de dimension N, et non pas face à un segment du plan (2D) ou de l'espace (3D). Le comportement et le principe seront le même, mais se représenter mentalement le segment est très difficile
Optimum local
La négociation peut être réorientée par l'agent si sa contre-proposition issue du segment [S S'] est inférieure à un optimum local (en) de sa fonction d'utilité. En d'autres mots, si il existe une autre situation S" qui est un optimum local de la fonction d'utilité, alors la contre-proposition sera S", puisque l'utilité associée sera la plus élevée.
Un optimum local est une situation S" pour laquelle l'utilité U" est maximale dans un domaine autour de S". Autrement dit, S" est un optimum local si les valeurs d'utilités "autour" de S" sont plus faibles.
Par exemple:
Admet un optimum local (maximum local) en 1.7 (à vue de nez) qui vaut 0.15. Pourtant, la fonction n'admet pas de maximum (elle part vers l'infini).
Négociation associée:
- L'agent A propose S=0 (utilité: 1, hors image)
- L'agent B propose S'=2 (l'agent A ne connais pas l'utilité associée à cette situation par B)
- A calcule que f(S') = 0
- A coupe la poire en deux et accepte une utilité de 0.5
- A contre-propose S=0.375, et B contre-propose S' = 1.5
- A calcule que f(S') = 0.125
- A coupe la poire en deux et accepte une utilité de 0.2
- A contre-propose S=0.675, et B contre-propose S' = 1.25
- A calcule que f(S') = 0.05
- A coupe la poire en deux et accepte une utilité de 0.125
- Poursuivre la même négociation, et proposer S=0.7
- Réorienter la négociation, et proposer S=1.7 (meilleure utilité pour lui, et 1.7 était entre S'=2 et S'=1.5, propositions précédentes de B
- Proposer 2 choix à B: S=0.7 ou S=1.7 et B devra choisir laquelle des deux lui plait le plus
Fonction d'utilité
Ne fait pas un "salaire(état) = "x" et salaire(société) = "3*x"" pour représenter le fait que l'état accorde moins d'importance au salaire. Reportes ce "3" dans la fonction qui fait la moyenne des utilités partielles:
Code :
FonctionSatisfactionEtat(situation) = Fonction_F(FonctionSanteEtat(situation), FonctionSalaireEtat(situation),...)
FonctionSatisfactionEntreprise(situation) = Fonction_G(FonctionSanteEntreprise(situation), FonctionSalaireEntreprise(situation),...)Où "situation" est un ensemble de variables décrivant la situation proposée, FonctionSatisfaction* donne la satisfaction de l'agent * à partir d'une situation donnée, Fonction_$ est une fonction de moyenne quelconque, qui dépend de l'agent, et Fonction#* est la fonction donnant une satisfaction pour l'agent * dans le domaine # suivant la situation.
En effet, il vaut mieux faire porter le poids que chaque agent attribue à chaque domaine non pas sur la fonction d'valuation sante() mais sur la fonction de moyenne. La lisibilité en sera accrue.
Chaque fonction de satisfaction dans un domaine doit alors être normalisée, par exemple entre 0 et 1 ou entre 0 et 100. Ensuite, dans la fonction de moyenne tu attribues différents poids aux différents domaines, car chaque fonction pour domaine aura utilisé la même unité (additionner des carottes et des salaires même dans une fonction va devenir trop délicat à gérer).
Exemple:
Code :
F_etat(salaire, santé) = salaire_etat(salaire) + 2*sante_etat(sante)
F_entreprise(salaire, santé) = 3*salaire_entreprise(salaire) + sante_entreprise(sante)Où salaire_* et sante_* peuvent être des fonctions basées sur tanh.
Exemple d'implémentation
Revenons à la question:
Citation :je voulais savoir si quelqu'un sait où trouver (ou peut proposer lui même) des exemples d'implémentation ( peut importe le langage informatique) de la notion que l'on appel en économie "fonction d'utilité".
Je n'ai pas d'exemple de négociation bilatérale: les calculs de simulation dans ECLERD (comme les flux migratoires) sont basés sur un méthode unilatérale, et exécutés par les deux agents, qui génère donc deux flux parfois opposés:
- 10.000 habitants quittent le pays A pour le pays B parce que le pays A est au chômage
- le pays B est aussi au chômage et donc 10.000 habitants le quittent
Enfin, je ne vois pas l'intérêt de l'implémentation de la fonction d'utilité elle-même: ce n'est qu'une fonction mathématique, qui une fois exprimée se code directement quel que soit le langage (pour peu que les fonctions mathématiques utilisées soient implémentées dans le langage, ce qui exclus d'ailleurs les fonctions transcendantes, raison pour laquelle d'ailleurs il n'était pas possible de faire autrement que du tour-par-tour dans la régénération des ressources végétales de Sephi
).Le plus difficile est de définir cette fonction d'utilité, et non de l'implémenter.
Adapt or Perish
N'oublies pas que les fonctions d'utilité peuvent varier au fil de la vie de l'agent:
- L'agent A a besoin de 1.000 bois, et propose à l'agent B 500 métal contre 1.000 bois (pour A, 2 bois = 1 métal).
- L'agent B n'a pas utilité de ces ressources, et il sait qu'accepter rendrait service à A, et l'agent B ne veut pas, car cela peut lui nuire
- L'agent B fait alors la contre-proposition: 1.000 bois contre +infini métal, car à ce seuil le gain en métal dépasse la perte en nuisance du au fait d'aider A (la fonction d'utilité est maximale)
- L'agent A refuse, une infinité de métal est inaccessible et il fait une contre-proposition: 1.000 bois contre 2.000 métal. L'utilité pour l'agent A est réduite, mais elle est acceptable
- L'agent B accepte.
- L'échange se fait, et le prix perçu varie pour l'agent A: 1 bois = 2 métal
- Plus tard, l'agent B a besoin de bois, il offre alors 500 métal contre 1.000 bois à l'agent A (car pour l'agent B, 2 bois = 1 métal).
- L'agent A refuse (pour lui, 2 métal = 1 bois)
- L'agent B doit donc proposer autre chose, et ajuster son prix perçu du métal, idem pour A.
Donc, les pondérations des fonctions d'utilité, incarnées par les prix, vont automatiquement s'ajuster dans le réseau des agents. Ainsi, si tu laisses les prix (les fonctions d'utilité) s'ajuster indépendamment pour chaque agent, alors quelque soit ton choix pour les pondérations de départ, le réseau va s'adapter, s'ajuster et les prix vont s'auto-optimiser
Mais attention, car cela pourra aussi laisser émerger de sacrés comportements de spéculateurs
Tu verras peut-être apparaitre dans ton réseau, des agents qui ne produiront rien, et qui ne feront qu'acheter et vendre aux bons moment :p