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 LUdata 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 (BlackScholes 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
jcsgraph? 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, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
