When == is passed arguments of different type

jaboaf · January 25, 2023, 4:02pm

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

nilshg · January 25, 2023, 4:07pm

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

lmiq · January 25, 2023, 4:12pm

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

mbauman · January 25, 2023, 7:05pm

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.

jar1 · January 25, 2023, 7:35pm

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

github.com/JuliaLang/julia

Type-safe equality operators

opened 12:05AM - 05 May 21 UTC

jtrakk

breaking equality

I often make mistakes by using `==` between two objects that I shouldn't be comp…aring, such as comparing a number to an array of numbers or comparing a string to a character. The `==` comparison evaluates to `false`, but it wasn't the comparison I meant to make. For example, ```jl a = [1,2,3] b = 5 if a == b; # evaluates to false ``` I wish there were an equality-checking operator that would give an error for incompatible types, like in the example above. I'm not sure if the right implementation would be - check if they have exactly the same type - check some `<:` subtyping relationship - check if they can `convert` into each other's types - check if they can `promote` into a shared type or something else, or multiple different operators for different purposes. There are plenty of equals-like operators in unicode (eg ≟, ≐). Regardless, the current situation where my mistakes result in silent `false`s causes me problems too often for comfort; I would much rather get an explicit error that I can correct. What would be a good solution here?

mbauman · January 25, 2023, 7:58pm

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"=>[]).

melonedo · February 19, 2023, 8:45am

Base.jl has this line:

==(x, y) = x === y

So that means if there is no defined method to compare two values, it falls back to identity comparison. You can check that with methods(==):

julia> methods(==)
# 171 methods for generic function "==":
[1] ==(r::Union{StepRange{T}, StepRangeLen{T, T}}, s::Union{StepRange{T}, StepRangeLen{T, T}}) where T in Base at range.jl:1116
[2] ==(r::T, s::T) where T<:Union{LinRange, StepRangeLen} in Base at range.jl:1113
...
[161] ==(y::Int64, x::Float32) in Base at float.jl:450
[162] ==(y::Int64, x::Float64) in Base at float.jl:450
[163] ==(x::T, y::T) where T<:Number in Base at promotion.jl:477
[164] ==(x::Number, y::Number) in Base at promotion.jl:427
...
[169] ==(x) in Base at operators.jl:1135
[170] ==(w, v::WeakRef) in Base at gcutils.jl:5
[171] ==(x, y) in Base at Base.jl:116