- #1
kts123
- 72
- 0
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?
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?