From commons-dev-return-31865-qmlist-jakarta-archive-commons-dev=nagoya.apache.org@jakarta.apache.org Wed Jul 02 04:08:34 2003
Return-Path:
Delivered-To: apmail-jakarta-commons-dev-archive@apache.org
Received: (qmail 15552 invoked from network); 2 Jul 2003 04:08:33 -0000
Received: from exchange.sun.com (192.18.33.10)
by daedalus.apache.org with SMTP; 2 Jul 2003 04:08:33 -0000
Received: (qmail 7362 invoked by uid 97); 2 Jul 2003 04:11:06 -0000
Delivered-To: qmlist-jakarta-archive-commons-dev@nagoya.betaversion.org
Received: (qmail 7355 invoked from network); 2 Jul 2003 04:11:06 -0000
Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12)
by nagoya.betaversion.org with SMTP; 2 Jul 2003 04:11:06 -0000
Received: (qmail 15321 invoked by uid 500); 2 Jul 2003 04:08:31 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe:
List-Subscribe:
List-Help:
List-Post:
List-Id: "Jakarta Commons Developers List"
Reply-To: "Jakarta Commons Developers List"
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 15310 invoked from network); 2 Jul 2003 04:08:30 -0000
Received: from unknown (HELO hume.tsdinc.steitz.com) (209.249.229.10)
by daedalus.apache.org with SMTP; 2 Jul 2003 04:08:30 -0000
Content-Class: urn:content-classes:message
Received: from Lavoie.tsdinc.steitz.com ([209.249.229.4]) by hume.tsdinc.steitz.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Jul 2003 00:08:35 -0400
Received: from steitz.com ([130.13.162.175]) by Lavoie.tsdinc.steitz.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Jul 2003 00:08:35 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Message-ID: <3F025A89.9010909@steitz.com>
Date: Tue, 01 Jul 2003 21:07:37 -0700
From: "Phil Steitz"
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Jakarta Commons Developers List"
Subject: [math] abstact nonsense was Re: [math][functor] More Design Concerns
References:
Content-Type: text/plain;
charset="us-ascii";
format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Jul 2003 04:08:35.0280 (UTC) FILETIME=[9B8CDD00:01C3404F]
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
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