To facilitate inlining, the patch calls out to a separate larger method
which handles a group of cases.
+if(o.getClass().getName().startsWith(java.util.))
+return doalienhasheq(o);
+return o.hashCode();
I was wondering whether an efficient improvement is
It's not just to facilitate inlining, but also to limit the perf hit
for hashing non-collections, some of which make completely reasonable
map keys and set members. I've used the classes Alex Miller mentioned
he was interested in for benchmarking: Class, Character, Var; these
are all good
Also, = defers to equals in all cases except two: (1) numeric
arguments, (2) at least one IPersistentCollection among the arguments.
Clojure collections are allowed to determine whether they are = to the
other thing or not. So, we should calculate special hashCodes for the
java.util collections
Unfortunately the Guava example means that this approach doesn't
really solve the problem at hand... Thanks for pointing it out.
The earlier version with the three-way test in place of the
java.util. check should be semantically correct, at least.
On 13 May 2014 14:40, Michał Marczyk
New patch reinstates the three-way check, but puts it in a separate
static method. Performance seems to be just fine.
I wonder if my previous round of benchmarking with the inline
three-way check was somehow flawed... Either that or the JIT is
happier with the new arrangement for some reason. In
On Sunday, May 11, 2014 6:33:25 PM UTC-5, Alex Miller wrote:
On Sun, May 11, 2014 at 2:06 PM, Mikera mike.r.an...@gmail.comjavascript:
wrote:
OK. this thread is a bit worrying. If I understand correctly, it
means that we've now got inconsistent hash and equals functions. I suspect
On Mon, May 12, 2014 at 12:15 PM, John Hume duelin.mark...@gmail.comwrote:
On Sunday, May 11, 2014 6:33:25 PM UTC-5, Alex Miller wrote:
On Sun, May 11, 2014 at 2:06 PM, Mikera mike.r.an...@gmail.com wrote:
OK. this thread is a bit worrying. If I understand correctly, it
means that we've
On Mon, May 12, 2014 at 12:53 PM, Alex Miller a...@puredanger.com wrote:
My recommendation in Java would be the same - using mutable objects as
keys in a map (where mutability changes the hashcode) is a bug waiting to
happen.
Although I used java.util.ArrayList in the sample REPL session
On Mon, May 12, 2014 at 4:26 PM, John D. Hume duelin.mark...@gmail.comwrote:
On Mon, May 12, 2014 at 12:53 PM, Alex Miller a...@puredanger.com wrote:
My recommendation in Java would be the same - using mutable objects as
keys in a map (where mutability changes the hashcode) is a bug waiting
On Monday, 12 May 2014 00:33:25 UTC+1, Alex Miller wrote:
On Sun, May 11, 2014 at 2:06 PM, Mikera mike.r.an...@gmail.comjavascript:
wrote:
OK. this thread is a bit worrying. If I understand correctly, it
means that we've now got inconsistent hash and equals functions. I suspect
this
I've posted a patch that makes java.util.{List,Map,Map.Entry,Set}
hashes consistent with those of appropriate Clojure collection types
on the ticket.
Performance of repeated hasheq lookups on a single PHM actually seems
to be slightly better with this patch applied. Adding the hasheqs of a
PHM, a
OK. this thread is a bit worrying. If I understand correctly, it means
that we've now got inconsistent hash and equals functions. I suspect this
hasn't bitten many people yet simply because it is unusual to mix Java and
Clojure collections as keys in the same structure, but it seems like a
Euh
From the top of my head after a long working day,
aren't we comparing apples with cabbages here ?
How can you expect a mutable
structure to have any stability
over time ?
They're not values and even worse
they are alien to Clojure.
To how much contortions should
go through to deal with
I'm the reporter of the mentioned ticket and I'm no longer inclined into
fixing the hash. The real issue seems to lay in the fact that the =
equality tries to work with host non-values. Whether the usefulness of such
interoperability outweights the correctness of the =/hash is the issue
which
On Sun, May 11, 2014 at 2:06 PM, Mikera mike.r.anderson...@gmail.comwrote:
OK. this thread is a bit worrying. If I understand correctly, it means
that we've now got inconsistent hash and equals functions. I suspect this
hasn't bitten many people yet simply because it is unusual to mix Java
Thanks for the ticket pointer. I didn't find it in my initial search
because it Affects Version/s: None :-/, and I knew this behavior was new
to 1.6.
For those not up for the medium-length comment-thread read:
non-Clojure-aware Java Collections Framework interface instances are not
considered
On Sat, May 10, 2014 at 7:51 AM, John Hume duelin.mark...@gmail.com wrote:
Thanks for the ticket pointer. I didn't find it in my initial search
because it Affects Version/s: None :-/, and I knew this behavior was new
to 1.6.
I changed Affects Version/s to Release 1.6
Whether that field is
Is this behavioral change in Clojure 1.6.0 expected? Under 1.6.0, a set and
a map seem to treat a java.util.ArrayList differently with respect to its
equivalence to a vector.
https://gist.github.com/duelinmarkers/7c9f84cfc238e5d37a09
user= (- {} (assoc [1 2] vec) (assoc (java.util.ArrayList. [1
Perhaps this is a consequence of the hashing changes in 1.6.
(http://dev.clojure.org/display/design/Better+hashing)
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new
Mike is correct. This change in behavior is due to the hashing changes in
Clojure 1.6. See the comments on ticket
http://dev.clojure.org/jira/browse/CLJ-1372 for some discussion of whether
this is considered a bug. It appears that perhaps the hash consistency is
not promised for mutable
20 matches
Mail list logo
