Re: defrecord, equality, hashing, and performance

deftype allows you to override hashCode and/or hasheq (I believe defaulting to identity-based implementations from java.lang.Object). defrecord does not. As mentioned in another message, potemkin may provide easier building blocks to build on than deftype. Andy On Thu, Jun 11, 2015 at 11:10 PM,

Re: defrecord, equality, hashing, and performance

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Prismatic has some document for deftype/defrecord/map, hope it's useful to you: https://github.com/Prismatic/eng-practices/blob/master/clojure/20130926-data-representation.md On 06/12/2015 02:36 AM, Mars0i wrote: > I think that the following is all

Re: defrecord, equality, hashing, and performance

On Thursday, June 11, 2015 at 2:12:12 PM UTC-5, puzzler wrote: > > Zach Tellman's potemkin library includes several useful ways to tweak > deftypes and defrecords. I wish Clojure itself provided more ways to do > this, but in the meantime, potemkin is the best way to create something > custom,

Re: defrecord, equality, hashing, and performance

On Thursday, June 11, 2015 at 2:19:56 PM UTC-5, Andy Fingerhut wrote: > > You can override hashCode and/or hasheq methods in deftype. > I've been unable to do it. Is there something special needed to allow this to work? user=> (defrecord Foo [x] Object (hashCode [this] 42)) CompilerException

Re: Merge optimization question

Hi Leon, If you use merge a lot, check out data.int-map , it only supports integer keys, but is optimized for merges. Merge is essentially (reduce conj) so you could see if using a transient version of the original map and m

Re: `rational?` `decimal?` Am I misunderstanding these? (also `float?`)

On Friday, June 12, 2015 at 12:12:01 AM UTC-4, Andy Fingerhut wrote: > > Some related facts, but not sure if they offer a perfect justification for > _why_ rational? and decimal? return what they do. > > (source rational?) reveals that it returns true for integers, ratios, and > decimal?, where (

Re: `rational?` `decimal?` Am I misunderstanding these? (also `float?`)

Some related facts, but not sure if they offer a perfect justification for _why_ rational? and decimal? return what they do. (source rational?) reveals that it returns true for integers, ratios, and decimal?, where (source decimal?) reveals it is true if it is of type BigDecimal. Arithmetic opera

Re: easy clojure.core.cache interaction

Also worth mentioning is that the implementation is many-thread friendly, so using a cache: 1) won't be a single thread bottleneck (as in the case of using an unadorned agent) 2) work is done on the calling threads Granted, there's a race condition where two threads trying to find the same thing a

easy clojure.core.cache interaction

https://gist.github.com/rwat/4abcebcb4cfae956f382 I've enjoyed using clojure.core.cache for caching results from time expensive operations involving I/O, etc. and feel like this is the sort of function that makes c.c.cache as simple to use as possible. e.g. all it becomes is: (cache-interact c f

Re: defrecord, equality, hashing, and performance

I agree the hashCode performance for records is a concern due to that lack of caching. I noticed the priority of that Jira 1224 changed to "critical" about a week ago (June 3). I was curious why that was done and what that means in terms of prioritization. Last minute squeeze into CLJ versio

Re: `rational?` `decimal?` Am I misunderstanding these? (also `float?`)

On Thursday, June 11, 2015 at 9:34:57 PM UTC-4, John Gabriele wrote: > > ~~~ > (integer? 5) ;=> true Yes > (integer? 5N) ;=> true Yes > (integer? 5.1) ;=> false > > (float? 5.1) ;=> true > (float? 5.1M) ;=> false (?!) > ~~~ > > Whoops. Please ignore the two "Yes"'s. Also, I thin

`rational?` `decimal?` Am I misunderstanding these? (also `float?`)

My understanding is that a rational number is one that can be written as a fraction. For example, 5.1, which can be written as 51/10. But Clojure seems to disagree: ~~~ (rational? 51/10) ;=> true (rational? 5.1) ;=> false (?!) ~~~ Is my definition of "rational" incorrect? Also, my understand

Re: Merge optimization question

(keys old-map) might not be in the same order as (keys new-map). The every? check is almost right but the test will be false where new-map's value is falsey. You could use (set (keys new-map)). -- You received this message because you are subscribed to the Google Groups "Clojure" group. To po

Merge optimization question

If I want merge in an algorithm where it is often the case that the new map has the same keys as the old map, I'd assume using the new map as a replacement is faster in those cases. Of course comparing the keys costs and I'd like to know which is the fastest way. Can I do (= (keys old-map) (ke

Re: defrecord, equality, hashing, and performance

Yes, please vote for that issue. I find myself frequently having to work around this limitation of records in Clojure; I mostly avoid using records directly as a consequence of this performance issue. As a side note, one quick-and-dirty way to get identity semantics for your data is to wrap each

Re: defrecord, equality, hashing, and performance

Ugh. Too many typos there. Here is what I meant: If the reason that defrecord hashing is slow in your application is because _hasheq_ recalculates the hash values from scratch each time, without _caching the value_, consider voting for this ticket so that is improved in the future: http://dev.cl

Re: defrecord, equality, hashing, and performance

You can override hashCode and/or hasheq methods in deftype. If the reason that defrecord hashing is slow in your application is because hashed recalculates the hash values from scratch each time, without hashing, consider voting for this ticket so that is improved in the future: http://dev.clojure

Re: defrecord, equality, hashing, and performance

Zach Tellman's potemkin library includes several useful ways to tweak deftypes and defrecords. I wish Clojure itself provided more ways to do this, but in the meantime, potemkin is the best way to create something custom, like a deftype that behaves mostly like defrecord with some different hashin

defrecord, equality, hashing, and performance

I think that the following is all correct, but I could be wrong about something. The datatypes page at clojure.org says: "defrecord provides ... value-based equality and hashCode", while deftype does not. So (defrecord Rec [x]) (= (Rec. 42) (Rec. 42)) ;=> true b

Re: Question regarding java array

I'm not sure why you'd see much slower results there. For reference, I'm on a Core i7-2720-M (MacbookPro 8,1 13" early 2011), and was using clojure-1.7-beta3. Also, I looked at the code you posted and I'm not so sure about your assumption that Java arrays are slower: * in load-txt-image_array, y

Re: Question regarding java array

Unfortunately, I don't get to decide the data format. It's a dump from previous stage. Also, it's supposed to be super easy for Physics people to look at. If you every work with them, you'll know what I mean XD. But thanks for the suggestion. On Thursday, June 11, 2015 at 7:30:07 AM UTC-5, Andy

Re: Question regarding java array

On Thursday, June 11, 2015 at 5:32:02 AM UTC-4, Ritchie Cai wrote: > > Just wondering though, is there a faster way to load an array than this > way? > https://github.com/malloc82/imaging/blob/45475b99f564b1ac77e668e04b91cb9c01a096d7/src/imaging/dicom.clj#L138 > the data file I'm trying to read f

Re: Question regarding java array

> Lesson learned here for me is that only use java array when absolutely > necessary. I always thought since it's primitive array, it should be the > fastest. Apparently not! This bears repeating. I often find it hit-and-miss to know when idiomatic Clojure will be faster than turning to Java. Ar

Re: Question regarding java array

Yup. Reflection is issue, I needed type hint. However, on another note, I notice that in your first test case, your evaluation takes about 3 ms, but on my machine it takes 76 ms. I'm running a Xeon CPU at 3.5 GHZ, clojure-1.7-RC1. What could cause such a huge different timing? Thanks. On Wedn

Re: Question regarding java array

I tried with vectorz here: https://github.com/malloc82/imaging/blob/45475b99f564b1ac77e668e04b91cb9c01a096d7/src/imaging/dicom.clj#L130-L161 and I'm really impressed with it's performance. The performance is shown here: imaging.dicom> (def data3 (timer "total: " (load-txt-image_matrix "resourc

Re: Question regarding java array

Yup. As it turns out, the slow down is pretty much due to reflection. After added type hint, it's much better now. The code can be viewed here: https://github.com/malloc82/imaging/blob/45475b99f564b1ac77e668e04b91cb9c01a096d7/src/imaging/dicom.clj#L46-L161 They are three different implementation