Phil Steitz a écrit : > Ted Dunning wrote: >> 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? >> > Part of 3) is having full code available with the package for > inspection. That is part of the reason that we have avoided external > dependencies. I would be open to making our fully self-contained, fully > documented, fully open source library extensible to use other libraries, > including native libraries, but I would not want to distribute anything > associated with external libraries. The reason for this is the > commitment made early on that all numerics and algorithms would be > immediately visible to the user - no chasing down external, possibly > incomplete or ambiguous docs to figure out what our code is doing.
I have an additional reason for avoiding native libraries. Pure Java can be processed by external tools for either inspection (think findbugs, cobertura, traceability, auditing) or modification (think Nabla!). The Nabla case is especially important to me, but I am aware this is a corner-case. >> 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. >> > As Luc said, commons-math aims to be a general-purpose applied math > package implementing good, well-documented, unencumbered numerical > algorithms. I think this can be done in Java and we are doing it. We > are never going to compete with optimized native code in speed, but > strong numerics, JRE improvements and Moore's law are rapidly shrinking > the class of real-world applications where the 3x difference above is > material. Perhaps we should have some benchmarks including our new linear package. Something more serious than my little experiement with QR decomposition. Unfortunately, I clearly have no time for it now. My current priotity is to publish 2.0 as soon as possible and I am already late on my own schedule. Luc > > Phil > > >> 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 >>> >> >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
