Implémentation fonction d'utilité (économie)

[Argorate]

Bonjour,

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é".

J'aurais bien aimé avoir un aperçu concret de comment mettre ça en place de la cadre de la prise de décisions entre agents lors d'échanges de biens.

merci.

[Ter Rowan]

Bonjour,

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é".

J'aurais bien aimé avoir un aperçu concret de comment mettre ça en place de la cadre de la prise de décisions entre agents lors d'échanges de biens.

merci.

de mon souvenir.. j'espère que ce sera a peu près clair...

Imaginons un système économique avec N variables :

salaire
emploi
santé
impot
chiffre d'affaires
etc...

supposons maintenant que une entreprise veuille s'installer en France pour vendre des OGM (donc risque sur la santé supposé - je dis supposé pour ne pas polémiquer sur c est bien / c'est mal, on s'en fiche ici).

dans ce cadre la France dans un premier temps va dire non (opinion publique etc...)
Après on rentre dans la négociation

la société propose de payer les gens plus cher que le smic
la société déclare qu'elle va embaucher du monde dans une région sinistrée
etc....

dans ces négociations la modélisation par fonction d'utilité permet de trouver l'optimum pour les deux parties (et parfois pour personne)
tu vas avoir l'Etat qui va avoir une fonction du genre

salaire(Etat) + impôt(Etat) + emploi(Etat) - santé(Etat)


tu vas avoir la société qui va avoir une fonction du genre

chiffre d'affaires(société) - salaire(société) - impôt(société) - emploi(société)

et les négociateurs vont chercher à trouver l'optimum de ces deux équations. Si ils trouvent il y a accord gagnant gagnant, si ils ne trouvent pas il y a soit un perdant (voire 2), soit pas d'accord (ce qui revient à un perdant la plupart des cas)


alors il est important de noter que

chaque "morceau" des formulaires (ex salaire() ) est une fonction ( x ou x*x, ou x+3x*x ...) donne un score que l'on peut agréger avec les autres (sinon on additionne des choux en € et des carottes en nombre de chômeur par exemple)

de même si les deux parties ont un intérêt (positif ou négatif) sur une variable, l'intérêt n'est pas forcément le même

exemple le salaire est moins important pour l'état que pour la société.

tu pourrais donc avoir salaire(état) = "x" et salaire(société) = "3*x" où x est le salaire en euros


bon vala une approche très vulgarisante, je sais pas si tu peux en faire quelque chose telle quelle.

[niahoo]

Bon si j'ai bien compris, il s'agit, pour une action impliquant deux parties telle que "S'implanter ou non dans tel pays", de lister toutes les conséquences que cela implique, de leur attribuer un score sur une échelle commune et de voir dans quelle mesure cela est bénéfique pour chacune des parties.

Ensuite, si l'action peut être quantifiable (Société qui peut produire entre 1 et 1 000 000 tonnes d'OGM par an) on peut chercher quelle quantité va avoir les conséquences les plus équilibrées pour chacune des parties, afin que l'échange soit favorable à tout le monde.

J'ai bon ?

[Xenos]

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:

• 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
  

A peut alors faire 3 choses:

• 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:

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
  

Le flux total est donc nul, bien que 20.000 personnes aient bougés. En revanche, on vire toute "négociation" entre agents (aucun dialogue).

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

[Argorate]

Mon problème est beaucoup plus basique Ter Rowan, nihaoo, c'est juste en terme d'échange de ressources comme dans l'exemple de Xenos, genre: 2 bois contre 5 nourritures entre deux agents (pas d'entité genre les états ou quoi, c'est déjà très complexe ça^^).

En fait, ce qui me gène, c'est qu'il n'y a pas de définition mathématique simple de comment définir la fonction d'utilité.

Du coup ce sur quoi je suis parti :
Chaque agent à un besoin, chaque agent mémorise de combien la consommation de chaque ressource satisfait chaque besoin et à quel hauteur.

Ensuite, grâce à cela je calcule la fonction d'utilité U, pour la ressource r, à l'instant t, comme étant la somme des produits du poids W du besoin i avec la satisfaction S pour la ressource r :

Ur(t) = SOM( Wi(t) * Sr )

Du coup, cela permet à un instant t de savoir la valeur relative qu'accorde un agent pour chaque ressource et permettre de déterminé si un agent trouve un accord acceptable.


Qu'es-ce que vous en dites?


PS: pas moyen de mettre des lettres en indices sur le forum?

[Xenos]

La définition mathématique est celle d'une fonction quelconque.
La définition admissible est une fonction croissante (plus on te file de métal contre ton bois, plus t'es content, ou au moins, t'es pas mécontent qu'on te file plus).

L'idée est pas mal, mais ta fonction Ur est non normalisée. Il faudrait la diviser par SUM(Sr), et du coup, sous condition que Wi(t) soit normalisée dans [0..1], alors Ur le sera aussi. Ce sera bien plus pratique et cela t'éviteras de gérer les "satisfactions infinies".

[Ter Rowan]

comme dit Xenos, y a pas de formule à la fonction d'utilité car elle dépend de ... l'utilité... qu'on en a

de plus, contrairement à Xenos, elle ne peut pas être que croissante (mais elle doit l'être dans un intervalle raisonnable)


exemple :

j'ai besoin de métal, plus j'ai de métal, plus je suis content ( fonction croissante) sauf que si j'obtiens 1 tonne d'or dans mon garage me voilà bien, je risque à tout moment de me faire tuer...
si j'obtiens 1 milliard de milliard de tonnes d'or dans mon garage ma maison est écrasée / explose


donc je suis plutôt pour un modèle "borné"

plus j'ai d'or dans mon garage plus je suis content dans un intervalle borné


c'est pas de la blague, je suis sûr qu'on trouvera des exemples un peu partout du type :
on centralise à un endroit les récoltes. Plus j'ai de blé plus je suis content sauf que si il y a plus de blé que de silos, le surplus est perdu et en plus on a plus rien pour les populations qui ont envoyé le blé au point central au lieu de le stocker sur place à petite échelle (y a certainement du avoir des cas comme ça dans le système soviétique à la grande époque stalinienne)



sinon pour en revenir au cas que tu décris tu peux rajouter des pondérations d'ordre local :

celui qui a peur considère le métal plus cher que celui qui n'a pas peur : le métal permet de fournir des armes, si je donne du métal, je donne des armes ==> j'ai encore plus peur de me faire attaquer

[Xenos]

J'aurai décomposé le problème de l'or en deux parties:

• La satisfaction liée à la possession de l'or
  
• La satisfaction (en fait, le risque) lié à son stockage
  

La première est croissante, la seconde est décroissante (le risque est une fonction croissante), l'ensemble des deux est une forme de "cloche".

Je vais donc me corriger: la fonction de satisfaction devrait être monotone. De plus, cela simplifiera les calculs de conception que tu pourrais avoir (intégrales, dérivées,...)

[Argorate]

En fait Wi est borné entre 0 et 100. Donc apriori c'est bon, mais je vois pas pourquoi divisé par SOM( Sr ), il y a un nbre fini de besoin, je vois pas ton histoire d'infini.

Sinon merci pour l'explication, en gros la fonction d'utilité c'est du "vent", on fait ce qu'on veux, c'est totalement théorique et relatif a chaque modèle.

[Xenos]

La fonction d'utilité n'est pas du vent: c'est du vocabulaire, qui désigne une fonction quelconque

Et je me suis mélangé un peu... Ta notation n'est pas une notation classique.
S(t) = ∑(r; Wr(t)*Sr(t) ) / ∑(r; Wr(t) )

Où Wr(t) est le poids associé à une ressource r à la date t
Sr(t) est la satisfaction à la date t pour la ressource r
S(t) la satisfaction totale à la date t
Wr n'est pas forcément normalisé, mais avec une telle formule (qui est une formule de moyenne pondérée classique), S sera normalisée (entre 0 et 1) si les Sr sont normalisées.

Pour l'histoire d'infini, si l'agent cherche à maximiser sa satisfaction, il veut donc maximiser U. Il faut donc que U admette un maximum. Or, certaines fonctions d'utilité peuvent ne pas admettre de maximum: U = ln par exemple n'admet pas de maximum. En de tels cas, l'agent ne serait satisfait (maximum d'utilité) que si la quantité de ressource atteint "+l'infini".

Borner U ne changerait rien:

Code :

U(q) = 2 - 1/q

Avec q≥0 la quantité de ressources.

U(q) est borné: elle ne dépassera jamais 2, et pour autant, U(q) n'admet pas de maximum: q doit tendre vers l'infini pour que l'utilité U soit maximale.

Pour y remédier, il faudrait alors soit:

• Limiter la quantité de ressources, par exemple restreindre q à [0..100], auquel cas le U(q) est maximum pour q = 100, ou bien
  
• Utiliser des fonctions qui tendent vers -∞ quand q tend vers +∞
  

En effet, si ta fonction U est continue sur q=[0..+∞], et si U(+∞) = -∞, alors U admettra un maximum "quelque part", maximum que l'agent cherchera à atteindre.