commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject [math] abstact nonsense was Re: [math][functor] More Design Concerns
Date Wed, 02 Jul 2003 04:07:37 GMT
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) 

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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message