Discovering a Moving Orbit Algorithm

[kts123]

A moving "orbit"?

I'm using the term orbit in a non-mathematical sense, because I don't know what it is I've just thought up! It seems very interesting to me, does anyone know what it is I've stumbled on?

Imagine an algorithm that is iterated as follows:

*I must stress that g( ), f( ), and F( ) are each unique, and that that they are the ONLY functions being used.

If a < b, then a = f(a), and b = g(b) where 0 < |g(b)-b| < |f(a)-a| and 0 < b < g(b) and 0 < a < f(a)
If a > b, then a = F(a) and b = g(b) where 0 < |F(a)-a| < |g(b)-b| and 0 < b < g(b)

In otherwords, the difference between b and g(b) is LESS THAN the difference of a and f(a), hence when the function f(a) is iterated against g(b), f(a) will "grow faster" than g(b), hence while a < b, a is "catching up" to b. After this is iterated enough, a will pass up b...

Now that a has passed up b, the second half of the algorithm comes into play:
When iterated, the difference of g(b) and b is GREATER THAN the difference of a and F(a) (by definition.) Hence each iteration of g(b) causes a larger increase than that of F(a) -- in otherwords, b is now running faster than a!

HOWEVER, g(b) ALWAYS causes b to increase -- hence EVERY iteration causes our algorithm's outputs of a and b to steadily increase, yet since a will pass up b, and then slow down so that b passes up a (or in the case of 0 < F(a) < a, run backwards!) I say that a is orbiting b, and that b is moving.

Imagining a graph in which each iteration is given an x value, and each a output a y value, various functions satisfying the inequality would probably create a "stair-case." I'm wondering what might happen if an iteration would cause a = b, how we might re-define the algorithm to account for that (maybe have one side defined as LESS THAN OR EQUAL TO, and the other simply as GREATER THAN -- or reverse this to get a new effect on the algorithm, I'm not sure.)

Eh-hem, and for good measure, here's an example:
if a (lesser-or-equal-to) b, then b = b+2 and a = a+3 (starting at a = 1 and b = 2)
if a > b, then b = b+2 and a = a-10

a = 1, and b = 2, 1 < 2, therefor we iterate: a=1+3, b = 2+2
a = 4 and b = 4, a is less or equal to b, therefor we iterate: a=4+3, b = 4+2
a = 7 and b = 6, a is GREATER than b, therefore we iterate the second: a=7-10, b=6+2
a = -3 and b = 8 ...

See what I mean?

 

[kts123]

After a little thought, it also seems like this might be adapted into other contexts (complex functions, with neighborhoods as criteria for example.) I'm not really sure if this is useful or worth bothering with though, since it really is nothing more than an algorithm -- I guess there really isn't anything stopping us from making one as confusing or complex as need be.

I'm mostly just interested in the behavior of the "orbit," since each value of the function will create a unique pattern. You can plug a few into a script (I tried it myself in Python Shell last night) to see what I mean.

 

[HallsofIvy]

I suspect you are not getting any responses because it is not at all clear what you are saying. For example, you appear to have a function, g, of some variable b. But then you say "g(b) ALWAYS causes b to increase ". What does that mean? How does a function "cause" the variable to increase"?

 

[kts123]

Oops, I forgot to specify by what I mean by "iterate."

Take a single number, 3, and then apply a function to it:

3*2 = 6
now take the output and apply the function to THAT:
6*2 = 12
now take the new output and apply the function to THAT:
12*2 = 24
now take the new new output and apply the function to THAT:
24*2 = 48

etc. That is, set a specific value for a and b, and then apply the given function to each value; then take the new value and apply it to THAT. I guess I misused the term "iterate" (and maybe function?) Anyway, does that clarify?

And what I mean by it "always causes it to increase," I mean that g < f(g) ; that is, each output is greater than the input. For example, f(g) = g+1 ; therefor g < f(g).

--------------------------------------------------------------------------------

Sorry, I'm not doing a good job explaining myself I can tell. Maybe it would be better for me to state that a and b are NOT variables, but rather objects that are transformed by an operation that is similar to a function.

When I say "a = f(a)," I mean it somewhat in the python-programing language sense. Does that help?

 

[CRGreathouse]

I'm going to try to translate, kts123.

Set some values a_0,b_0&gt;0. Define
b_{n+1}=g(b_n) and
a_{n+1}=\begin{cases} f(a_n),\;a_n&lt;b_n\\\text{?},\;\;\;\;\;\;\;\;a_n=b_n\\F(a_n),\;a_n&gt;b_n \end{cases}
for n\ge0. f and g are strictly increasing functions. (Should F be strictly increasing, as well?)

If a_n&lt;b_n, then a_{n+1}-a_n&gt;b_{n+1}-b_n;
if a_n&gt;b_n, a_{n+1}-a_n&lt;b_{n+1}-b_n.


In some sense, g increases faster than F but slower than f:
F\prec g\prec f
so a_n-b_n oscillates above and below 0 as n increases.

 

[kts123]

I'm going to try to translate, kts123.

Set some values a_0,b_0&gt;0. Define
b_{n+1}=g(b_n) and
a_{n+1}=\begin{cases} f(a_n),\;a_n&lt;b_n\\\text{?},\;\;\;\;\;\;\;\;a_n=b_n\\F(a_n),\;a_n&gt;b_n \end{cases}
for n\ge0. f and g are strictly increasing functions. (Should F be strictly increasing, as well?)

If a_n&lt;b_n, then a_{n+1}-a_n&gt;b_{n+1}-b_n;
if a_n&gt;b_n, a_{n+1}-a_n&lt;b_{n+1}-b_n.


In some sense, g increases faster than F but slower than f:
F\prec g\prec f
so a_n-b_n oscillates above and below 0 as n increases.

F doesn't need to strictly increase, it simply needs to increase "slower" than g. Anyway, your last statement sums up the result very nicely. I *think* you have a functional translation, so kudos.