Re: Call for masters thesis ideas (possibly related to Clojure)

What about adding circular dependency resolution to the compiler between Clojure -> Java code ? I know, I know - it's not very sexy but it would go a long way for companies with larger legacy Java code bases that may be considering moving to Clojure. Being able to replace Java code 'one step at a

Re: Boggle solver

C and Common Lisp versions here --> http://code.google.com/p/boggle-solvers/ Both use the same algorithm and data structures as far as possible. The C version can solve a 1000x1000 board in about 40 seconds. The CL version solves a 1000x1000 board in about 65 seconds on a dual core laptop. Haven

Congrats !

Rich, Is there any possibility in the future of the Clojure compiler being able to deal with bi-directional dependencies between Clojure code and Java code ? --> http://groups.google.com/group/clojure/browse_thread/thread/84bd18b3ceeae0e8 --~--~-~--~~~---~--~~ Y

Re: Circular dependencies (Clojure and Java)

To deal with the problem the ideal solution would be supporting something along these lines. It's probably inevitable that at some point the Clojure compiler would have be modified. On Oct 15, 12:17 pm, Manuel Woelker wrote: > On Thu, Oct 15, 2009 at 5:48 AM, jng27 wrote: > > &

Re: Circular dependencies (Clojure and Java)

On Oct 15, 11:48 am, Stuart Sierra wrote: > On Oct 15, 7:56 am, Laurent PETIT wrote: > > > if the clojure classes depend on the java classes in the implementation and > > not in their interfaces ( extends, implements, methods signatures ), then > > you can write your gen-class with a separate

Circular dependencies (Clojure and Java)

The following seems like it could be a common scenario when attempting to re-write parts of an existing Java application in Clojure. Let's say there exists Clojure code and Java code in the same 'project'. The Clojure code depends on the Java code in one direction and then the same is true in the

Pong!

http://jng.imagine27.com/articles/2009-09-12-122605_pong_in_clojure.html --~--~-~--~~~---~--~~ 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 f

Re: Calculating digits of π (Salamin-Brent)

> > You *really* shouldn't do nested defns. They're misleading, as defns > *always* cause a global change. > Just use separate functions. > Agreed, creating global functions that are meant to be local is no good. Using letfn instead. > >           (. (. (* (+ a1 b1) (+ a1 b1)) > >              d

Re: Calculating digits of π (Salamin-Brent)

This updated version is 2x as fast as the previous version : (import 'java.lang.Math) (import 'java.math.MathContext) (import 'java.math.BigDecimal) (defn sb-pi [places] "Calculates PI digits using the Salamin-Brent algorithm and Java's BigDecimal class." (let [digits (+ 10 places) ;; a

Re: Calculating digits of π (Salamin-Brent)

This version is about 2x faster : (import 'java.lang.Math) (import 'java.math.MathContext) (import 'java.math.RoundingMode) (import 'java.math.BigInteger) (import 'java.math.BigDecimal) (defn sb-pi [places] "Calculates PI digits using the Salamin-Brent algorithm and Java's BigDecimal class

Calculating digits of π (Salamin-Brent)

Took a shot at implementing PI in Clojure using a reasonably fast algorithm. So why is it so slow ? Is BigDecimal just that bad ? Would fixed point arithmetic be better using BigInteger ? (MacBook Pro - Intel Core 2 Duo 2.26 GHz - 4GB RAM) (set! *warn-on-reflection* true) (import 'java.lang.Mat