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.-----Original Message----- From: Phil Steitz [mailto:[EMAIL PROTECTED] 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 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.
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.
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 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 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 ;-)).
Phil
Brent Worden http://www.brent.worden.org
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
