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

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

`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> float(1f0)
1.0f0

julia> float(1)
1.0
``````
2 Likes

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> 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…

7 Likes

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

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> 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:
 float(::String) at ./float.jl:277
 top-level scope at REPL:1
``````

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.

5 Likes

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`.

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

1 Like