When == is passed arguments of different type

just wondering about the design choice where, for example,
julia> Int8(1)==Int64(1)
true
julia> typeof(Int8(1))==typeof(Int64(1))
false

why is it that way ? or why was that choice made ? as opposed to, for example,
julia> Int8(1)==Int64(1)
false

p.s. long time julia user first time poster; I appreciate everyone contributing to the design

I would think that that’s because the integer 1 is exactly the same value whether it is stored as an 8-bit of 64-bit integer? So the question is whether the exact same number can be represented with the numerical type. Compare to e.g.:

julia> Float64(1) == Float32(1)
true

julia> Float64(0.3) == Float32(0.3)
false
5 Likes

Also I would add there is === for a comparison involving the type altogether.

1 Like

The basic gist is in the == docs, emphasis mine:

Generic equality operator. Falls back to ===. Should be implemented for all types with a notion of equality, based on the abstract value that an instance represents. For example, all numeric types are compared by numeric value, ignoring type.

This isn’t a trivial matter, and it really cuts to the core of what makes Julia’s generic functions (and multiple dispatch) work. Doing this consistently is quite the feat, especially as it has impacts on other comparisons and hashing… and it needs to play nicely with promotion and wonky floating point semantics and more.

7 Likes

It seems Jeff and Stefan want to get rid of this misfeature in 2.0.

That’s not what the OP was asking about — Int8(1) == 1 == 1.0 == 1/1 is not generally considered a misfeature. That issue is about comparing types that don’t have a meaningful relation, like 1 == Dict("hello"=>[]).

4 Likes