I didn't know reduce could be short circuited! I assume from the code below
this is done calling the function reduced? Is this in Clojure 1.5 only and
is where is this documented?
On Wednesday, February 27, 2013 4:59:33 AM UTC-5, Christophe Grand wrote:
>
>
> On Wed, Feb 27, 2013 at 10:21 AM, Ma
This is pretty neat. Thanks!
Yeah the swapping of prev and curr seems to be a stumbling block.
On Sunday, February 24, 2013 6:08:39 PM UTC-5, Aria Haghighi wrote:
>
> I have a solution (gist here https://gist.github.com/aria42/5026109, key
> bits pasted below). It's pretty short (15 lines) and r
> On Thursday, February 21, 2013 10:27:11 PM UTC+1, Geo wrote:
>>
>> Man, this is exactly how I feel after all this tinkering! It was great
>> for learning Clojure a bit more in depth, but in the end I am going to
>> stick with the Java solution. Especially since i
programming solution, which is O(M*N), but
> there are O(M+N) algorithms that might be faster depending on the length
> and "alphabet" of your input sequences.
>
> On Monday, February 18, 2013 11:16:51 PM UTC-5, Geo wrote:
>>
>> Hello,
>>
>> I
Just wanted to say I am getting a lot out of this discussion.
--
--
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 members are moderated - please be patient with you
in VisualVM to
> find what to optimize and how. The amount of code is about the same at
> either end.
>
>
> On Thursday, February 21, 2013 10:41:55 AM UTC+1, Christophe Grand wrote:
>>
>> I updated my answer on SO, with a deftype-based one that gives me an
>> add
Cool. Thanks for the explanation.
On Tuesday, February 19, 2013 12:47:05 PM UTC-5, Marko Topolnik wrote:
>
> Naturally, it's Object#equals. String's override of equals gets involved
> without the checked downcast.
>
> On Tuesday, February 19, 2013 6:38:07 PM UTC+1, Ge
VM all arrays of Objects are treated the same, regardless
>> of whether those Objects are String, Integer, java.awt.Color, etc.
>>
>> Andy
>>
>> On Feb 19, 2013, at 8:46 AM, Geo wrote:
>>
>> One thing I don't get is that switching the type hints from
Note that I'm not very confident that using long-array instead of int-array
is a true improvement vs. just noise.
On Tuesday, February 19, 2013 11:46:21 AM UTC-5, Geo wrote:
>
> Using long-array instead of int-array seems to produce a very slight but
> noticeable improvement. (~2
One thing I don't get is that switching the type hints from
[#^"[Ljava.lang.String;" a1 #^"[Ljava.lang.String;" a2]
to [^objects a1 ^objects a2] didn't seem to have any negative impact on
performance. Can anyone explain why hinting ^objects is just as good as
specifying that it's an array of S
Using long-array instead of int-array seems to produce a very slight but
noticeable improvement. (~2.1 sec -> ~1.8 sec) = 1.16x improvement
One other thing is that loop seems to return boxed primitives, so by
wrapping the inner loop with (long ) I got another slight performance gain.
(~2.5 sec
ava doesn't check for overflow in primitive
> operations, either.
>
> Also use aset instead of aset-int. I don't know why, but the aset-*
> operations are typically slower than aset, as long as the type hints on the
> aset arguments are good enough.
>
> I got
Hello,
I am cross-posting my Clojure question from StackOverflow. I am trying to
get an algorithm in Clojure to match Java speed and managed to get the
performance to within one order of magnitude and wondering if more is
possible. The full question is here:
http://stackoverflow.com/questions
Clojure is full of pleasant surprises :)
>
>
--
--
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 members are moderated - please be patient with your
first post.
T
Thank you!
Adding type hints solves the problem. The interop now slightly outperforms
Clojure's get and count.
So how come Clojure's get and count don't incur the reflection penalty?
On Sunday, February 17, 2013 9:17:55 AM UTC-5, Geo wrote:
>
> I am writing an expensive
I am writing an expensive algorithms in Clojure and while trying to
optimize the code I discovered something that puzzled me. Clojure count and
get functions are much faster on strings than direct interop with .length
and .charAt. On my machine I get the following:
(def sss (apply str (repeat 1
Thanks.
I investigated it, which led to another related question as to whether lazy
seqs are always chunked (it appears not!). I posted this on stack overflow
here:
http://stackoverflow.com/questions/12412038/in-clojure-are-lazy-seqs-always-chunked
--
You received this message because you are
Hello,
I am just getting started with Clojure and I had a question. I have to
following code:
(get-rss-entry (get-rss-feeds h-res) url)
The call to get-rss-feeds returns a lazy sequence of URLs of feeds that I
need to examine.
The call to get-rss-entry looks for a particular entry (whose :li
18 matches
Mail list logo
