# Why "Int()" is capitalized and "float()" is not?

**URL:** <https://discourse.julialang.org/t/why-int-is-capitalized-and-float-is-not/43285>\
**Category:** Internals & Design\
**Created:** [July 18, 2020, 12:44pm UTC](https://discourse.julialang.org/t/why-int-is-capitalized-and-float-is-not/43285 "2020-07-18T12:44:43Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![alusiani](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/alusiani/32/16415_2.png) [@alusiani](https://discourse.julialang.org/u/alusiani)\
**Post date:** [July 18, 2020, 12:44pm UTC](https://discourse.julialang.org/t/why-int-is-capitalized-and-float-is-not/43285/1 "2020-07-18T12:44:43Z")

</div>

In order to force a number to be float I can use “float(1)”, to force an integer I can use “Int(1e7)”. I am curious about why Int() is capitalized and float() is not. The first is related to Int64 etc, the second one to Float64 etc, both of which are capitalized.

## Cheers,

Alberto Lusiani

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 18, 2020, 12:54pm UTC](https://discourse.julialang.org/t/why-int-is-capitalized-and-float-is-not/43285/2 "2020-07-18T12:54:05Z")

</div>

`Int` converts to, well, `Int`, so it fits the pattern of using specific constructorss for conversion, while generally `float` just attempts to convert to some kind of float, without being specific about the type.

Cf

```julia
julia> float(1f0)
1.0f0

julia> float(1)
1.0

```

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [July 18, 2020, 1:19pm UTC](https://discourse.julialang.org/t/why-int-is-capitalized-and-float-is-not/43285/3 "2020-07-18T13:19:40Z")

</div>

To elaborate on what Tamas said, it’s a convention in Julia that types (and hence their constructors) start with an uppercase letter, while all other functions are lowercase. What you’re seeing here is that there is a convenience function which converts the argument to a floating point type

```julia
julia> float(BigInt(1))
1.0

julia> typeof(ans)
BigFloat

```

while there isn’t a function to convert the argument to a generic integer type. This is probably because a floating point number can’t generally be “converted” to an integer, you likely want to round it in some ways, but you must be explicit about it by using functions like `round`, `floor`, `ceil`, etc…

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [July 18, 2020, 2:30pm UTC](https://discourse.julialang.org/t/why-int-is-capitalized-and-float-is-not/43285/4 "2020-07-18T14:30:17Z")

</div>

One illustrative example is to use `float` on complex integers (I don’t have Julia handy to demonstrate, though.)

---

<div class="post-metadata">

**Author:** ![purplishrock](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/purplishrock/32/13451_2.png) [@purplishrock](https://discourse.julialang.org/u/purplishrock)\
**Post date:** [July 18, 2020, 7:04pm UTC](https://discourse.julialang.org/t/why-int-is-capitalized-and-float-is-not/43285/5 "2020-07-18T19:04:00Z")

</div>

also interesting that float(“1.3”) doesn’t work.  
You have to use parse(Float64, “1.3”), which I get, but about every two weeks or so I try to do ‘float(String)’, lol.

```julia
julia> float("1.3")
ERROR: MethodError: no method matching AbstractFloat(::String)
Closest candidates are:
  AbstractFloat(::Bool) at float.jl:258
  AbstractFloat(::Int8) at float.jl:259
  AbstractFloat(::Int16) at float.jl:260
  ...
Stacktrace:
 [1] float(::String) at ./float.jl:277
 [2] top-level scope at REPL[1]:1

```

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [July 18, 2020, 7:16pm UTC](https://discourse.julialang.org/t/why-int-is-capitalized-and-float-is-not/43285/6 "2020-07-18T19:16:38Z")

</div>

One way to think about this is that there is no ambiguity when asking to convert an integer to float: an integer represents a specific value and if that value can be represented as a float, then that’s the value you should get. While we have some common expectations about how to interpret a string as a number, they are just conventions—there’s no one numeric value that the string `"1.3"` represents. In base 6, the string `"1.3"` represents the number 1.5 and in base 16, it represents the number 1.1875. There could be other stranger conventions for writing numbers where it has an entirely different meaning (p-adics come to mind). We tend to assume base 10 and that’s usually correct and would be a fine default. But that’s not always the case and fundamentally there is parsing and interpretation required when turning a string into a number. That’s not the case when converting an integer to a float—that’s just a change of representation.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [July 18, 2020, 7:23pm UTC](https://discourse.julialang.org/t/why-int-is-capitalized-and-float-is-not/43285/7 "2020-07-18T19:23:20Z")

</div>

There are some potential ambiguities when converting Int to Float64 as well, they are just much less numerous compared to string parsing. Two simple examples are `float(0) == +0. or -0.`, and `float(9*10^18 + 512) == 9.0e18 or 9.000000000000001e18`.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 19, 2020, 6:19am UTC](https://discourse.julialang.org/t/why-int-is-capitalized-and-float-is-not/43285/8 "2020-07-19T06:19:51Z")

</div>

> [@purplishrock](#):
>
> also interesting that float(“1.3”) doesn’t work.

Not really — parsing is not what `float` is for. Try `parse` etc.

The purpose of `float` in Julia is to take ensure that your values end up as _floating point_, usually at a point in some calculation where you are

1. willing to accept the loss in precision implied by floating point,
2. in exchange for implicitly assuming that the result returned by `float` will be a type that has all relevant arithmetic ops defined,
3. you don’t want to bother figuring out the actual float type though, or want to keep it flexible.

This is just my reconstruction though — neither the interface nor the usage is really explained in the docs. Also, `float` is a bit vestigial in the sense that it operates on values, _arrays_, and _types_: in current practice, arrays would be dealt with by broadcasting, and types would get a separate function.

Cf

> <https://github.com/JuliaLang/julia/issues/26552>
>
> On 0.6.2:
> 
> \`\`\`julia
> julia\> using ForwardDiff
> 
> julia\> ForwardDiff.derivative…(sinpi, 1.)
> 0.0
> \`\`\`
> 
> on b571283a4c:
> 
> \`\`\`julia
> julia\> using ForwardDiff
> 
> julia\> ForwardDiff.derivative(sinpi, 1.)
> ERROR: StackOverflowError:
> Stacktrace:
> \[1\] sinpi(::ForwardDiff.Dual{ForwardDiff.Tag{typeof(sinpi),Float64},Float64,1}) at ./special/trig.jl:865 (repeats 80000 times)
> \`\`\`
> 
> This is because of https://github.com/JuliaLang/julia/blob/7674acada0c6b645319c54ed2a6606b5408f5693/base/special/trig.jl#L865
> 
> which seems unfortunate. Similarly, \`log1p\` \[required a workaround in DiffRules\](https://github.com/JuliaDiff/ForwardDiff.jl/issues/261). I wholeheartedly agree with https://github.com/JuliaDiff/ForwardDiff.jl/issues/261#issuecomment-330308814:
> 
> \> Looks like \`Base.Math.JuliaLibm.log1p(x::Real)\` just calls \`Base.Math.JuliaLibm.log1p(float(x))\`, which basically guarantees infinite recursion in the general case
> 
> \`log\` and \`cospi\` also have this issue. Maybe others as well?