Yes, that's definitely a good idea. I tried a few other things (including 
that, I think) after I posted that but nothing really worked and it turned 
out that the tail-recursive version even had a bug.

I couldn't find a way to really keep the amount of copying of the data 
structures (stack, finished above) very low and thus my algorithm was slow. 
I know that the data structures are persistent and share structure but it 
still was slow for that many elements.

I finally solved the problem by implementing an imperative solution with 
Java arrays and type hints. It ran in ~20-30 seconds.

On Thursday, March 28, 2013 2:22:44 AM UTC+1, Stephen Compall wrote:
>
> On Mon, 2013-03-11 at 10:37 -0700, Balint Erdi wrote: 
> >           (let [neighbors (persistent! 
> >                            (reduce 
> >                             (fn [c u] (if (explored u) c (conj! c u))) 
> >                             (transient []) 
> >                             (G v)))] 
>
> What happens if you do ^^^ *after* vvv? 
>
> >              (explored v) (recur vs explored lhalf rhalf (inc iter-cnt)) 
>
> -- 
> Stephen Compall 
> "^aCollection allSatisfy: [:each | aCondition]": less is better than 
>
>
>

-- 
-- 
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.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to