# Infinity symbol

Is there any reason that Julia does not allow Inf to be typed in as \infty?

1 Like

It is not pre-defined, but it’s allowed.

julia> const ∞  = Inf
Inf

julia> 1/∞
0.0

3 Likes

Ah, thanks, I hadn’t thought of that.
Any reason not to pre-define it?

no need, Inf is a Float64, unlike pi, if we had a type for infinity, we probably would

1 Like

More specifically, there are packages like GitHub - JuliaMath/Infinities.jl: A Julia package for representing infinity in all its forms that define ∞ as an alias for a special type, which then can be used to create infinite ranges, arrays, etc. Defining ∞ as an alias for Inf would clash with those approaches, and probably not be the most useful definition. For floating point Inf, I would guess that usually it is the result of a calculation (likely a calculation on floating point numbers that went wrong), and not something you generally work with directly.

3 Likes

Because Inf is not infinity. It’s a symbol that represents this series of bits

julia> bitstring(Inf)
"0111111111110000000000000000000000000000000000000000000000000000"

1 Like

On the contrary, floating-point Inf is quite useful as an input to a function when you want a parameter to be infinite, e.g. you can use it with quadgk to indicate infinite integration bounds (improper integrals), with nlopt to indicate an unbounded optimization parameter, with norm to specify the infinity norm, and in many other contexts.

1 Like

It was proposed and rejected: Adding the ∞ symbol as an alternative to Inf by wg030 · Pull Request #38815 · JuliaLang/julia · GitHub

Why is Inf capitalized the way it is?

1 Like

Ha! Good point. Why?

Interesting, thanks for the examples. I would have thought those types of cases would be better handled by an Infinities.jl-like symbolic infinity, in order to have a type check for the infinite case instead of a runtime check, since presumably the cases you mention have different implementations for the infinite case. I’m sure the runtime check is no problem in terms of performance for those cases, maybe just tradeoffs in terms of code organization (using dispatch instead of if-statements).

Thanks, I see there is/was a variety of opinions.