commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <>
Subject Re: [math] Priority
Date Fri, 30 May 2003 21:08:09 GMT wrote:
> Just because we the creators of the framework see no need for higher
> order derivates, the end users, whose needs no one can fully
> enumerate, may have a quite reasonable use for them.

Well, I designed the interface as a helper for a variety of
numerical algorithms, not for general use. It's the way the
user supplies his function to solvers. Solvers rarely need
higher derivatives. If a solver has to use a third or higher
derivative, we can still extend the interface. If someone else
wants to use an algorithm which needs higher derivatives, he
can use his own mechanism or extend what is available on his

>  If you create a function, you control the
> implementation for creating the derivative function object and is
> directly coupled to your object. The implementor, you,

Not quite. I expect a variety of prebuild function objects
and perhaps some mechanisms for more generic definition of
functions, but if push comes to shove, it's the user of
j-c-math who has to code a class for supplying his function
to the solver. I want to think him of the calculations to
be closely related.


> Why can't the domain of interest and explicit input be a single value?
>  That's exactly how I did the CDF stuff using a root finding method
> which needs a bracket and it worked fine.  And it's a generic process
> that could be incorporated into all the solvers.

Nice, build a modular system: an interval(or bracket)-from-start-value
builder and solvers which need an interval (or more likely a bracket).
You can provide convenience objects which combines everything.

 > When did I introduce finding all roots into this discussion?

You didn't.
A solver might not find the root closest to the start value,
with no indication that there is a root closer to the start
value than the reported root. I mean something like start
value 0, expected root near 0.5, reported root 1E15. I wager
a guess this will irritate a few people. OTOH, letting the
solver do heavy checking every time just in case may be seen
as an unnecessary overhead to more advanced users, and because
this *will* be equivalent to the problem of finding *all*
roots in general, it is often impossible.
Note that the most difficult part in root finding is not finding
the root, but detecting when you stray out of the domain of
applicability of the algorithm and detecting ill conditioned

Having the user to supply an interval is no guarantee that he
knows what he is doing, but if the interval size is much larger
than the required accuracy suggests, implementations could just
bail out.


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

View raw message