[utility.jl] Why having an extra constant term in the CRRA utility function?

1

I happened to notice that the Julia implementation of CRRA utility type is calculating a different value than what the docstring says. There is an extra -1.0 in the numerator that seems to be unnecessary to me. Is this intentionally written like this or a bug?

Here is the code that I am talking about in QuantEcon.jl/src/modeltools/utility.jl:

"""
Type used to evaluate CRRA utility. CRRA utility takes the form

u(c) = ξ c^(1 - γ) / (1 - γ)

Additionally, this code assumes that if c < 1e-10 then

u(c) = ξ (1e-10^(1 - γ) / (1 - γ) + 1e-10^(-γ) * (c - 1e-10))
"""
struct CRRAUtility <: AbstractUtility
    γ::Float64
    ξ::Float64

    function CRRAUtility(γ, ξ=1.0)
        if abs(γ - 1.0) < 1e-8
            error("Your value for γ is very close to 1... Consider using LogUtility")
        end

        return new(γ, ξ)
    end
end

(u::CRRAUtility)(c::Float64) =
    c > 1e-10 ?
       u.ξ * (c^(1.0 - u.γ) - 1.0) / (1.0 - u.γ) :
       u.ξ * ((1e-10^(1.0 - u.γ) - 1.0) / (1.0 - u.γ) + 1e-10^(-u.γ)*(c - 1e-10))
derivative(u::CRRAUtility, c::Float64) =
    c > 1e-10 ? u.ξ * c^(-u.γ) : u.ξ*1e-10^(-u.γ)
2

Hi @Norman. With -1.0, log utility is a special case of CRRA where γ==1.0. I’m sure you can easily find a proof by l’Hôpital’s rule.

You are right in the sense that it does not matter for the consumer’s decision. Even without -1.0, FOC is same but the value of utility is not same.

I think the docs should be fixed.

3

Thank you! Now it makes sense.

4

Thanks @Norman. If you are able to, please submit a pull request to fix the docs:

https://github.com/QuantEcon/QuantEcon.jl/pulls

Regards, John.

5

Should we open an issue for it?

6

I hesitated to do so, as I realized that it is such a trivial error that does not really cause a problem. (I guess very few people will actually compare the numbers calculated from the utility functions.)
But, I would do that if people think it is worthwhile.