The changed subject line is a pun that I hope none will find insulting 
sort of a little math joke. "Abstract nonsense" is the term that some
mathematicians (including some who love the stuff) use to refer to
category theory, the birthplace of the functor concept. To conserve
bandwidth, I am going to try to respond to the whole thread in one message.
First, I agree that the funtor concept, or more importantly functional
programming, represents a very powerful technique that is certainly
widely relevant and applicable to mathematical programming. Exactly what
is relevant and useful to commonsmath, however, is not obvious to me.
Brent's examples are not compelling to me. My main concern is that at
least initially, commonsmath is primarily an applied math package,
aimed at direct applications doing computations with real and complex
numbers. I do not see strictly mathematical applications as in scope 
at least initially. By this I mean things like applications to finite
fields, groups, etc, which is where I personally see the value of the
"abstract nonsense" really kicking in.
As I said in an earlier post, I do not see the main distinction to be
between "objects" and "primitives" but rather between reals, integers,
complex numbers and more abstract mathematical objects such as group,
field, ring elements or elements of topological spaces with certain
properties. To me, doubles are "natively supported reals" and these are
by far the most important objects that any applied math package will
ever work with. Almost every (another little pun) real statistical
application uses realvalued random variables, for example.
Brent's "rootfinding" example illustrates what I mean. If this kind of
thing is really useful, what is useful is the notion of convergence in a
dense linear ordering without endpoints  moderately interesting from a
mathematical standpoint, but not compelling, IMHO from an engineering or
applied math perspective. The "vector convergence" example is
contrived. What is practically valuable in the rootfinding framework is
rootfinding for realvalued functions of a real variable.
I see no point in a) introducing the object creations/gc overhead and b)
losing the strong typing to introduce "typeless" functors into
commonsmath at this time. I would even go so far as to say that I
would *never* want to see "typeless" functors introduced, even if we
decide that we want to be Mathematica when we grow up. As and when the
need for more abstract mathematical objects arises, we should model them
and their morphisms directly, using naturally defined mathematical
objects. The functor pattern could certainly play a role here; but I
would want to see at least the algebraic properties of the morphisms
(functors) themselves defined explicitly following some standard
mathematical definitions. I may be manifestly missing the point of the
o.a.c.functor package here, in which case I would appreciate (gentle)
enlightenment.
One final point. A few comments were made about performance and what
commonsmath should aim for. My perspective is that performance is an
important consideration and we should avoid adding computational and/or
resource management overhead unless there is a compelling reason to do
so. As David Graham pointed out in an earlier post, Jakarta Commons
components need to target server application deployment. This means that
we cannot do things that kill scalability, which bad performance and
excessive resource consumption will do. While I do not see commonsmath
as a "numerics package", I do see it as a package that provides some
basic numerical analyis capabilities and it needs to do this in as
efficient, stable and standard a way as possible in Java.
I agree with Al that we try our best to stay focused on the actual
application use cases and let these drive design. From my perspective,
what I see now are realvalued random variables, realvalued functions
and a few other objects that we have modelled in a straigtforward way
(e.g real matrices) that both mathematical and nonmathematical users
will find relatively easy to understand. I am not convinced that either
for internal use or certainly for exposed interfaces we will get any
value out of introducing additional abstractions at this time. Of
course, I may just be missing the point of Brent's utopian vision and/or
the universal applicability of the functor concept.
Phil

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
