commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brent Worden" <>
Subject RE: [math] abstact nonsense was Re: [math][functor] More Design Concerns
Date Wed, 02 Jul 2003 07:13:16 GMT
> -----Original Message-----
> From: Phil Steitz []
> Sent: Tuesday, July 01, 2003 11:08 PM
> To: Jakarta Commons Developers List
> Subject: [math] abstact nonsense was Re: [math][functor] More Design
> Concerns
> 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.

Problem with this is if we add a complex number data type, none of the
storage and computation facilities can handle the new type.  If we keep
everything as is, the only way to support complex matrices is to duplicate
the real matrix functionality in a new complex matrix functionality.  Yuck.

>  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"

Unfortunately, Java has created a huge distinction between objects and
primitives.  They're incompatible types.  Objects have to be treated in a
distinctly different manner than primitive values.  I prefer objects over
primitives because the other commons projects we depend on are built around
objects.  For instance, 90%+ of the functionality in commons-collections is
geared towards objects and unusable by our primitive approach.  I wager we
could see a significant code reduction in the univariate classes if we could
incorporate some of those object driven routines.  Yeah.

> 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.

Statistical data analysis also involves dates, times, categories, etc.  None
of which can be handled by the univariate classes without converting them to
doubles before adding them to the container and reversing the conversion
when accessing metrics.  This is hardly convenient to the user.

> 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.

Are finding eigenvalues, iterative refinement of linear system solutions,
solving of linear systems, finding roots of complex equations, finding roots
of bivariate equations, etc. contrived examples?  No, they're are practical
applications that could be addressed using a bisection method or other root
finding techniques.  And all of these applications could be addressed using
the same implementation using different functors.  Yeah. Yeah.

> What is practically valuable in the rootfinding framework is
> rootfinding for real-valued functions of a real variable.

No one is talking about taking that away.  I would prefer the convenience
methods for the standard applications stay in place.  What I would like to
see is when a complex number data type is added to the library that the root
finding methods we have in place can be applied to this type.  If we keep
the solvers as is, we would have to write a whole new root finding framework
for complex functions.  Yuck. Yuck.

Brent Worden

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

View raw message