Phil, I think we have much of the same desires and motivations, but we seem to come to somewhat, but not entirely different conclusions.
Assuming that (1) can be dealt with and assuming that (3) is already dealt with, do you still mind the inclusion of *optional*, automatically generated native code? This page has some useful speed comparisons. For matrix-matrix multiply up to size 50, java is competitive. If you get up to roughly n = 500 or 1000, then heavily optimized native code can be up to 3x faster. Note the line in the third graph for colt (a reasonably well written pure java implementation) and MTJ (which is running in pure java mode here). In my case, I will generally opt for portability, but I like to have a portable option for speed. It is also important to remember that numerical codes more often need blinding speed than most other applications. http://blog.mikiobraun.de/2009/04/some-benchmark-numbers-for-jblas.html Is that optional dependency really all that bad? On Fri, May 15, 2009 at 6:23 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > [math] also has currently zero dependencies. We had two dependencies on >> other commons components up to version 1.2 and removed them when we >> started work on version 2.0. Adding new dependencies, and especially >> dependencies that involve native libraries is a difficult decision that >> needs lots of discussion. We are currently trying to have 2.0 published >> very soon now, such a decision would delay the publication several months. >> >> > -1 for adding dependencies, especially on native code. Commons math needs > to remain > > 1) ASL licensed > 2) self-contained > 3) fully documented, full open source -- Ted Dunning, CTO DeepDyve
