Hi (warning: this is an entangled message),

For all those library writers, I have a tough design decision to make about
the interface between my network optimization library and the user, and I
keep bouncing back and forth in ideas in loops, so I want to get some help:

Assume that there is a user "cost" function c=f(x), where x is the "flow".
The derivatives of this cost function are the "potential" g=f'(x) and
"resistance" h=f''(x). The potential is invertible, that is, either knowing
the flow or knowing the potential determines all the rest uniquely via
x=(f')^(-1)(g). All these are assumed to be expensive (order of several
exponentiation operations) to calculate.

In various parts of my algorithm what is known (flow or potential) will
change from only the flow known at some point, or only the potential known,
*or both* (from previous calculations, while the other value may be
approximately known (and so can be used as a guess in any iterative
algorithm there may be for calculating these), or may not be known.
So, the possible input combinations are (K is known, A is approximate, U is
unknown):
1. K: x, K: g
2. K: x, A: g
3. K: x, U: g
4. U: x, K: g
5. A: x, K: g
The cost c and resistance r are always assumed to be unknown U to avoid too
many possibilities.

For each set of these possible inputs, we may want to calculate any number
of the unknown or approximate values. If we denote with N the fact that a
value needs to be calculated, and with I that that value is not needed
(ignored), a possible situation may be:
K: x, A, N:g, U, N:r, U, I: c

So now you get the gist that there are *many* possibilities. The important
part is that for some cost functions f things may be more quickly calculated
from the flow, but for some the potential may be the more natural
independent variable (as I said one or the other uniquely determines all the
rest). Another important thing is that computation may be saved considerably
if more values are bundled together.

For example, if f(x)=x^a, where a is a real number (exponentiation is
expensive), then g=f'(x)=a*x^(a-1) must be calculated expensively. But now
assume that at the same point we want the resistance too. Then we can save
ourselves half the time by doing:

temp=x^a ! The expensive part--if f is known approximately, then it can be
used as a starting guess in Newton's iteration for calculating this
if needed: f=temp
if needed: g=a*temp/x
if needed: h=a*(a-1)*temp/x/x or if g is already calculated h=(a-1)*g/x

So, I want to put the whole burden of these possibilities to the user. In
some old (and new) codes, reverse communication is used for this--the user
is told what is needed and what is known or approximate, and then he needs
to perform the calculation and call the optimization library again. In my
case, notice that the calculations described here will have to be carried
out in an inner loop many times (maybe for different powers a).

I do not like reverse-communication. Instead, I want the user to provide a
routine (a dummy argument) for the optimization library, that will accept a
valid combination of inputs and desired outputs (such as K: x, A, N:g, U,
N:r, U, I: c) and calculate the values that have the N on them.

The problem is on how to make an interface to this routine, because of all
the possibilities. For example, the values that are U,I need not even be
present in the argument list, the values with K are INTENT(IN), and the
others are INOUT or OUT. As I mentioned, this routine is expected to be
expensive, but it should not do most of its calculation in IF statements and
CASE structures. So a balance between efficiency and ease-of-use/writing is
needed.

If anyone has an idea of how to write an interface for such a function (and
then the next step is actually writing the function for say f(x)=x^a.I know
that doing things this way is not the standard approach to user-library
interfacing, but I think it may be a good approach that allows the user a
lot of flexibility in choosing the fastest approach, while giving me inside
the library a simple way of using this user input and passing it around as
just one dummy argument procedure.

Thanks a lot for listening,
Aleksandar

_____________________________________________
Aleksandar Donev
http://www.pa.msu.edu/~donev/
[log in to unmask]
(517) 432-6770
Department of Physics and Astronomy
Michigan State University
East Lansing, MI 48824-1116
_____________________________________________