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 >
