Brent Worden wrote:
>>Original Message
>>From: Phil Steitz [mailto:phil@steitz.com]
>>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 commonsmath, however, is not obvious to me.
>>Brent's examples are not compelling to me. My main concern is that at
>>least initially, commonsmath 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.
>
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 commonscollections 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 arraybased
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 realvalued 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, welldocumented computation
support in commonsmath. 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 realvalued 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
>>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.
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 realvalued 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 "rootfinding for complex functions" as something that we
will likely ever implement in a way that is logically similar enough to
rootfinding 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 realvalued 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 ;)).
Phil
>
> Brent Worden
> http://www.brent.worden.org
>
>
> 
> To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
> For additional commands, email: commonsdevhelp@jakarta.apache.org
>

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
