Ah, ok, thanks. This might cause issues with one of my packages, which is why I'm interested. How would you approach creating the hash dispatch for custom types, and does this impact immutables as well?
On Thursday, July 16, 2015 at 9:09:08 AM UTC-7, Stefan Karpinski wrote: > > This is just an artifact of memory layout – hashing by identity is based > on object_id which is based on memory address. It's not a meaningful > behavioral difference between Julia versions. Sticking mutable objects for > which hash and == disagree is an undefined behavior and causes dictionaries > to do potentially weird things. > > On Thu, Jul 16, 2015 at 12:04 PM, Seth <catc...@bromberger.com > <javascript:>> wrote: > >> I can't because I just rebuilt to latest to test >> https://github.com/JuliaLang/julia/issues/12063 - but I'll try on the >> latest master... >> >> ... and Julia Version 0.4.0-dev+6005 Commit 242bf47 does not appear to >> have the issue (I'm getting two results returned for unique()). >> >> On Thursday, July 16, 2015 at 8:36:03 AM UTC-7, Stefan Karpinski wrote: >>> >>> Dan and/or Seth, can you try that again and check if hash(foos[1]) and >>> hash(foos[2]) have the same last hex digit? >>> >>> On Thu, Jul 16, 2015 at 11:30 AM, Matt Bauman <mba...@gmail.com> wrote: >>> >>>> Bizarre. I happen to have last updated on *exactly* the same commit >>>> SHA, but I'm seeing the original (expected) behavior: >>>> >>>> $ julia -q >>>> julia> versioninfo() >>>> Julia Version 0.4.0-dev+5860 >>>> Commit 7fa43ed (2015-07-08 20:57 UTC) >>>> Platform Info: >>>> System: Darwin (x86_64-apple-darwin14.3.0) >>>> CPU: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz >>>> WORD_SIZE: 64 >>>> BLAS: libopenblas (USE64BITINT NO_AFFINITY NEHALEM) >>>> LAPACK: libopenblas >>>> LIBM: libopenlibm >>>> LLVM: libLLVM-3.3 >>>> >>>> julia> type Foo >>>> x::Int >>>> end >>>> >>>> julia> ==(f1::Foo, f2::Foo) = f1.x == f2.x >>>> == (generic function with 109 methods) >>>> >>>> julia> unique([Foo(4),Foo(4)]) >>>> 2-element Array{Foo,1}: >>>> Foo(4) >>>> Foo(4) >>>> >>>> julia> @which hash(Foo(4), zero(UInt)) >>>> hash(x::ANY, h::UInt64) at hashing.jl:10 >>>> >>>> Might there be some package that changes this behavior? Is the result >>>> of `@which hash(Foo(4), zero(Uint))` the same as what I show above? >>>> >>>> >>>> On Thursday, July 16, 2015 at 11:02:46 AM UTC-4, Seth wrote: >>>>> >>>>> I can confirm this works as described by milktrader on 0.4.0-dev+5860 >>>>> (2015-07-08 20:57 UTC) Commit 7fa43ed (7 days old master). >>>>> >>>>> julia> unique(foos) >>>>> 1-element Array{Foo,1}: >>>>> Foo(4) >>>>> >>>>> >>>>> On Thursday, July 16, 2015 at 7:52:03 AM UTC-7, Stefan Karpinski wrote: >>>>>> >>>>>> I don't see that on 0.4-dev – it also doesn't seem possible without >>>>>> having defined a hash method since unique is implemented with a dict. >>>>>> >>>>>> On Thu, Jul 16, 2015 at 10:29 AM, milktrader <milkt...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Julia 0.4- has different behavior ... >>>>>>> >>>>>>> First, with 0.3.9 >>>>>>> >>>>>>> julia> versioninfo() >>>>>>> Julia Version 0.3.9 >>>>>>> Commit 31efe69 (2015-05-30 11:24 UTC) >>>>>>> Platform Info: >>>>>>> System: Darwin (x86_64-apple-darwin13.4.0) >>>>>>> CPU: Intel(R) Core(TM)2 Duo CPU P7350 @ 2.00GHz >>>>>>> WORD_SIZE: 64 >>>>>>> BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Penryn) >>>>>>> LAPACK: libopenblas >>>>>>> LIBM: libopenlibm >>>>>>> LLVM: libLLVM-3.3 >>>>>>> >>>>>>> julia> type Foo >>>>>>> x::Int >>>>>>> end >>>>>>> >>>>>>> julia> import Base: == >>>>>>> >>>>>>> julia> ==(f1::Foo, f2::Foo) = f1.x == f2.x >>>>>>> == (generic function with 80 methods) >>>>>>> >>>>>>> julia> foos = [Foo(4), Foo(4)] >>>>>>> 2-element Array{Foo,1}: >>>>>>> Foo(4) >>>>>>> Foo(4) >>>>>>> >>>>>>> julia> unique(foos) >>>>>>> 2-element Array{Foo,1}: >>>>>>> Foo(4) >>>>>>> Foo(4) >>>>>>> >>>>>>> julia> unique(foos)[1] == unique(foos)[2] >>>>>>> true >>>>>>> >>>>>>> And now 0.4-dev >>>>>>> >>>>>>> julia> versioninfo() >>>>>>> Julia Version 0.4.0-dev+5587 >>>>>>> Commit 78760e2 (2015-06-25 14:27 UTC) >>>>>>> Platform Info: >>>>>>> System: Darwin (x86_64-apple-darwin13.4.0) >>>>>>> CPU: Intel(R) Core(TM)2 Duo CPU P7350 @ 2.00GHz >>>>>>> WORD_SIZE: 64 >>>>>>> BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Penryn) >>>>>>> LAPACK: libopenblas >>>>>>> LIBM: libopenlibm >>>>>>> LLVM: libLLVM-3.3 >>>>>>> >>>>>>> julia> type Foo >>>>>>> x::Int >>>>>>> end >>>>>>> >>>>>>> julia> import Base: == >>>>>>> >>>>>>> julia> ==(f1::Foo, f2::Foo) = f1.x == f2.x >>>>>>> == (generic function with 108 methods) >>>>>>> >>>>>>> julia> foos = [Foo(4), Foo(4)] >>>>>>> 2-element Array{Foo,1}: >>>>>>> Foo(4) >>>>>>> Foo(4) >>>>>>> >>>>>>> julia> unique(foos) >>>>>>> 1-element Array{Foo,1}: >>>>>>> Foo(4) >>>>>>> >>>>>>> julia> unique(foos)[1] == unique(foos)[2] >>>>>>> ERROR: BoundsError: attempt to access 1-element Array{Foo,1}: >>>>>>> Foo(4) >>>>>>> at index [2] >>>>>>> in getindex at array.jl:292 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thursday, July 16, 2015 at 9:36:21 AM UTC-4, Stefan Karpinski >>>>>>> wrote: >>>>>>>> >>>>>>>> You need to also define a hash method for this type. >>>>>>>> >>>>>>>> >>>>>>>> On Jul 16, 2015, at 9:16 AM, Marc Gallant <marc.j....@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> The unique function doesn't appear to work using iterables of >>>>>>>> custom composite types, e.g., >>>>>>>> >>>>>>>> julia> type Foo >>>>>>>> x::Int >>>>>>>> end >>>>>>>> >>>>>>>> julia> import Base: == >>>>>>>> >>>>>>>> julia> ==(f1::Foo, f2::Foo) = f1.x == f2.x >>>>>>>> == (generic function with 85 methods) >>>>>>>> >>>>>>>> julia> unique(foos) >>>>>>>> 2-element Array{Foo,1}: >>>>>>>> Foo(4) >>>>>>>> Foo(4) >>>>>>>> >>>>>>>> julia> unique(foos)[1] == unique(foos)[2] >>>>>>>> true >>>>>>>> >>>>>>>> >>>>>>>> Is this the intended behaviour? >>>>>>>> >>>>>>>> >>>>>> >>> >
