Fork me on GitHub
#clojure-dev
<
2019-12-02
>
sogaiu02:12:22

@andy.fingerhut starting at around 12:50 of https://youtube.com/watch?v=ketJlzX-254 (clojure data structures part 1 2012-12), there is something about comparison and hashing -- may be there's something there that clarifies things?

sogaiu02:12:08

(on a side note, i got the date from: https://github.com/tallesl/Rich-Hickey-fanclub -- but the site shown during the talk appears to be the sourceforge site according the location field of the browser. if one visits http://archive.org, it appears that already in 2009, there was redirection in place from sf to http://clojure.org. so i'm skeptical of the date being 2012)

andy.fingerhut02:12:52

I am pretty sure all YouTube dates are the date the video was uploaded. That is all YouTube really knows.

andy.fingerhut02:12:14

Basically gives you a "created on or before this date", but not much more information than that.

sogaiu03:12:51

makes sense

sogaiu03:12:11

the presentation content does not mention atoms and those look like they were added in 2008-12, so that gives some clue

favila02:12:25

Clojurescript definitely uses unequal cached hash values to short-circuit comparison, eg nodes of a persistent vector. I find it hard to believe clj doesn’t do this too?

andy.fingerhut03:12:08

Do you have a pointer to any particular part of the ClojureScript source code for that handy? No worries if not.

favila13:12:08

Nevermind! CLJS doesn’t use hashes for comparison. It either changed or it never did and somehow I got the wrong impression

favila13:12:00

I thought I remembered -equiv on PHM PAM PV having a “same type” path that did node-by-node comparison of internal structures

favila13:12:12

but they are all generic item-by-item

favila14:12:00

Seems to me this strategy could really speed up e.g. react renders

andy.fingerhut14:12:23

I thought that it was believed that the identical? speedup for equal sub-maps or sub-vectors nested within a larger collection were thought to give most of the existing speedup possible there, but that is just plausible hearsay for me.

favila15:12:32

Without extra effort, they are not identical

andy.fingerhut02:12:20

I agree, that is part of the implementation of calculating and storing a cached value for the hash of a map. However, I do not believe it is ever called during a call of clojure.core/=. The 'eq' in the name 'hasheq' I believe means 'the Clojure-specific hash function, different than Java's hashCode, that returns a value (usually) consistent with clojure.core/=, rather than Java's equals method'

andy.fingerhut07:12:30

Thanks for finding that. That third link you show definitely looks like it is using comparison of hashCode values to speed up equality checks on maps. It was removed in 2011 with this commit, some time before the release of Clojure 1.4.0: https://github.com/clojure/clojure/commit/b5f5ba2e15dc2f20e14e05141f7de7c6a3d91179

andy.fingerhut07:12:15

Note that it is using Java hashCode comparisons, not Clojure hasheq comparisons. I am pretty sure that would be incorrect in general for Clojure, since hashCode can be different even for two Clojure maps that return true for clojure.core/=, e.g. one has an Integer value, the other a BigInteger value, both with the same integer that is clojure.core/=, but not Java equals.

alexmiller14:12:56

@bronsa the latest published tools.analyzer.jvm 0.7.2 depends on tools.reader 1.0.0-beta4. Deps have been bumped since then in the project but not released. Any reason not to release a new version with latest deps?

bronsa14:12:18

I'll cut a release

alexmiller14:12:36

might want to check if deps should be bumped again prior, I didn't look that closely

bronsa14:12:44

yeah will do

bronsa14:12:55

released 0.7.3