Luc Maisonobe wrote:
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.
+1 for getting 2.0 released ASAP. This is long overdue and we need to
stay focussed on getting it out.
Phil
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
