[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference rusure::math

Title:Mathematics at DEC
Moderator:RUSURE::EDP
Created:Mon Feb 03 1986
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2083
Total number of notes:14613

1092.0. "closed expressions and their inverse" by UTRUST::DEHARTOG () Wed Jun 28 1989 21:35

Here's a problem out of my current programming practice:

Given a relation between five variables (b, e, i, p and n),
I want to find closed expressions for any of five variables.
So, when four of the five variables are known, I want to compute
the fifth with a simple expression. It's easy for b, e, i and p:

b = e / (i ^ n) - n * p / 2
e = (b + n * p / 2) * (i ^ n)
i = (e / (b + n * p / 2) ^ (1 / n)
p = 2 * (e / (i ^ n) - b) / n
n = ???

If it's any help, some constraints are known from the real world: all
variables are real numbers, n is greater than zero, i is in the
interval [1,2]; there is also a relaxing constraint: it is sufficient
to give an approximation for n within 1% accuracy or so.

That was real practical but now theoretically: one of course is
interested in the set of closed expressions that have their inverse
counterpart in the same set...
T.RTitleUserPersonal
Name
DateLines
1092.1iterative techniqueEAGLE1::BESTR D Best, sys arch, I/OFri Jun 30 1989 14:5433
I don't think that you will be able to get a neat closed form expression
for n.

I have no proof that this works for arbitrary values of e, b, i, and p,
but, being an engineer, I tried a dumb brute force experiment
in which I iteratively evaluated:

n' = 2 * ( e - b * i^n )/p/(i^n)

until | (n' - n)/n' | < .001

with initial value of n = 1 and a few sets of e, b, i, p that satisfied your
criteria.

It converged for most of the combinations I tried.  It did seem to oscillate
for certain combinations.  Empirically, this seemed to occur when
i got larger (> 1.05), but this is a wild leap based on a very small set of
observations.  When this happened, I chose a value between the two oscillating
endpoints, and it converged.  I didn't notice any divergence, but that doesn't
mean much.

Perhaps one of the numerical analysis wizards can help validate/invalidate
this kind of iterative solution or provide ranges and provisos.  There may
well be unsafe ranges of non-convergence, but (practically) I would consider
using such an iterative approach until I found a combination of parameters
that didn't work.

If you use this technique, I would advise fail-safe'ing the program by
putting in iteration count limits, and maybe some divergence limits to
avoid floating overflow, bad denominator values, negative n, etc.  A clever
program would also look for 'bouncing' or divergence and kick the value of
n0 into previously uncharted intervals.  For example, n' = (n' + n0)/2
where n' and n0 are the oscillation endpoints.