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 commons-math, however, is not obvious to me. Brent's examples are not compelling to me. My main concern is that at least initially, commons-math 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 real-valued 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 real-valued 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 commons-math 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 commons-math 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 commons-math 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 real-valued random variables, real-valued functions and a few other objects that we have modelled in a straigtforward way (e.g real matrices) that both mathematical and non-mathematical 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, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org