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.


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.


julia> float(1f0)

julia> float(1)

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

julia> typeof(ans)

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…


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


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.


1 Like