Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Unable to create matrix in incanter 1.4.0 #114

Closed
marshallshen opened this Issue · 6 comments

3 participants

@marshallshen

I installed incanter 1.4.0 on lein but was unable to create matrix in REPL, but it works fine for 1.3.0. Maybe a package dependency issue?

Bug details can be found in the following link:
http://stackoverflow.com/questions/14087222/unable-to-create-matrix-in-incanter-1-4-0

@alexott
Owner

Hmmm, very strange - I can't reproduce this on my machine. I deleted all incanter jars from ~/.m2/repository/ and used following project to get it from clojars:

(defproject in-test "0.1.0-SNAPSHOT"
    :dependencies [[incanter "1.4.0"]])

and in lein repl, I execute your commands without errors:

user=> (use 'incanter.io)
nil
user=> (use 'incanter.core)
nil
user=> (def A (matrix [[1 2 3] [4 5 6] [7 8 9]])) 
#'user/A
user=> A
[1.0000 2.0000 3.0000
4.0000 5.0000 6.0000
7.0000 8.0000 9.0000]

Can you provide more details on which java version are you using, which OS, etc.

@lionandoil

I can reproduce this with incanter 1.4.* (clojure 1.4.0, JVM 1.6) even after completely wiping incanter/pcolt/jplasma from my local .m2 repositories:

(use '(incanter core io))
(def A (matrix [[1 2 3] [4 5 6] [7 8 9]])) 
user=> NoSuchMethodError edu.emory.mathcs.utils.ConcurrencyUtils.getThreadsBeginN_2D()I  cern.colt.matrix.tdouble.impl.DenseColumnDoubleMatrix2D.assign (DenseColumnDoubleMatrix2D.java:661)
user=> java.lang.NoSuchMethodError: edu.emory.mathcs.utils.ConcurrencyUtils.getThreadsBeginN_2D()I, compiling:(NO_SOURCE_FILE:2)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3387)
at clojure.lang.Compiler$DefExpr.eval(Compiler.java:398)
at clojure.lang.Compiler.eval(Compiler.java:6516)
at clojure.lang.Compiler.eval(Compiler.java:6477)
at clojure.core$eval.invoke(core.clj:2797)
at clojure.main$repl$read_eval_print__6405.invoke(main.clj:245)
at clojure.main$repl$fn__6410.invoke(main.clj:266)
at clojure.main$repl.doInvoke(main.clj:266)
at clojure.lang.RestFn.invoke(RestFn.java:512)
at user$eval27$acc__3301__auto____30$fn__32.invoke(NO_SOURCE_FILE:1)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.NoSuchMethodError: edu.emory.mathcs.utils.ConcurrencyUtils.getThreadsBeginN_2D()I
at cern.colt.matrix.tdouble.impl.DenseColumnDoubleMatrix2D.assign(DenseColumnDoubleMatrix2D.java:661)
at cern.colt.matrix.tdouble.impl.DenseColumnDoubleMatrix2D.<init>(DenseColumnDoubleMatrix2D.java:109)
at incanter.Matrix.<init>(Matrix.java:77)
at incanter.internal$make_matrix.invoke(internal.clj:41)
at incanter.core$matrix.invoke(core.clj:96)
at clojure.lang.AFn.applyToHelper(AFn.java:161)
at clojure.lang.AFn.applyTo(AFn.java:151)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3382)
... 11 more

As in the stackoverflow Link above I can get it to work by either excluding jplasma or using jplasma-0.9.4 instead of 1.2.0. Excluding jplasma from the incanter.core deps should fix this, but if there's gonna be no 1.4.2 release I guess this issue is superfluous anyway?

@lionandoil

The 0.9.4/exclude trick only fixes matrix and to-matrix, I still get the exception in other places, e.g. when calling non-linear-model:

java.lang.NoSuchMethodError: edu.emory.mathcs.utils.ConcurrencyUtils.getThreadsBeginN_1D()I
at cern.colt.matrix.tdouble.impl.DenseDoubleMatrix1D.assign(DenseDoubleMatrix1D.java:472)
at cern.colt.matrix.tdouble.algo.decomposition.DenseDoubleLUDecompositionQuick.decompose(DenseDoubleLUDecompositionQuick.java:145)
at cern.colt.matrix.tdouble.algo.decomposition.DenseDoubleLUDecomposition.<init>(DenseDoubleLUDecomposition.java:43)
at cern.colt.matrix.tdouble.algo.DenseDoubleAlgebra.lu(DenseDoubleAlgebra.java:202)
at cern.colt.matrix.tdouble.algo.DenseDoubleAlgebra.solve(DenseDoubleAlgebra.java:1119)
at cern.colt.matrix.tdouble.algo.DenseDoubleAlgebra.inverse(DenseDoubleAlgebra.java:195)
at incanter.core$solve.doInvoke(core.clj:726)
at clojure.lang.RestFn.invoke(RestFn.java:410)
at incanter.optimize$nls_gauss_newton.doInvoke(optimize.clj:563)
at clojure.lang.RestFn.invoke(RestFn.java:652)
at incanter.optimize$non_linear_model.doInvoke(optimize.clj:668)
at clojure.lang.RestFn.invoke(RestFn.java:470)
at inctest.core$logit_model.invoke(NO_SOURCE_FILE:55)
at inctest.core$eval3998.invoke(NO_SOURCE_FILE:98)
at clojure.lang.Compiler.eval(Compiler.java:6511)
at clojure.lang.Compiler.eval(Compiler.java:6477)
at clojure.core$eval.invoke(core.clj:2797)
at clojure.main$repl$read_eval_print__6405.invoke(main.clj:245)
at clojure.main$repl$fn__6410.invoke(main.clj:266)
at clojure.main$repl.doInvoke(main.clj:266)
at clojure.lang.RestFn.invoke(RestFn.java:512)
at user$eval27$acc__3301__auto____30$fn__32.invoke(NO_SOURCE_FILE:1)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Thread.java:680)
@alexott
Owner

Can you try fresh 1.5.0 release?

@lionandoil

Yes, it's all fixed now!

While not strictly related to the NoSuchMethodError problem, some of the matrix stuff within non-linear-model is still broken, in particular when using :method :newton-raphson, which always results in:

java.lang.ClassCastException: clatrix.core.Matrix cannot be cast to java.lang.Number
at incanter.core$symmetric_matrix.doInvoke(core.clj:2346)
at clojure.lang.RestFn.invoke(RestFn.java:439)
at incanter.optimize$nls_hessian.invoke(optimize.clj:456)
at incanter.optimize$nls_newton_raphson.doInvoke(optimize.clj:501)
at clojure.lang.RestFn.invoke(RestFn.java:866)
at incanter.optimize$non_linear_model.doInvoke(optimize.clj:667)
at clojure.lang.RestFn.invoke(RestFn.java:529)
at language_games.utils.math$eval4848.invoke(Unknown Source)
at clojure.lang.Compiler.eval(Compiler.java:6511)
at clojure.lang.Compiler.load(Compiler.java:6952)
at clojure.lang.Compiler.load(Compiler.java:6921)
at clojure.core$load_reader.invoke(core.clj:3627)
at clojure.core$load_string.invoke(core.clj:3637)
at user$eval4843.invoke(NO_SOURCE_FILE:90)
at clojure.lang.Compiler.eval(Compiler.java:6511)
at clojure.lang.Compiler.eval(Compiler.java:6477)
at clojure.core$eval.invoke(core.clj:2797)
at clojure.main$repl$read_eval_print__6405.invoke(main.clj:245)
at clojure.main$repl$fn__6410.invoke(main.clj:266)
at clojure.main$repl.doInvoke(main.clj:266)
at clojure.lang.RestFn.invoke(RestFn.java:512)
at user$eval27$acc__3301__auto____30$fn__32.invoke(NO_SOURCE_FILE:1)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Thread.java:680)

:gauss-newton also still fails in many more cases than it did with 1.3, usually bailing out with:

org.jblas.exceptions.LapackException: LAPACK DGESV: Linear equation cannot be solved because the matrix was singular.
at org.jblas.SimpleBlas.gesv(SimpleBlas.java:274)
at org.jblas.Solve.solve(Solve.java:48)
at clatrix.core$solve.invoke(core.clj:790)
at clatrix.core$i.invoke(core.clj:801)
at incanter.core$solve.doInvoke(core.clj:695)
at clojure.lang.RestFn.invoke(RestFn.java:410)
at incanter.optimize$nls_gauss_newton.doInvoke(optimize.clj:563)
at clojure.lang.RestFn.invoke(RestFn.java:652)
at incanter.optimize$non_linear_model.doInvoke(optimize.clj:668)
at clojure.lang.RestFn.invoke(RestFn.java:470)
at language_games.utils.math$logistic_model.invoke(Unknown Source)
at language_games.utils.math$foo.invoke(Unknown Source)
at language_games.utils.math$eval4927.invoke(Unknown Source)
at clojure.lang.Compiler.eval(Compiler.java:6511)
at clojure.lang.Compiler.load(Compiler.java:6952)
at clojure.lang.Compiler.load(Compiler.java:6921)
at clojure.core$load_reader.invoke(core.clj:3627)
at clojure.core$load_string.invoke(core.clj:3637)
at user$eval4924.invoke(NO_SOURCE_FILE:117)
at clojure.lang.Compiler.eval(Compiler.java:6511)
at clojure.lang.Compiler.eval(Compiler.java:6477)
at clojure.core$eval.invoke(core.clj:2797)
at clojure.main$repl$read_eval_print__6405.invoke(main.clj:245)
at clojure.main$repl$fn__6410.invoke(main.clj:266)
at clojure.main$repl.doInvoke(main.clj:266)
at clojure.lang.RestFn.invoke(RestFn.java:512)
at user$eval27$acc__3301__auto____30$fn__32.invoke(NO_SOURCE_FILE:1)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Thread.java:680)

but I guess that issue should go into its own thread.

@alexott
Owner

yes, it's better to file separate bugs for these errors
thank you

@alexott alexott closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.