Hi Phil.
On Wed, 01 Apr 2015 10:27:52 -0700, Phil Steitz wrote:
Starting with Thomas and Gilles' tex setup from FOSDEM 2013, I have
started creating slides for my talk in a couple of weeks at
Apachecon NA [1]. The basic idea is to combine an overview and
quick examples with some discussion of the many design and
implementation challenges that we have faced. I have put the tex
sources on github [2] and would appreciate any comments or just PRs
there. There is a make file (thanks, Thomas!) that creates a pdf
from the sources and also has a clean target to clean up cruft. You
need to have beamer installed for the build to work.
The content looks like too much for 50 mins, but I can fly through
most of it, so don't be discouraged to provide more examples. I can
also swap out some of the ones that are there. I have also
obviously not made it look pretty yet. Patches of all kinds welcome
:) My goal is to have the slides complete and uploaded to LF by the
end of this weekend.
Thanks in advance for review / feedback. Its probably best to
provide the feedback on github. If we get into any code
discussions, we can take things back here.
Phil
[1] http://sched.co/2P9O
[2] https://github.com/psteitz/apachecon-2015-commons-math.git
Depending on your goal(s) and expected audience, you might want[1]
to make it transparent that there are conflicting approaches to
the development of Commons Math (sometimes along the lines of what
you mention as "problems"). As an example, the statement
---
Distribution classes also have sample() methods, but that makes
them dependent on generators
---
could be expanded to show that the problem _can_ be solved, that
a patch exists, but that no consensus can be reached due to the
non reconcilable opinions: stability of the (naming) API[2] vs
evolving the API whenever such a problem is identified.
That was a concrete example; a more general aspect that leads
to tension is that it is not easy or obvious to delimit the
scope of Commons Math. Some like to add features, others fear
that a feature may become orphan (when the contributor goes
away) when it is realized that major refactoring is needed
(example: "BOBYQAOptimizer").
Even more pervasive is the less and less true statement of
Commons Math being "state-of-the-art" (whether programming-like,
library-like or performance-like): one aspect that you mention
is indeed the inherently parallel nature of some algorithms
and the decision to maintain codes that cannot benefit from the
now ubiquitous multi-CPU machines (example: genetic algorithm).
Another is the whether to (be allowed to) keep up with the Java
language (also as a means to, perhaps, attract people who might
take the challenge to make Commons Math state-of-the-art again).
It might also be interesting to update the status of the
"FastMath" comparisons (also with Java 8).
Regards,
Gilles
[1] Or not...
[2] Even though the top-level package is changed anyways (so that
existing code is never broken anymore).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
