Re: Math Functions: Domain problems...

From: Eric Ford (eford_at_[hidden])
Date: 2001-09-10 17:34:20

I'm having a little doubt about the preliminary design of the
checkers.
Presently, both an accuracey checker and a domain checker are used as
optional template parameters.  You can pass your own checker at
construction or use the default.

I'm pretty sure the accuracey checker needs to have it's own class.
Sometimes users have quite strange criteria for cehcking whether
something is accurate (e.g. you may be integrating some ode's that
come from a Hamiltonian system, so you might check how well energy is
conserved).  So I beleive the flexibility of an accuracey checker
class is necessary.

For the domain checker, I'm not so sure.  Basically, you need to
know if the user wants to perform domains checks (a bool) and what the
domain is.  So I'm wondering if it would it be better to replace the
domain checker template parameter with a domain template parameter and
a bool.  The bool could either be it's own parameter or it could be
included in the error handeler.  (I've made a simple policy based
error handeler which could easily pick up another bool. But I'm a
little reluctant to do that, since it seems to me that whether you
perform domain checks doesn't entirely fit with the concept of an
error_handeler.)  I'd like to have the domain be it's own template
parameter so that algorithms could be chosen on the basis of the
domain.  By hiding the domain type in the domain checker type, it's
difficult for an implementation to impose additional restrictions on
the domain, since that requires extracting the domain, creating a new
domain, and then creating a new domain checker (of a different type
than the template parameter) with the modified domain.  This could be
resolved by a Bartman & Nackman trick, but I don't think that's
necessary here.  And since a user creating their own domain class
might not be so uncommon, it migth be desirable to avoid making them
use that.

Actually, just being able to manipulate domains is a fairly big deal
by itself.  If all you do is provide a bool is_in_domain(arg_type x)
function, then it's relatively easy to combine them (e.g. you can
create a domain_intersection<D1,D2> class that just returns
(D1::is_in_domain(x)&&D2::is_in_domain(x)).  However, making a domain
class that allows for choosing an algorithm based on the domain, is
much more difficult.  For example, you may want to be able to choose a
different algorithm for bessel functions depending on the order
(e.g. the order is 0, non-zero integer, half integer, multiple of a
third, rational with a small denominator, real, complex, small, large,
etc.).  You need a way to test if the domain a user has sepcified
(the domain they want) is a sub domain of the domain provided by a
given
algorithm.  While you can write out complicated domains as a bunch of
unions and intersections of more primitive domains, there are often
multiple ways of writing the same domain.  So you need to do more than
just make union<D1,D2> and intersection<D1,D2> templates.  You need a
way to either reduce a given template expression to some "standard
reduced form" or at least a way to regocnize when one's a subset of
the other.  (If you can test for each being a subset of the other,
then you can combine them with an and to test for equality.)  Does
anyone have experience with this?

BTW- Does anyone see a need for a user to provide an error handeler
that has non-static members?

Thanks,
E