commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [math] abstact nonsense was Re: [math][functor] More Design Concerns
Date Wed, 02 Jul 2003 14:24:36 GMT
Brent Worden wrote:
>>-----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
>>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
> 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.
For the specific case of real matrices, you definitely have a point.  My 
opinion, however, is that a) it is not obvious to me that we will be 
adding complex matrices any time soon b) the current RealMatrix 
interface and implementation make essential use of the fact that the 
entries are real -- both for computational efficiency and for ease of 
use and c) we can always insert a base "Matrix" and refactor the 
implementation later without changing the RealMatrix interface, which I 
maintain is *much* better for actual applied work than a "Field element" 
based interface forcing users to cast everything and losing the 
efficiency and ability to represent and work with large matrices that 
the native double[][] implementation provides.

>> 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.
I am not convinced of this.  There really is not that much code there. 
If what you think you can eliminate is all of the DoubleArray stuff, 
that is probably true but at a significant loss of performance and 
flexibility.  I would in any case always want to keep the array-based 
implementations for speed and ease of use.  That would result in code 
swell (and smell).  Yuk.

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

You are missing the point. To use the continuous methods, you *must* 
convert to real in any case.  I would prefer to have the user control 
this conversion.  Think through the use cases.  What does the mean of a 
collection of dates mean? Need to decide discrete vs continuous and set 
up a mapping -- a *random variable*.  I would prefer to let the user do 
this explicitly and provide efficient, well-documented computation 
support in commons-math. For the discrete case, I agree that Frequency 
can certainly be improved/extended to accomodate different sorts of 
objects, but there again, it is going to come down to string 
representation of the discrete values and then floating point 
computations to analyze the distributions.  I think that Tim's 
"BeanList" stuff is the kind of thing that we should be looking at in 
terms of extending to support collections, but even there the linkage to 
the core computational infrastructure is real-valued properties.
>>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
> 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.

Maybe I am dense, but I do not see the huge value of a DLO convergence 
algorithm for the mathematical problems that you are describing above. 
Sure, you could probably wrap real solutions to these problems in an 
abstract "convergence" functor, but I see no value in this.  You will 
still be doing the real work in the implementations.  If, on the other 
hand, what you were suggesting was something like an abstract field 
class or a functor class based on field operations, that might turn out 
to be useful (and in fact provide some of the basis for a generic 
Matrix), but I simply do not see the need for this now.
>>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.

I do not see "root-finding for complex functions" as something that we 
will likely ever implement in a way that is logically similar enough to 
root-finding for R->R functions that a common infrastructure will be 
useful.  I know that is a bold statement, but if you think carefully 
about the use cases, I think (hope?) that you will agree -- i.e., what 
will be left of "rootfinding" when it is abstracted to the level where 
it both makes sense and can be implemented in a utility fashion that can 
be reused across both of these domains is not much.  If you look at NR 
for example, or Colt or other numerics packages, you will see that the 
"special case" of real-valued functions (and matrices) really is 
addressed directly and specifically.  That is not just because these 
guys are all old Fortran programmers who can't handle abstraction (like 
me ;-)).


> Brent Worden
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message