Phil Steitz wrote:
3 Both MathException and ConvergenceException don't compile on Java 1.3
  and nobody noticed. This is ugly:
Ranks inserted (IMHO, of course)

Agreed with rankings. However, I think in the long term either the recursive exception should be factored out of [lang] into a separate package for better reuse, or merge [math] with [lang] into a somewhat bigger package resembling a extension to the whole java.lang+java.util+java.text combo.

Part of the reason for packing it all into RealMatrix was the need to keep the LU decomposition handy to avoid having to recompute it.

I'd think so. Nevertheless, better modularization allows for people which can afford to dive into the more complex network of interfaces to more extensively customize the solving algorithm and, more important, discard the LU-data and other auxillary stuff quickly after it is no longer needed. I'd like to have both: small components for experts and convenient interfaces to allow unsophisticated users to have a quick shot at solving their problem.

I have to confess, however, that I have never liked this.add(that) syntax

Mee to: it runs counter to how the equations are printed in books for hundreds of years. From this point of view its a pity Java doesn't have user defined operators and operator overloading (this doesn't mean I'd like to have this in Java).

I am interested in what others think about this -- especially others who might actually use real matrices in their programs.

Whoever uses Java for extensive numerical calculations is soon tempted to abandon it and go either to FORTRAN (maximal performance and the most mature libraries) or C++ (near FORTRAN performance and much improved code maintainability). I see [math] mainly useful for descriptive and partly for analytical statistics, because this functionality is actually used in the business/web service environment where Java is a major player.

For the same reason I support the idea of adding financial math
functionality (Black-Scholes anyone? :-).

Interpolation as it is currently implemented is only of limited use in
this context, I guess it would be mostly used to draw a graph of the
function (suggestions for adding Java2D integration welcome). There's
obviously overlap with graphing/diagram packages like JFreeChart, but
we don't have any such package at Apache anyway.

Solving linear equation systems may have some use in this environment
too, but I can't imagine that general matrix calculations are used on
a regular basis. Nobody is going to solve economical networks or
calculating magnetical fields in a web application.
Well, there is bayesian and vector based text classification, as in
statistical spam filtering, of course.

Anyone out there willing team up to add graph and diagram layout to
j-c-s-graph? The book is Battista et al: Graph Drawing, ISBN 0133016153.

Note that to me, solve() is conceptually no different from add

But it is. add() represents an operator, solve() represents a complex algorithm, depending on more data like accuracy concerns than add().

6 Factorials and binominal coefficients
Interesting perspective. The uses that I had in mind were for discrete probability distributions

Ah, forgot about these.


J.Pietschmann


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to