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.
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.
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
