Nothing Special   »   [go: up one dir, main page]

Jump to content

Leontief utilities

From Wikipedia, the free encyclopedia

In economics, especially in consumer theory, a Leontief utility function is a function of the form: where:

  • is the number of different goods in the economy.
  • (for ) is the amount of good in the bundle.
  • (for ) is the weight of good for the consumer.

This form of utility function was first conceptualized by Wassily Leontief.

Examples

[edit]

Leontief utility functions represent complementary goods. For example:

  • Suppose is the number of left shoes and the number of right shoes. A consumer can only use pairs of shoes. Hence, his utility is .
  • In a cloud computing environment, there is a large server that runs many different tasks. Suppose a certain type of a task requires 2 CPUs, 3 gigabytes of memory and 4 gigabytes of disk-space to complete. The utility of the user is equal to the number of completed tasks. Hence, it can be represented by: .

Properties

[edit]

A consumer with a Leontief utility function has the following properties:

  • The preferences are weakly monotone but not strongly monotone: having a larger quantity of a single good does not increase utility, but having a larger quantity of all goods does.
  • The preferences are weakly convex, but not strictly convex: a mix of two equivalent bundles may be either equivalent to or better than the original bundles.
  • The indifference curves are L-shaped and their corners are determined by the weights. E.g., for the function , the corners of the indifferent curves are at where .
  • The consumer's demand is always to get the goods in constant ratios determined by the weights, i.e. the consumer demands a bundle where is determined by the income: .[1] Since the Marshallian demand function of every good is increasing in income, all goods are normal goods.[2]

Competitive equilibrium

[edit]

Since Leontief utilities are not strictly convex, they do not satisfy the requirements of the Arrow–Debreu model for existence of a competitive equilibrium. Indeed, a Leontief economy is not guaranteed to have a competitive equilibrium. There are restricted families of Leontief economies that do have a competitive equilibrium.

There is a reduction from the problem of finding a Nash equilibrium in a bimatrix game to the problem of finding a competitive equilibrium in a Leontief economy.[3] This has several implications:

  • It is NP-hard to say whether a particular family of Leontief exchange economies, that is guaranteed to have at least one equilibrium, has more than one equilibrium.
  • It is NP-hard to decide whether a Leontief economy has an equilibrium.

Moreover, the Leontief market exchange problem does not have a fully polynomial-time approximation scheme, unless PPAD ⊆ P.[4]

On the other hand, there are algorithms for finding an approximate equilibrium for some special Leontief economies.[3][5]

Application

[edit]

Dominant resource fairness is a common rule for resource allocation in cloud computing systems, which assums that users have Leontief preferences.

References

[edit]
  1. ^ "Intermediate Micro Lecture Notes" (PDF). Yale University. 21 October 2013. Retrieved 21 October 2013.
  2. ^ Greinecker, Michael (2015-05-11). "Perfect complements have to be normal goods". Retrieved 17 December 2015.
  3. ^ a b Codenotti, Bruno; Saberi, Amin; Varadarajan, Kasturi; Ye, Yinyu (2006). "Leontief economies encode nonzero sum two-player games". Proceedings of the seventeenth annual ACM-SIAM symposium on Discrete algorithm - SODA '06. p. 659. doi:10.1145/1109557.1109629. ISBN 0898716055.
  4. ^ Huang, Li-Sha; Teng, Shang-Hua (2007). "On the Approximation and Smoothed Complexity of Leontief Market Equilibria". Frontiers in Algorithmics. Lecture Notes in Computer Science. Vol. 4613. p. 96. doi:10.1007/978-3-540-73814-5_9. ISBN 978-3-540-73813-8.
  5. ^ Codenotti, Bruno; Varadarajan, Kasturi (2004). "Efficient Computation of Equilibrium Prices for Markets with Leontief Utilities". Automata, Languages and Programming. Lecture Notes in Computer Science. Vol. 3142. p. 371. doi:10.1007/978-3-540-27836-8_33. ISBN 978-3-540-22849-3.