thanks Ivar, So set depends on Dict too to maintain its elements.
On Wed, Jan 22, 2014 at 11:29 PM, Ivar Nesje <[email protected]> wrote: > Currently at the top of base/set.jl > type Set{T} > dict::Dict{T,Nothing} > > Set() = new(Dict{T,Nothing}()) > Set(x...) = union!(new(Dict{T,Nothing}()), x) > end > > kl. 18:36:36 UTC+1 onsdag 22. januar 2014 skrev Sharmila Gopirajan > Sivakumar følgende: > >> Hi Stefan, >> I beg to differ. Julia's current collection of numeric types >> will meet the needs of almost all users. Users will mostly be defining >> composite types. In the rare case that they are defining a bitstype, its >> usage semantics would most certainly deviate from the builtin numeric types >> that it might not be equivalent to the numeric types.A typical example >> would be Char and Int32. When the user adds a new type, he has the >> freedom to specify how his type should be treated by adding a new method to >> 'hash' function's multiple dispatch with the user-defined type as >> parameter. We could document the procedure to help the user define how his >> user-defined type should be hashed. >> >> To treat the numeric types differently during hashing would be >> inconsistent with how the rest of the built-in operations deal with numeric >> types. This will increase the mental burden for the user to remember that >> only in Dict, same values does not mean same keys. This will be common >> pitfall for most Julia users and we will have to spend more time educating >> how Dict works, that we would have to spend time specifying how to hash >> user-defined types. Also the user, once educated, will have to assiduously >> ensure all accesses of the Dict uses the same datatype. >> >> As an example, I was bit by a similar bug a day back. The >> variables defined in my julia program defaulted to Int64. Unfortunately >> one of the C api database calls returned Int32. I was comparing the result >> with a list of constants using the 'in' operator. Since the 'in' operator >> internally used isequal, these two were considered different, though they >> were same by value and raised an error where there was none. This defeats >> the purpose of type conversions and promotions. We will face similar >> issues in Dict also. >> >> Does the 'Set' collections use hash too? >> >> Regards, >> Sharmi >> >> On Tuesday, January 21, 2014 11:54:12 PM UTC+5:30, Stefan Karpinski wrote: >>> >>> This is very similar to how we used to do hashing. It would be fine if >>> there were a fixed collection of numeric types in Julia, but if course >>> that's not the case and user-defined types need to be able to participate >>> in the hashing behavior, which rapidly spirals out of control. That's what >>> motivated the change to the current behavior, which unfortunately leaves a >>> rather large gap in functionality since there's no good way to express >>> equality comparison that doesn't care about type but considers NaNs to be >>> equal values – which happens to be what I think hashing should probably do. >>> >>> On Jan 21, 2014, at 12:53 PM, Sharmila Gopirajan <[email protected]> >>> wrote: >>> >>> Thanks for the heads up. I will use the master then. I am still >>> interested in implementing the hashing strategy for numbers. So any >>> feedback would be great. >>> >>> Regards, >>> Sharmi >>> >>> >>> On Tue, Jan 21, 2014 at 10:53 PM, Milan Bouchet-Valat >>> <[email protected]>wrote: >>> >>>> Le mardi 21 janvier 2014 à 00:13 -0500, Jeff Bezanson a écrit : >>>> >>>> The main reason is that there are many types of numbers, with more >>>> added all the time. And for purposes of hash tables, it is difficult >>>> to ensure that all numerically-equal numbers hash the same. So we had >>>> isequal(), which is used by dictionaries, distinguish numbers of >>>> different types. At this point, we would kind of like to change this >>>> back and make isequal more liberal (although it would still >>>> distinguish -0.0 and 0.0, and so not be strictly more liberal than >>>> ==). However, the hashing problem remains. Any ideas are welcome. >>>> >>>> Actually, you changed the behavior of in to use == instead of >>>> isequal() after I filed an issue: https://github.com/JuliaLang/ >>>> julia/issues/4941 >>>> >>>> >>>> With git master as of a few days, this works: >>>> >>>> julia> x = int32(4) >>>> 4 >>>> >>>> julia> y = int64(4) >>>> 4 >>>> >>>> julia> x == y >>>> true >>>> >>>> julia> x in [y] >>>> true >>>> >>>> That doesn't mean hashing shouldn't be improved, though. >>>> >>>> >>>> Regards >>>> >>> >>>
